La ingeniería inversa y el malware
Muchas veces la utilización de la Ingeniería Inversa es la forma que los creadores de malware tienen para desarrollar sus nuevas amenazas.Una de las principales formas de mantenerse a salvo del ataque de los miles de códigos dañinos existentes es la actualización del software y de los sistemas que utilizamos a diario.
Para ello siempre es recomendable recibir y descargar las actualizaciones desde los CD o del sitio web del fabricante del sistema tratado.
Así por ejemplo, Microsoft lanza actualizaciones de su software el segundo martes de cada mes, por lo que sería recomendable configurar Windows para descargar y actualizar sobre esa fecha.
Paradójicamente, muchos de los códigos más dañinos nacen inmediatamente después de que aparece una actualización por parte de la empresa fabricante del software. A modo de ejemplo puede verse la fecha de aparición de una actualización determinada y luego la cantidad de días que pasan hasta la aparición de gusanos ampliamente difundidos.
| Actualización | Fecha Actualización | Gusano | Fecha Gusano | Días transcurridos |
| MS01-033 | 18/06/2001 | CodeRed | 16/07/2001 | 28 |
| MS01-044 | 15/08/2001 | Nimda | 19/09/2001 | 34 |
| MS04-034 | 10/07/2002 | SQLSlammer | 26/01/2003 | 196 |
| MS03-026 | 16/07/2003 | Blaster/Lovsan | 12/08/2003 | 26 |
| MS04-034 | 14/04/2004 | Sasser | 01/05/2004 | 17 |
| MS05-039 | 11/08/2005 | Zotob | 15/08/2005 | 4 |
Gráficamente podemos observar que a medida que pasa el tiempo, la cantidad de días transcurridos desde que aparece una actualización hasta que aparece un gusano es menor.
Hasta aquí, todo haría pensar que el desarrollo de actualizaciones propicia la creación y aparición de nuevos códigos dañinos. Sin embargo este hecho tiene otra explicación razonable y bajo ningún aspecto debe considerarse negativo el desarrollo de actualizaciones y el parcheo de una aplicación.
Los creadores de malware siempre están buscando nuevas formas de perfeccionar y acelerar sus creaciones. Una de estas formas es lo que justifica lo antes mencionado.
Al encontrarse una vulnerabilidad, el fabricante del software revisa el código de la aplicación que se trate y generalmente después de un tiempo lanza una actualización sobre dicho código. Esta corrección puede llegar en horas o tardar meses dependiendo de la criticidad del error, la empresa desarrolladora y la política que la misma tiene frente a las vulnerabilidades.
Esto es lo que generalmente se conoce como “parche” y no es más que una corrección sobre el código fuente del programa afectado. Por supuesto este código fuente se compila y luego se informa a los usuarios que se encuentra disponible la actualización para su descarga.
De esta forma, todas las personas (incluidos los creadores de malware) tienen acceso a la actualización, que generalmente constará de cierta cantidad de programas compilados (.DLL, .EXE, .BIN, etc.) que se copiarán al sistema, reemplazando las versiones vulnerables anteriores.
Cuanto mayor sea la criticidad de la vulnerabilidad y si la misma permite realizar ciertas acciones dañinas sobre un sistema no parcheado, mayor será el atractivo de esta vulnerabilidad para un atacante.
Aquí entra en juego la Ingeniería Inversa, consistente en observar como se comporta un objeto determinado para conocer su funcionamiento. Extrapolando esta definición al software, es “ver” el código compilado para llegar al origen del mismo.
Contrario a lo que se suele pensar este proceso de “determinar el funcionamiento de las cosas” es legítimo y legal si se realiza con los fines y medios adecuados. No se debe confundir la ingeniería inversa con la decompilación y copia (plagio) del código fuente, si bien la decompilación puede ser una herramienta utilizada en el proceso de ingeniería.
A modo de ejemplo se puede citar el software ofimático OpenOffice, el cual es desarrollado a partir de ingeniería inversa de Microsoft Office ya que este último es un código compilado, cerrado y no liberado al público.
Siguiendo con las actualizaciones de software y sabiendo como funciona la ingeniería inversa es fácil adivinar como sigue la historia. Al lanzarse una actualización se corrigen cientos/miles de líneas de código en el programa original pero al compilarse el atacante no tiene forma de conocer cuáles han sido.
Para conocer este dato, el creador del malware, realiza ingeniería inversa sobre el código compilado vulnerable y luego sobre el corregido. De esta forma se obtienen las diferencias y es posible conocer dónde estaba la vulnerabilidad original
Gráficamente:
Como puede observarse, parte del código ha sido reemplazado, indicando claramente que ese es el error corregido.
Con esta información y con el problema exactamente acotado el creador del malware puede escribir un código dañino capaz de afectar a sistemas que no han sido parcheados.
Además, como se vio en el gráfico los creadores de malware han obtenido la experiencia suficiente para lograr que el tiempo de análisis (ingeniería inversa) y desarrollo del código dañino sea mínimo (y siga disminuyendo) desde la aparición del parche.
La corrección de una vulnerabilidad aparentemente favorece al creador del malware y le facilita la tarea. Esto es así en el caso que el usuario no actualice su sistema y no significa que las empresas desarrolladoras no deben corregir su software. Luego, si el usuario instala la actualización desarrollada, nada tendrá que temer.
Para el usuario final esto no implica mayor esfuerzo que descargar e instalar la versión corregida. En cambio, en entornos corporativos la instalación de actualizaciones debe evaluarse dependiendo la criticidad y riesgo de la misma, luego debe probarse en entornos montados para ese fin, y por último, instalarse en los entornos productivos.
Luego, el principio es que toda actualización debe instalarse en el menor tiempo posible, que será “de inmediato” para el usuario final y “cuanto antes” para una organización.
Los errores y vulnerabilidades deben corregirse y el usuario debe actualizar su sistema tan pronto sea posible.
