12 Comentarios para “Dí NO al polimorfismo.”

1. vmalvarez
   Comment por vmalvarez | 06/14/06 at 9:24 pm

   Una mora de Trípoli tenía
   Una perla rosada, una gran perla:
   Y la echó con desdén al mar un día:
   —«¡Siempre la misma! ¡ya me cansa verla!»

   Pocos años después, junto a la roca
   De Trípoli… ¡la gente llora al verla!
   Así le dice al mar la mora loca:
   —«¡Oh mar! ¡oh mar! ¡devuélveme mi perla!»

   José Martí

   Sé de un lugar donde deberían sentirse como la mora de Trípoli después de leer este paper. Muy bueno, muy currado ¿Podemos organizar un día una demostración? Me gustaría verlo funcionando.

2. ggonzalez
   Comment por ggonzalez | 06/14/06 at 9:47 pm

   Muy bien tio, es una pasada de trabajo, la idea, el analisis… awesome, como dirian por aqui

3. mballlano
   Comment por mballlano | 06/14/06 at 10:33 pm

   Como ya te había comentado me parece un artículo muy muy interesante! :-D, y creo que hoy en día podría dar muy buenos resultados en un entorno real, como ya has demostrado haciendo las pruebas con Morphine.

   Aún así el principal problema que le veo es que actualmente únicamente tienes planteado un análisis estático del código (solamente desensamblado) y aunque Morphine (por ejemplo) no está preparado para evitar que lo detectes, no sería realmente muy dificil hacerlo, simplemente imaginad que incluimos un pequeño stub muy reducido en tamaño y con una elección de las instrucciones a usar que eliga las frecuencias de los opcodes a usar de manera pseudo-aleatoria e incluso el tamaño del bloque, este mini-bloque de codigo se encargaría de añadir una capa polimórfica más al «engendro» y dificultaría terriblemente el análisis de este tipo, ya que quizá los datos estadísticos obtenidos no sean ya suficientemente identificativos. Otra opción para los desarrolladores de engines polimórficos es ir precisamente y concienzudamente contra esta estrategia y tener en cuenta también que la frecuencia de las instrucciones y sus «delta offsets» utilizados a la hora de generar código puede ser usada contra ellos, por lo tanto pasarían a «randomizar» también este aspecto del código.

   El siguiente paso bajo mi punto de vista, podría ser el uso de un emulador de código junto con esta estrategia, de manera que el análisis se podría realizar sobre las diferentes capas de un engine e incluso tomar otros datos que podrían ser útiles para la propia identificación, el problema de la emulación es que ya es más costosa y requiere un «tuning» más específico que la elección de samples únicamente ya que se requiere estudiar un poco el engine polimórfico en concreto y preparar unas pautas para que la emulación sea correcta, quizás se podría implementar algo genérico… se podría si no existieran tantas maneras de detectar a los diferentes emuladores de código disponibles en el mercado, si fuera algo genérico, con recolectar unos cuantos «tips&tricks» de estos, posiblemente evitaríamos que el engine fuera detectado, aunque pensando desde el punto de vista más coherente deberíamos disponer de emuladores que fueran muy dificilmente detectables .. 😉

   A consecuencia de este estudio que comentaba que sería necesario realizar para cada engine, si quisieramos usar un emulador, supongo que muchas veces el encargado de realizarlo encuentra «fallos» en el engine «firmas» concretas que pueden ser utilizadas de manera mucho más efectiva que un análisis como el que planteas, supongo que es por esto por lo que este tipo de tecnología quizá no esté muy arraigada en los engines de detección, aunque quien sabe…

   De cualquier manera me parece que debería ser un método más de detección disponible en los engines de análisis de los antivirus, el cual podría ser activado ante situaciones concretas ya que este análisis es costoso realmente, a fin de cuentas supongo que muchas veces se hacen detecciones de manera parecida pero menos «científica» en plan si el ejecutable tiene una sección que tiene estas características y veo un poco de «entropía» por aquí y tal y tal y cual… pues detectado.

   Conclusiónes:

   – Utilidad del artículo: (100%), infinitamente más que muchas de las bobadas que he tenido que leer ultimamente 🙂
   – Usabilidad : Estoy seguro de que un tanto por ciento bastante significativo de los engines polimorficos que se han programado hasta hoy serían detectables de esta manera :-), me gustaría tambien ver pruebas con los engines de z0mbie, el que usa el efish o el del marburg, sería interesante :-D.
   – Innovación: No estoy tan seguro de que seas el único que has pensado esto y que lo ha implementado, pero quizá si el primero que lo plantea de cara al público.
   – ¿Es esto el fin de los engines polimórficos, van a poder detectarse todos?: Lo siento pero no me lo creo ni de coña xDDD.

   En fin,,, un gran artículo y una gran lección para más de uno 😉

4. ggonzalez
   Comment por ggonzalez | 06/14/06 at 11:52 pm

   Y utilizando redes autoorganizativas?

5. Zohiartze
   Comment por Zohiartze | 06/15/06 at 12:22 am

   Da gusto, poder leer y sobre todo hoy en día, un articulo como este. Tengo que reconocer que algunas partes no las he podido entender del todo, en parte por que hace mucho que no he leido ni programado nada relacionado con redes neuronales, cuando tenga un poco mas de tiempo lo releeré buscando algunas cosillas en Google.

   De todos modos ¿el hecho de que el entrenamiento de la red sea supervisado no supone de por si un obstaculo importante para ofrecerlo como una solución AV? ¿Podría ser una red entrenada para detectar cualquier tipo de engine polimorfico (y diferenciarlo por ejemplo de un packer)?

   Igual voy a decir una tontería, pero si hoy en día los AV se bajan ficheros con signatures para identificar nuevos virus, tal vez en un futuro podrían bajarse signatures para entrenar la red neuronal segun las nuevas «amenazas» (¿se dice asi?) que surgan.

   En cualquier caso, muy buen paper. Gracias 🙂

6. ruben
   Comment por ruben | 06/15/06 at 2:05 pm

   A ver por partes.

   vmalvarez: Mi intención es liberar las aplicaciones pero estoy haciendolas legibles para el resto de los humanos xD. Dentro de un tiempo la colgaré.

   mballano: Pues puede sonar raro, pero es que es así. El polimorfismo es una técnica avanzada respecto a las técnicas actualmente usadas por los antivirus. El caso que tu planteas, en el caso hipotético de que alguien lo hiciera, podría ser detectado igualmente. El tema de las frecuencias y tal, es para este caso, multitud de características adicionales se podrían haber añadido. Bajo mi punto de vista, si los antivirus emplean esta técnica u otras mejores, el polimorfismo está muerto. Si se puede detectar la cara de un fulano de AlQaeda moviéndose entre 200.000 personaes en una estación de metro, ¿crees que no se puede detectar un engine polimórfico? Sólo hay que proponerselo.

   Zohiartze: Pues no veo el problema de usar aprendizaje supervisado. Vamos que toda la heurística de los antivirus se basa en el código que han analizado de todos los samples que han ido viendo. Entrenar una red neuronal con un aprendizaje no supervisado no creo que sea la mejor opción para un antivirus. No tiene mucho sentido creo. A parte, la complejidad crecería la oxtia y los resultados no se si iban a ser tan buenos como sabiendo realmente por donde atacar.

   Gracias a todos por los comentarios 🙂

7. mballano
   Comment por mballano | 06/15/06 at 2:36 pm

   Evidentemente, yo no digo que sea imposible detectar un engine polimórfico, Solo planteaba que únicamente con las características que has recogido no es viable detectar todos, aunque entiendo perfectamente que esto es un ejemplo. Y lo que planteo es que no importa que añadas X características a la red de análisis, porque seguramente siempre se pueda hacer un engine polimórfico en el que las características recogidas no sean suficientes como para detectarlo (igual que un tio de alqaeda se puede poner una careta xD), con lo que te tocaría añadir X características adicionales , lógicamente cuantos más vías de ataque utilices para recoger estos datos (por eso planteaba el uso de un emulador de código) y más datos significativos recolectes más posibilidades tendrás de tener éxito de deteccion de varios engines con la misma red de análisis.

   Creo que me explico, no sé si me confundo en algo .. 😕

8. ruben
   Comment por ruben | 06/15/06 at 2:56 pm

   Sobre cosas hipotéticas podemos estar discutiendo 4 años chacho xD. Que alguien saque un engine polimórfico que se salte este método y entonces podremos discutir qué es viable o qué no. El de AlQaeda tiene que llevar una careta del Bush.

9. Zohiartze
   Comment por Zohiartze | 06/15/06 at 4:08 pm

   No se, yo me imagino un AV instalado en mi máquina, con una red neuronal ya entrenada y que en un principio funcione correctamente. Pero si más adelante tiene que ir reconociendo más y más engines politomórficos, ¿como se puede predecir a priori, si cuando detecte los nuevos engines no va a dejar de detectar los viejos? Hasta donde yo sé, no puedes predecir como va a converger la red neuronal, supongo que ese es uno de los motivos para que las compañias AV no hayan ofrecido todavía una solución de este tipo. No pueden arriesgarse a dejar un día a sus clientes más en pelotas de lo que ya les suelen dejar normalmente…

   Por cierto, ya que todo es byte y no todo es seguridad informática y virii, a una red neuronal de este tipo, tal vez se le podrían dar también otro tipo de usos 🙂

10. ruben
    Comment por ruben | 06/15/06 at 4:22 pm

    Zohiartze, la estructura de un antivirus soportando «neural signatures» sería un engine que las interprete y en vez de signatures, la red neuronal. Una red neuronal una vez entrenada se puede guardar como si fuera una signature. Es decir, imagínate que salen 4 worms con engines polimórficos diferentes. Pues venga, entrenamos 4 redes neuronales, guardamos los pesos y la topología de cada una en nuestro formato «antiviruschiniwini» y se las subimos a los usuarios como el que sube una signature. No se si me he explicado.

11. Zohiartze
    Comment por Zohiartze | 06/15/06 at 4:53 pm

    Ok, ahora creo que sí. Tienes una topología de red neuronal por cada engine polimórfico que quieras detectar. Despues alimentas la entrada de cada una de las redes con el binario en cuestión hasta ver si alguna de ellas da un positivo.

    Yo estaba pensando en una única red que detectase genéricamente todos los tipos de engines polimorficos, perdón por la confusión, creo que estaba mal-influenciado por mi ignorancia en estos temas 😛

12. mballano
    Comment por mballano | 06/15/06 at 8:02 pm

    Creo que antes no me has entendido rú, vamos, que tampoco me he expresado correctamente xD, es precisamente lo que comentaís a lo que me refería, que para cada engine polimórfico puede ser que tengas que variar la topología de la red neuronal, aunque probablemente una topología te valga para más de uno.

    De todas maneras, como comentaba anteriormente, yo creo que algunos engines polimórficos no se podrían detectar con una topología que solamente tenga en cuenta datos de un análisis estático, quicir, que podría ser necesario tener en cuenta datos que provengan de un emulador de código, pero que si entiendo bien podrían ser incluidos perfectamente en una nueva topología (emulas lo necesario) recoges lo que quieres y se pasa a la red neuronal, ¿no?.

Se han cerrado los comentarios