Exploits a partir de ingeniería inversa de parches

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.