En este artículo voy a escribir un poco sobre lo fácil que es burlar la protección de un antivirus sin tener que recurrir a técnicas complejas y algoritmos "vanguardistas" como encoders, polimorfismos, metamorfismos y demás ingenios, que muchas veces nos llevan a la falsa creencia de que un posible intruso o creador de malware debe ser un genio de los ordenadores, y como hay pocos genios es difícil que nos toque. De hecho un gran porcentaje de incidentes de seguridad se produce aprovechando vulnerabilidades o malware antiguos, que a priori todo antivirus detectaría fácilmente de no haber sido modificados.
Eso, sumado a la falsa seguridad que nos proporciona el software como los antivirus o firewalls hace que la gran mayoría de la gente no preste la atención que debiera a la seguridad de sus sistemas (ya no vamos a entrar en el recalcado tema de cómo escoger una buena contraseña).
Se invierten millones de euros en investigación de protecciones de seguridad informática y existe todo un gran mercado en torno a ello, pero al final del día el mejor antivirus, y la mejor protección que "podría" existir para nuestros ordenadores es el propio usuario (aunque desgraciadamente, todavía siga siendo lo contrario). Muchas veces me han pedido consejo para escoger un antivirus, o me han preguntado que antivirus utilizo, y cuando yo contestaba "ninguno" se quedaban un poco sorprendidos. Si bien hoy en día si utilizo, es verdad que he estado muchísimos años sin utilizarlos.
A lo que quiero llegar es que fuera del mundillo de la seguridad informática, se sigue confiando la seguridad un 100% a programas como los antivirus, la gente se siente protegida con ellos, lo cual es contraproducente. Pequeñas cosas como mantener actualizados todos nuestros programas, ser cuidadosos con las cosas que descargamos o controlar que servicios tenemos corriendo en nuestras máquinas en cada momento quedan relegados a un segundo plano (muchísima gente ni siquiera le da importancia a no actualizar), aunque no infalible, minimizan mucho los riesgos, convirtiendo un antivirus en una capa de protección más, y no en la más importante.
Dicho esto, y después de asustar un poco a los no iniciados (esa era la intención), entremos al lío.
De todos es sabido que los antivirus basan casi el 90% de su detección en la búsqueda de signatures, partes de código reconocibles como maliciosas o sospechosas se que van actualizando en sus bases de datos de firmas según se descubren nuevos virus o exploits.
Para camuflar este tipo de firmas en malware, una de las cosas que más se están utilizando son encoders de todo tipo, que manipulan ese código detectable convirtiendolo en otro diferente que hace la misma función, pero a la larga esos encoders se vuelven inefectivos porque siguen un patrón que puede detectarse con análisis heurístico. Incluso el famoso y polimórfico shikata ga nai es inefectivo hoy en día, por muchos pases que se apliquen.
Por regla general, un antivirus realiza el análisis de los archivos tanto cuando se escriben en disco como cuando son ejecutados, pero no monitoriza toda la ejecución del mismo, porque eso requeriría de unos recursos de los que una máquina normal hoy en día no dispone (imaginad que cada vez que se ejecutase un Photoshop u otro programa intensivo computacionalmente, el AV tuviese que monitorizar en todo momento todas las operaciones que realiza).
Sin embargo existen técnicas que le pueden poner las cosas muy difíciles a un antivirus, incluso a los análisis heurísticos, y que sólo un análisis exhaustivo por parte de un humano en un entorno sandbox podría detectar (algo impensable para la detección en tiempo real).
Algo de lo que adolecen los antivirus es que analizan los archivos independientemente, y no como un conjunto de archivos que forman una pieza de software. Y desgraciadamente deben hacerlo así para evitar multitud de falsos positivos.
Por ejemplo, en uno de los últimos exploits Java (CVE-2012-1723), compuesto por varias clases empaquetadas en un jar, detectaba la firma sólo en dos de ellas, donde se ejecutaban las funciones sospechosas, con lo que separando esas firmas en clases diferentes se podía anular la detección muy fácilmente.
Sin entrar en detalles, este exploit se basa en type confusion, asignando una clase con funciones que requieren privilegios de sistema a otra clase de distinto tipo que no los requiere, saltándose el sandbox java de ese modo. El antivirus detectaba el exploit en la clase que forzaba la confusión (llamemosle confusor), y en un par de líneas de código de otra clase, donde se creaba la instancia del confusor (probablemente para detectar variantes del exploit donde el confusor fuese diferente).
No fue necesario utilizar ningún tipo de ofuscación de clases sobre el exploit:
Para el confusor bastó con cambiar un bucle for de 100 iteraciones por 110 para que el antivirus ya no lo marcase como peligroso.
En cuanto a la clase donde se creaba la instancia de forma reflectiva, el AV lo detectaba cuando estas dos líneas aparecían juntas en el mismo archivo, pero separandolas de una manera extremadamente trivial, neutralizamos totalmente lo que el AV daba por sentado como malicioso:
Como se puede apreciar, realizando pequeñas modificaciones al código, y sobretodo separando las partes del código sospechosas en diferentes lugares es muy sencillo desaparecer de la lista de firmas del AV. De este modo y con un poco de creatividad podríamos ocultar incluso ROP chains, heap sprays..., pilares de muchos exploits modernos.
Para continuar, y ya que hemos utilizado el exploit java para demostrar cómo evadir el antivirus durante la fase de explotación, vamos a ver como ocultar también un payload, ya que las shellcode más comunes suelen ser detectadas per se como firmas.
Hemos modificado el código del exploit de java para evitar el antivirus, pero en cuanto añadiesemos a la ecuación nuestra shellcode (por ejemplo un meterpreter https reverso), volvería a ser detectado. Dado que el exploit en java no nos limita en tamaño a la hora de weaponizarlo con un payload, y como ya nos hemos saltado el sandbox java, ¿por qué ejecutar la shellcode directamente desde el exploit, cuando podemos volcar un ejecutable a disco y lanzar la shellcode desde allí? Podría parecer una estupidez hacer una escritura a disco dando al AV una oportunidad extra de análisis, pero como veremos más adelante evitar la detección de la explotación asumiendo ese riesgo tiene sus ventajas si nos encargamos de ocultarlo bien en la fase post-exploit, donde contamos con más flexibilidad para hacerlo.
Como se puede apreciar, hemos convertido los binarios en cadenas de texto (los he truncado por legibilidad), los hemos almacenado en variables (separados en dos mitades), y los recodificamos a binario antes de escribirlos a disco, consiguiendo que el AV no los detecte al analizar el paquete Java.
Con eso ya estamos separando el payload del propio exploit (recordad, separación es la clave), pero tendremos que conseguir que el payload sea también indetectable.
Para ello vamos a utilizar varios trucos. En primer lugar, cogeremos nuestra shellcode y la partiremos en 2 mitades (una vez más). Con eso ya sería suficiente, pero para este ejemplo, además, he creado un sencillo "encoder" que hace rotaciones de bits en cada byte de la shellcode y luego los invierte, con la intención de camuflarla un poco. Así que ya tenemos dos mitades de nuestro meterpreter, previamente scrambled con el miniencoder.
Si sólo utilizaramos el encoder sobre la shellcode entera, el antivirus podría reconocerla con algo de heurística, pero de este modo aunque aplique la heurística a cada mitad, no se encontrará con la shellcode completa, con lo que no la reconocerá como firma.
Podríamos crear un sencillo ejecutable que lanzase esa shellcode, pero aquí vamos a utilizar otro truco para engañar aún más.
Crearemos un ejecutable normal (payload.exe), con una función trivial que no haría saltar jamás al antivirus, porque no realiza ninguna acción sospechosa, pero utilizaremos unas librerías dinámicas para sobreescribir esa función trivial con nuestra shellcode en tiempo de ejecución, y ya en memoria:
Debemos configurar el compilador para que no utilice el NX/XD (DEP) ni base dinámica (ASLR), de este modo la dirección de memoria que sobreescribiremos en nuestro programa no variará en cada ejecución, ni la memoria estará desorganizada por el ASLR, lo cual sería un problema para escribir secuencialmente.
Como veis, y para esta demostración, la función inofensiva() está compuesta por una serie de NOPs (o cualquier otra cosa), para hacerla más fácil de encontrar en nuestro debugger, y debe tener el tamaño suficiente para albergar nuestra shellcode una vez la sobreescribamos.
Lo ejecutamos en el debugger para localizar la dirección donde comienza dicha función:
Dado que en este caso el programa comienza a ejecutarse en 400000, nuestro offset para comenzar a sobreescribir será 53F0, que es el punto de entrada de la función.
Un análisis por parte del antivirus sobre el ejecutable no revelaría nada ya que el código de la shellcode no sobreescribe la función inofensiva() hasta que cargamos las librerías.
Como hemos partido la shellcode en 2 mitades, crearemos dos DLL (shellcode1.dat y shellcode2.dat), una con cada mitad (una vez más, separación), de este modo el AV aunque analice cada DLL en disco, no encontrará nada.
En MY_OFFSET establecemos la posición de memoria en tiempo de ejecución donde debe empezar a sobreescribir. Decodificamos nuestra media shellcode anteriormente “revuelta”, y la escribimos donde estaba la función inofensiva().
VirtualProtectEx, así como otras que permiten API hooking, es una de las funciones más vigiladas por un antivirus dado que abre las puertas a escribir en memoria en tiempo de ejecución, pero como hemos dicho antes, solo estamos escribiendo media shellcode, y es por esa razón por la que no saltará la alarma, y es a lo que me refería con que un antivirus escanea archivos independientes, y no como un conjunto.
También habréis notado que utilizo sleeps para pausar la ejecución. Es solo una sospecha personal infundada, pero aunque retrasa la ejecución del payload creo que algunos antivirus (especialmente los que quieren vendernos que casi no comen recursos al ordenador) dejan de analizar si el proceso que monitorizan es lento, especialmente si es un bucle, para ahorrar recursos y no interferir en la experiencia del usuario. Y también para tratar de que el AV no “relacione” una función con la anterior, aunque supongo que eso ya es un raciocinio humano que no se aplica a una máquina ;)
Para la segunda DLL, solo tenemos que cambiar la segunda mitad de la shellcode y el offset para continuar escribiendo en la posición donde terminó la primer mitad.
Algo que podríamos hacer para enrrevesarlo aún más (aunque para no complicarlo demasiado no lo hemos hecho aquí), sería empezar escribiendo la segunda parte de la shellcode, y luego la primera (simplemente invirtiendo el orden en el que hacemos el LoadLibrary), con lo cual nos curamos en salud ante un posible análisis secuencial de lo que estamos escribiendo en memoria.
Ya para terminar, vamos a añadir una capa más de separación, utilizando un ejecutable (spawner.exe) , el cual es el verdadero ejecutado por nuestro exploit java y que será el encargado de lanzar el payload (Nota: he hecho esto porque a día de escribir el código, el reverse https terminaba el proceso al cabo de unos minutos si no se establecía una conexión):
Este pequeño programa también es inofensivo a los ojos del AV, y lo único que hace es monitorizar si existe el proceso de nuestro payload, y si no es así, lo relanza.
Además, como hemos creado una entrada en el autorun del registro (lo cual podría resultar sospechoso para el AV), siempre es mejor que el "sospechoso" sea este nuestro spawner inofensivo, y no el que carga las librerías del payload.
Resumiendo:
- Hemos lanzado nuestro exploit en java, ya modificado, con lo cual el antivirus no lo ha detectado.
- El exploit ha volcado 4 archivos al directorio temporal de Windows. El AV los analiza en el momento en que se escriben a disco. Dos de ellos son ejecutables inofensivos, con lo cual no los detecta. Los otros dos son las librerías donde está la shellcode, pero son dos archivos independientes, el AV tampoco detectará una shellcode completa.
- Se ejecuta nuestro lanzador inofensivo, el AV no lo detecta en la ejecución. Se ejecuta el payload lanzado, y el AV analiza qué trata de hacer (una función inofensiva), también analiza las DLL al cargarlas (pero cada una realiza la sobreeescritura por separado, tampoco las detecta). Llegado ese punto la shellcode ya está reemplazando la función inofensiva(), pero el AV ya no puede detectarlo, ya que para ello tendría que volver a analizar la ejecución completa del programa en memoria y darse cuenta que el código fue sobreescrito, algo que requeriría muchos más recursos, y que en un programa más complejo sería demasiado intensivo.
Hemos engañado al antivirus sin rompernos la cabeza con algoritmos imposibles, simplemente separando código malicioso en diversos trozos y lugares, y ejecutandolo de una forma poco convencional (sobreescribiendo una función ya existente). Podríamos haber utilizado otros trucos sencillos, como crear un programa con un overflow deliberado y explotarlo para lanzar la shellcode (algo que el antivirus jamás se "imaginaría"), en lugar de integrarla en el propio programa como una función más.
En el hipotético caso de que esto fuese un malware real, ya conocido, y con las firmas añadidas a un antivirus, bastaría con partir en más trozos todavía el código para que el AV dejase de detectarlo, y se convertiría en el juego del gato y el ratón.
¿Soluciones? Pues es bastante complicado. Para que los antivirus pudiesen conseguir una detección robusta no basada en firmas conocidas deberían ser capaces de monitorizar todos los procesos que ocurren en una máquina en todo momento, de relacionar esos procesos entre si de forma racional, tendrían que ser capaces de descubrir automáticamente vulnerabilidades en los programas (sin saber de antemano que las tienen); en definitiva, ser una inteligencia artificial que a día de hoy solo es ciencia ficción. Y necesitarían utilizar prácticamente la totalidad de los recursos de la máquina dejando una pequeñísima parte para el resto de procesos.
----------------------------------------------------------------------------------------------------------------
Artículo cortesía de Antonio Rodríguez (MoebiuZ)
