miércoles, 7 de abril de 2010

Desenmascarando una botnet mediante el uso de criptoanálisis

En los últimos tiempos estamos asistiendo a un auge significativo de botnets, puestas a la disposición de actividades fraudulentas, como pueda ser el robo masivo tanto de credenciales de banca online como de tarjetas de crédito.

Dada la rentabilidad, derivada de las actividades maliciosas, facilitada por una botnet, las mafias no escatiman esfuerzos en la utilización de técnicas que permitan prolongar tanto su tiempo de vida como el aseguramiento de su control.

En el presente artículo se va a desenmascarar el comportamiento de una botnet mediante el análisis del tráfico de red generado por la misma, a pesar de la utilización de técnicas criptográficas que dichas botnets puedan estar utilizando.


Análisis del comportamiento

Para analizar el comportamiento de la botnet, el primer paso será determinar bajo qué circunstancias un zombie transmite información al botmaster. Esta labor puede ser realizada mediante la utilización de un sniffer, con el objeto de identificar conexiones salientes, hacia destinos no estipulados.

En el ejemplo que acontece se puede identificar que, durante el proceso de autenticación en un entorno de banca online, y adicionalmente a las conexiones propias entre el cliente y el entorno bancario, existe una serie de conexiones colaterales y susceptibles de estar relacionadas con una botnet.

Figura 1. Ejemplo de control de acceso al entorno de banca online


Figura 2. Ejemplo de tráfico susceptible de estar relacionado con una botnet


Como se puede observar en la imagen anterior, inicialmente no se aprecia una capa de cifrado. Sin embargo, como se puede observar en la siguiente figura, los dados transmitidos son susceptibles de estar protegidos por algún algoritmo criptográfico, ya que el tráfico HTTP capturado no se corresponde con el texto plano que caracteriza a dicho protocolo.

Figura 3. Indicios de tráfico cifrado en las comunicaciones entre el zombie y el botmaster


En la actualidad existe toda una variedad de algoritmos de cifrado, comúnmente utilizados, que podrían estar siendo utilizados por la botnet:

  • Algoritmos de cifrado simétrico por bloques, como por ejemplo DES, IDEA, blowfish, AES, etc.

  • Algoritmos de cifrado simétrico por sustitución, trasposición o polialfabetos, como por ejemplo Cesar, ROT13, Vigenere, Vernam (XOR), etc.

  • Cifrado asimétrico basados en la factorización de grandes números primos (como podría ser RSA), cálculos de logaritmos discretos (como por ejemplo ElGamal) o incluso cálculos basados en la utilización de curvas elípticas.


Mediante el análisis diferencial de las capturas de red, obtenidas mediante la repetición de un mismo suceso (introducción de mismo login/password en el entorno de banca online), se puede observar que, en apariencia, la botnet no realiza un cálculo de claves pública-privada (como podría ser la utilización del algoritmo Diffie-Hellman, MTI/A0, STS o derivados), ya que tanto el zombie como el botmaster siempre comienzan sesión con los mismos mensajes. Es por ello que se descarta que la botnet esté utilizando criptografía asimétrica.

Por otro lado, el análisis diferencial indica que, en función de ligeras variaciones en los patrones de login y password introducidos en el entorno de banca online (véase figura 1), el zombie envía al botmaster criptogramas ligeramente diferentes en cada repetición efectuada. Este comportamiento indica que las diferencias identificadas en los datos transmitidos contienen, total o parcialmente, el login y/o password introducido.

Figura 4. Parte variable del criptograma enviado por el zombie al botmaster en repetición 1.


Figura 5. Parte variable del criptograma enviado por el zombie al botmaster en repetición 2.


Identificando las diferencias, marcadas en rojo, entre la figura 3 y la figura 4, puede observarse dos hechos clave:

  1. El algoritmo criptográfico utilizado no proporciona una dispersión adecuada al sistema criptográfico. De lo contrario, la variación de un único bit entre diferentes logins y/o passwords, habría desencadenado alteraciones propagadas a la totalidad del criptograma, y no sólo a una parte del mismo.

  2. El algoritmo criptográfico utilizado genera criptogramas de longitud proporcional, y lineal, al tamaño del login y/o password utilizado en cada momento.

El hecho 1 descarta la utilización la mayoría de algoritmos “serios” de cifrado simétrico conocidos, incluyendo DES, 3DES, IDEA, Blowfish, AES, etc.

El hecho 2 descarta la utilización de algoritmos de cifrado simétrico basados en bloques.

Una vez se han acotado las posibilidades de cifrado de las comunicaciones, se procede a la utilización de ataques criptográficos para revelar la clave de cifrado.


Ataque “Choosen Plain Text Attack”

Choosen Plain Text Attack” es un ataque válido contra sistemas criptográficos, siempre y cuando el atacante conozca el texto en claro (login y/o password) y su correspondiente criptograma (patrones diferentes identificados en el análisis diferencial). Por lo tanto, se cumplen las condiciones necesarias para intentar utilizar este ataque contra la clave utilizada en el algoritmo de cifrado simétrico, para lo que se utilizará el siguiente caso de uso:

  • Captura de red mientras se accede al entorno online mediante el login: AAAAAAAAAAAAAAAA y el password: AAAAAAAAAAAAAAAA

Figura 6. Elección de texto en claro


El hecho de seleccionar dicha combinación de login y passwords facilita lo siguiente:

    • Tanto los textos en claro del login como del password, al ser idénticos, permite la identificación criptogramas repetidos. De este modo se identifica en que porción del criptograma reside el login y el password:

Figura 7. Identificación de criptogramas candidatos a pertenecer al login y password


Sobre el criptograma anterior podemos identificar claramente la repetición del patrón: 0x70,0x32,0x24,0x22,0x33,0x24,0x35, el cual se repite durante un total de 32 bytes (los mismos que suman el login y el password en el texto en claro). Esto significa que el login “AAAAAAAAAAAAAAAA”, una vez cifrado podría ser:

0x70,0x32,0x24,0x22,0x33,0x24,0x35,0x70,0x32,0x24,0x22,0x33,0x24,0x35,0x70,0x32

y el el password “AAAAAAAAAAAAAAAA”, una vez cifrado podría ser:

0x24,0x22,0x33,0x24,0x35,0x70,0x32,0x24,0x22,0x33,0x24,0x35,0x70,0x32,0x24,0x35


Debido a que se conoce el tamaño del texto en claro (16 bytes del login y 16 bytes del password) vemos, en el criptograma, que los candidatos a pertenecer a login y password también guardan la misma relación longitud.

Puede observarse que el criptograma del login es el mismo que el del password, solo que rotado 2 bytes. Esto tiene una explicación, habida cuenta de que la clave de cifrado puede haber comenzado en un offset diferente. Al mismo tiempo, puede observarse que, tanto en el criptograma del login como del password, el patrón vuelve a repetirse tras el séptimo byte, indicando que la clave de cifrado tiene tan sólo 7 bytes.

Una vez identificados textos en claro y sus correspondientes criptogramas, debido a la naturaleza del operador XOR, es conocido que realizando un XOR del criptograma con su correspondiente texto en claro, se obtiene la clave:

Figura 8. Obtención de la clave de de cifrado


Como se puede observar, la clave es alguna rotación de la cadena “1secret”. Dicha rotación puede conocerse, siempre y cuando se conozca previamente el offset donde comienza el criptograma conocido ( offset 6, véase la figura 6) y longitud de la clave (7 bytes). Realizando el módulo entre ambos valores, sabemos que el offset de la clave es 1, por lo que la clave original es: secret1.

Una vez conocida la clave, es posible revertir el criptograma de la figura 6, corresponde con el texto en claro:

login=AAAAAAAAAAAAAAAA&password=AAAAAAAAAAAAAAAA”


Una vez conocido el algoritmo, la clave de cifrado y los criptogramas intercambiados entre zombies y botmaster, la botnet está desenmascarada, pudiendo revelar toda la información que entre ellos se envía para analizar su comportamiento.


lunes, 5 de abril de 2010

Cuando la ToIP se queda sin voz

La telefonía IP se usa ampliamente en las organizaciones. Por ello, es necesario que este servicio esté libre de amenazas, tales como la intercepción de comunicaciones o las denegaciones de servicio. Es necesario securizar dichas plataformas de comunicación esencial y realizar revisiones periódicas de seguridad para comprobar a que ataques somos vulnerables.


En estos entornos de revisión se deben probar diferentes vectores de ataque. Los ataques contra los dispositivos VoIP son fáciles de realizar... Sobre todo si tenemos en cuenta la naturaleza del protocolo de transporte de la VoIP, RTP, el cual va sobre UDP.

Ok, pero ya sabemos que existen controles para los potenciales problemas que son, por ejemplo, inherentes al spoofing. Pero, qué pasa si las implementaciones de las pilas VoIP no contemplan una correcta implementación de los números de secuencia o de funciones similares que se realicen?. Veamos cómo funciona el paquete RTP (se transmite sobre el protocolo UDP y se utiliza en H.323 y SIP):

Figura 1. Cabecera del paquete RTP


Fijémonos en algunos campos:

PT (Payload Type): Informa que tipo de información lleva el paquete: codecs audio, info video, etc.
Sequence Number: Número de secuencia para controlar el flujo de la voz (es muy pobre…)
Timestamp: Refleja el instante de muestreo del primer octeto del propio paquete RTP.
SSRC (Synchronization Source): Es un valor elegido aleatoriamente, para identificar la fuente de la sincronización RTP, en particular.

A la saca!...

Es el momento de ver si se puede inyectar voz y molestar en las conversaciones o meter publicidad como el spit. Para ello, abusaremos de las inseguridades del protocolo UDP (spoofing y facilidades del control de flujo). Lo haremos así:

1.
Sniffamos la red para escuchar conversaciones activas
2.
Verificamos el códec que se usa en la conversación
3. Extraemos los puertos UDP, el tsmamp, el ssrc y el número de secuencia (fig 2.)
4. Con todo esto, ya podemos inyectar el ataque

Figura 2. Captura de paquetes RTP


En esta captura se puede observar un ejemplo de tráfico RTP, obtenido de una conversación VoIP entre dos softphones. En este caso concreto, los puertos UDP origen y destino coinciden. Se puede apreciar claramente el incremento del número de secuencia en los siguientes paquetes, este aumento va unidad en unidad. Además, también se puede observar el incremento constante en 100Hex del time stamp, en los diferentes paquetes, que identifica el instante del tiempo en el cual se debe reproducir la muestra de sonido contenida en el paquete.

Por último se puede comprobar el SSRC utilizado que se mantiene constante, ya que todos estos paquetes pertenecen a la misma sesión VoIP.

¿Fácil de hacer no?

Sólo basta con hacerse un pequeño programa e inyectar un tstamp superior y el mismo ssrc, del paquete que hemos obtenido (fig. 3).

Figura 3. Ataque de inyección de voz


Si probáis con este ataque, comprobaréis que muchos de los softphones descartan los paquetes del emisor y leen nuestra muestra o sample inyectado…

¡Es el momento de jugar con las pcap y demás!. Saludos,