Crimepack 3.1.3, ¿publicado? – Parte I

En el ultimo mes se han puesto a disposición de todos, diferentes Exploits Kits que por largo tiempo fueron las joyas de la industria del malware. Claros ejemplos de estos son: CrimePack 3.1.3, CrimeWare y Black Hole.

Estos paquetes de crimeware son montados en un servidor web y traen consigo varios exploits para navegadores como Internet Explorer, FireFox, Opera, y otros, así como también códigos maliciosos que explotan distintas vulnerabilidades en lectores PDF o JAVA.

Anteriormente la única forma de conseguir una muestra de éste era comprándolo en el mercado negro por valores como 800 dólares, o más, dependiendo de las prestaciones del kit. En el Laboratorio de Análisis e Investigación de ESET Latinoamérica descargamos la muestra de CrimePack 3.1.3 y nos hemos puesto en el trabajo de analizar el código. En la siguiente imagen se puede ver la pagina de instalación para este Exploit Kit:

Siguiendo el archivo README que trae consigo no es muy difícil de instalar, siempre y cuando se cumplan las dependencias del paquete, como por ejemplo un codificador para PHP, llamado IonCube. Ese codificador llamó poderosamente mi atención por el hecho de no existir ninguna documentación o método para desprotegerlo. Es por ello que en éste y varios post siguientes, veremos de qué se trata este protector comercial.

Como primera aproximación instalé todo el entorno en un Windows XP para poder debuggear el servidor Apache. Miremos un poco cómo quedan los códigos .php cifrados con esta herramienta:

La parte legible del código es la encargada de verificar que este cargada la DLL o el .so de IonCube, dependiendo de si  se trata un sistema Windows o Linux; o generar un error en caso de no encontrar la librería. La parte ilegible es nuestro código cifrado. Veamos las virtudes de este cifrado, a través de un análisis del mismo.

Con el OllyDBG me vinculo al proceso httpd.exe:

Luego, se coloca un breakpoint en la API MapViewOfFile. Se ejecuta y cuando se detenga el proceso se realiza un trace hasta la instrucción RETN:

Vemos que la función devuelve un puntero a nuestro archivo, permitiéndonos acceder al código cifrado para su posterior desencriptación. Si seguimos realizando un trace, un par de instrucciones más abajo podemos encontrar cosas interesantes como estas:

Dependiendo de los 4 primeros caracteres de la linea se ejecutan diferentes acciones que hacen uso de php5ts. Eso y el hecho de que haya un IonCube para cada versión de php existente, nos puede dar la pauta de que este protector no se encarga solamente de hacer ilegible el código, sino que lo interpreta directamente desde el código cifrado, imposibilitando la posibilidad de visualizar el mismo en memoria.

Claro que estas son suposiciones y para lograr romper IonCube se va a necesitar un estudio más minucioso de la protección, pero como primer acercamiento, ya podemos aunque sea notar a qué nos enfrentamos.

En estas pocas lineas he tratado de dejar plasmado una visión sobre la cantidad de seguridad que puede contener un código malicioso, impidiendo así su análisis manual, permitiendo que esté más tiempo operativo. Queda claro que el hecho de que se haya publicado el crimepack en cuestión no significa que se encuentre disponible su código fuente, restringiendo así la futura creación de posibles variantes.

Javier Aguinaga
Malware Analyst

Autor , ESET

  • interesante documento,ioncube me parece que trabaja en base 64 modificado, voy a probrar crimepack.
    Saludos.

  • Paul

    Excelente info. Thank u,

Síguenos