Por todos es conocida la utilidad de la ingeniería inversa. En este
caso, presentamos una aplicación de la citada técnica a la hora de
analizar parches de actualización, con fines de investigación.
Halvar Flake, especialista en ingeniería inversa y responsable de la
consultora Sabre Security, decidió investigar sobre el parche crítico
publicado para Microsoft Internet Explorer, y se centró en la
vulnerabilidad en la gestión de documentos gráficos portables PNG.
Utilizando herramientas propias, Flake localizó, comparando una versión
parcheada con una sin parchear, los cambios específicos que supuso el
parche MS05-025 en menos de 20 minutos, ante una audiencia atónita.
El software empleado, que el autor ha denominado BinDiff, localiza
cambios entre binarios. Con esta demostración, Flake documentó cómo los
parches rápidos y teóricamente inocuos pueden ser fuente de obtención de
código vulnerable, una vez aplicada una técnica de ingeniería inversa
sobre los mismos.
En un documento aparecido el pasado mes de Junio, los mismos
investigadores analizaron mediante ingeniería inversa un fallo en
SSL que Microsoft había parcheado. Una vez estudiadas las versiones
con y sin parcheo, fue posible deducir un exploit en menos de 10
horas. En el mismo documento, se analiza igualmente la deducción de
una explotación para la vulnerabilidad del servidor ISA (Internet
Security and Acceleration), descubriéndose que el parche corregía la
vulnerabilidad sólo en algunas partes del sistema, habiéndose olvidado
los desarrolladores de corregir el código erróneo en ciertas partes
del mismo, lo que permitía generar código de explotación para una
vulnerabilidad teóricamente corregida.
La técnica de comparación de binarios es muy útil para otros propósitos:
por ejemplo, el análisis de la posible violación de propiedad
intelectual en programas, el análisis de cumplimiento de licencias, el
análisis de cambios en la morfología de virus, y tal y como se ha visto,
deducir problemas de seguridad a partir del código parcheado.
Parece obvio que el principal problema de la deducción de vulnerabilidades
por ingeniería inversa está en el hecho de que algún usuario malicioso
puede desarrollar un exploit una vez se ha publicado el parche, y
distribuirlo con intenciones maliciosas antes de que la gran parte
de los usuarios de dicho sistema se hayan actualizado. Algunas firmas,
como Oracle, dificultan el proceso de ingeniería inversa de parches
suministrando las actualizaciones sólo a los clientes, reduciendo por
tanto el público objetivo que recibirá los cambios. La jefa de seguridad
de Oracle, Mary Ann Davidson, considera que la técnica de ingeniería
inversa de parches no es accesible en masa todavía, y considera que
esta medida de distribución controlada les ayuda a paliar el problema.
Microsoft, y otras muchas empresas, reconocen que el tiempo de deducción
de vulnerabilidades por ingeniería inversa de parches está decreciendo,
y por tanto, están estudiando medidas para prevenir los efectos que las
vulnerabilidades detectadas puedan suponer para los usuarios finales.
Las empresas afectas normalmente argumentan que el análisis de parches
por ingeniería inversa no es fácil, y que la obtención de exploits una
vez analizado los cambios es una tarea compleja, lo que reduce el número
de sujetos capaces de realizar explotaciones a posteriori de fallos
corregidos.
De esta información podemos extraer dos conclusiones importantes: la
primera es que la reducción del tiempo entre la publicación de parches y
la aparición de exploits bien podría ser causa del avance en la rapidez
de obtención de información maliciosa por ingeniería inversa; y por otro
lado, parece más que obvio que el modelo de código abierto no incurre en
este problema, ya que la apertura del mismo hace accesible toda la
información a todos los estamentos, y esto revierte en una clara mejoría
en la gestión de vulnerabilidades.
El código cerrado tiene, en estos casos, un enemigo directo, y ése no es
otro que su propio oscurantismo.
shernando@hispasec.com
Más información:
Reverse engineering patches making disclosure a moot choice?
http://www.securityfocus.com/news/11235
Comparing binaries with graph isomorphisms
http://www.bindview.com/Services/Razor/Papers/2004/comparing_binaries.cfm
Sabre Security: Publicaciones sobre comparación de binarios
http://www.sabre-security.com/resources/publications.html
Deja una respuesta