Español | English
rss facebook linkedin Twitter

Análisis de capturas de tráfico – parte I: Disección

Preliminares
a todo el mundo le gustan, pero alguno se los saltan con una facilidad..

Después de haber leído un número elevado de respuestas a la pregunta de Ion sobre las preferencias de los tipos de posts del blog, parece ser que las entradas de nivel técnico elevado escasean un poco. Vamos a intentar arreglarlo a ver si conseguimos que el interés no decaiga.

En esta ocasión, y sin que sirva de precedente me cambio la gorra de SCADA por la de malware, sin ningún motivo en particular salvo el hecho de que me viene mejor para resumir el tema de este post. Desde hace tiempo venimos trabajando con wireshark para analizar tráfico en Infraestructuras críticas, y la primera crítica de todas es la ausencia de “dissectors” para algunos de los protocolos conocidos y para ninguno de los protocolos propietarios, y para poder trabajar de forma razonable es necesario hacerlos (o conseguir que te los hagan).

Claro que, como quiera que soy muy receloso (unido al hecho de que no quiero que mi jefe me persiga por toda la oficina) nos guardamos los dissectors de SCADA, y cambiamos la temática del post a Malware. Aunque el protocolo que vamos a mostrar en este post aún está en uso, corresponde con una versión vieja de un troyano de sobra conocido (por varios nombres). El equipo de ecrime nos ha cedido el material (la captura) y el conocimiento (Josemi, que pongo aquí XD) del troyano en cuestión para poder completar el resto del post.



Desnudando el objetivo
Aunque no lo parezca, a veces si te puede ayudar alguien, mejor..

Y sin más retraso, empezamos con la primera de las imágenes, a todo el mundo le gustan las fotos. Partiendo de la captura que podréis encontrar en este enlace:


Así es como se ve el tráfico del troyano tal y como viene el wireshark de fábrica:


Eso que aparece en esa captura del wireshark es un paquete enviado por un troyano a su centro de control, informándole de algo. Veamos un poco más de cerca el contenido del “paquete”.


Aunque seguro que no me equivoco si afirmo que hay gente capaz de interpretar esa petición HTTP sin tener ni que usar una calculadora, para los mortales como yo no se recomienda este tipo de prácticas, aunque básicamente toda la comunicación se encuentra en la URI de una petición POST enviada al panel de control.

Existe información suficiente en internet para conseguir descifrar el galimatías de la URI en cuestión, así que el siguiente paso natural sería programar algo con lo que poder ‘ver’ que es lo que se esconde en el.. ‘paquete’.

Para continuar con el siguiente punto habría que explicar las diferentes formas de programar un disector para wireshark, pero como dejaría de ser un post técnico no lo voy a hacer. Quién quiera conocer las otras formas en la documentación de wireshark encontrará casi todo lo que está buscando. Sin necesidad de dar un porqué, el disector sobre el que trabajaremos será en LUA (Por si alguien necesitara también leerse la documentación sobre como habilitar LUA en wireshark, os dejo este enlace: Lua en wireshark).

Ah, he olvidado decir que el troyano en cuestión es Sinowal (también conocido como Anserin o Torpig). Algunos habrán reconocido la versión incluso, pero tengo que decir que en concreto hemos elegido este porque la comunicación analizada es antigua, y ahora utiliza una un poco más robusta. En cualquier caso es seguro que aún quedan bastantes equipos infectados con versiones que utilizan este tipo de comunicación. Podréis encontrar información adicional sobre el análisis de este troyano aquí:




Veamos que hay dentro
Mirar nos gusta a todos..

No voy a entrar en detalle de cómo funciona el troyano, este post se centra en la disección de su comunicación, aunque para entender partes del disector es necesario saber interpretar la URI una vez descifrada. El disector en cuestión lo podréis encontrar en este enlace:


Prestando atención a la función de descifrado de la URI :


La cadena utilizada en la URI en este caso es así:

oGJmlWUXX1QV/jQub+tw9BUjZiXB0rsSwAwhuy0cUmYncpYA1Kda0NUuRQ3q3gBQMEImZaBS2mWQD7RaOhuloeAGYrBFx1o1EKvR634fwDUEI+bVMVLaNaE7oDsq6zGkUUKWcQU=

Y una vez descifrada queda en algo más legible:

ts=0&ip=10.0.0.179:&sport=9950&hport=9920&os=5.1.2600&cn=Spain&nid=3AEFBA86C8B89862&bld=eagle&ver=229

La lista de campos que contiene la URI depende de la comunicación que realiza el troyano con el panel de control, pero nos centraremos en este tipo de tráfico: un ping del agente al servidor:

  • Ts es el timestamp de la última actualización del servidor
  • Ip es la dirección de la tarjeta de red del equipo
  • Hport y Sport son los puertos de comunicación del troyano y del servidor
  • OS es la versión del sistema operativo del equipo infectado
  • CN es el país (obtenido por el lenguaje configurado) del equipo infectado
  • Nid es el identificador único del troyano
  • Bld y Ver indican la versión del software del troyano
“Al tema”
Mirar está bien, pero luego el cuerpo pide más. Seguramente muy pocos se salten este paso..

La siguiente imagen muestra un extracto del código del disector para el troyano Sinowal.


Sin entrar muy en detalle por cada línea de código, este trozo en concreto se encarga de crear la información suficiente para disponer de la ‘infraestructura’ suficiente como para interactuar con wireshark y poder mostrar el resultado de la “disección”.

Nos hemos creado una preferencia que permite activar/desactivar el disector.


También nos aseguramos que el sistema de filtros de visualización de Wireshark comprende los campos de nuestro protocolo (aquí ya requiere conocer un poco más la comunicación del troyano).



O incluso podemos usar el filtro rápido


Todo esto por sí solo no hace nada, pero nos proporciona el interfaz entre el wireshark y el usuario. El siguiente paso lógico sería interpretar los datos y rellenar los huecos reservados en este interfaz. Para eso primero necesitamos acceder a la URI del paquete (que está siendo diseccionado por el responsable de gestionar el tráfico HTTP).


Con este código se crean las funciones necesarias para leer los campos que (en esta implementación) es necesario leer. El método y la longitud se utilizan para determinar que es un POST de 0 bytes de contenido y discriminar el resto de peticiones HTTP que obviamente no son del troyano. El host se utiliza para identificar el panel de control y la URI para descifrarla y obtener los datos de la comunicación.

Una vez procesada (des-base64-ada, des-xoreada, des-invertida, des-hex-convertida, parseada y devuelta como un array en s_info), se crea una entrada en el panel de disección, y esta entrada pondremos los valores de los campos del protocolo utilizado por sinowal. Además, para mejorar la información visible en tiempo real, se modifican las columnas ‘Protocolo’ e ‘Información’ de la lista de paquetes por un mensaje de más alto nivel interpretando la comunicación del troyano.


l

El código anterior ha completado la información en el interfaz que habíamos creado anteriormente, por lo que ahora sería posible ver el tráfico con mayor claridad, esto es otra cosica ya, ¿eh?


Y en cuanto al contenido de la URI, madre mía la que puedes liar con esto.. ¡qué gráficos!!


Un factor importante es el hecho de que podamos utilizar el resto de funcionalidades de Wireshark, como por ejemplo los filtros de visualización con los campos de nuestra disección




Y antes de salir del bar, pagar
Ya casi hemos terminado.

El contenido del adjunto de este post incluye el script en LUA con el disector del Sinowal y una captura con un ping al panel de control. El script no está completo, aunque es funcional, obviamente no incluye todo el código relacionado con el análisis de la URI, pero sí que incluye lo necesario para finalizarlo, así como para hacer otro disector de otro protocolo, que venía a ser el objetivo del post.

Para acabar de entender las funciones del disector es necesario entrar en demasiado detalle, algo a lo que los comentarios del código os ayudarán, estoy seguro.

Para los del full-disclosure, las direcciones IP de la captura son direcciones reales, tan reales como la captura, vamos.. Eso si, ni las imágenes son lo que son, ni la captura es lo que es, ni el disector en LUA es lo que parece ser, si alguno se aburre y quiere echarles un ojo, notará ciertas diferencias entre los archivos y el post, y si consigue enlazar las piezas habrá resuelto un reto oculto en este post.

Bueno, y ahora que les hemos hecho la cama a los de malware, a ver cuando tienen ellos el valor suficiente para escribir un post de SCADA

Iñaki López – S21sec Labs.

PD1: Cualquier contenido no relacionado con seguridad es debido únicamente a la estación primaveral.
PD2: Ion, nosotros no podemos participar en los sorteos, no es justo!


1 comentario:

mgesteiro dijo...

interesante entrada :)
bien por el giro!


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login