Español | English
rss facebook linkedin Twitter

Se acabó la tregua, el malware bancario Gootkit muta y afecta a entidades españolas


Desde el departamento de Servicios Avanzados de Ciberseguridad de S21sec, el pasado mes de mayo os dábamos información técnica al respecto del malware bancario Gootkit, y comentábamos algunas de las entidades afectadas, principalmente de Italia y Francia.

Durante las últimas semanas, mediante el seguimiento que hacemos de las botnets de estas familias de malware bancario, hemos observado cómo ha ido evolucionando el número de entidades y países afectados. Si ya vimos en el pasado que múltiples entidades financieras de Reino Unido, Canadá y Estados Unidos se unían al grupo de entidades atacadas directamente, a finales de la semana pasada ya detectamos una muestra con afectación a algunas entidades españolas, entre las que no se encuentra ningún cliente de S21Sec, que habría sido alertado inmediatamente.

Las primeras observadas en esta variante:



Nuestra recomendación es que no se puede obviar ninguna familia de malware, ya que cualquiera de ellas puede mutar en cualquier momento en su comportamiento, características o en las entidades a las que afecta, y por ende a los usuarios de esas entidades, incluyendo inyecciones con muleros.

Estar siempre vigilante antes nuevas amenazas detectadas, aunque no nos afecten directamente y en la medida de lo posible, contar con algún servicio de alerta temprana de una empresa especializada en este tipo de amenazas

Realizar periódicamente acciones que mejoren el nivel de concienciación de nuestros clientes y usuarios en lo referente a Amenazas, Fraude y CiberSeguridad, con campañas de comunicación, Ciber-ejercicios, formación, etc

Debemos educar a nuestros usuarios para que interioricen el grado de alerta necesario, a la hora de navegar en ciertos sitios, identificar correos fraudulentos, no pichar en enlaces sospechosos y, sobre todo, desconfiar de aquellos que les solicitan claves o información adicional, bancaria en la mayoría de los casos

Drown a fondo: Un nuevo ataque al SSL.(PARTE V)



En el post anterior vimos cómo debido a una vulnerabilidad de OpenSSL (CVE-2015-3197) un atacante podía forzar el uso de algoritmos de cifrado EXPORT en su intento por descifrar los master-key de SSLv2 necesarios para el ataque DROWN, incluso aunque se encontraran deshabilitados por configuración. Esto le permite descifrar cada master-key mediante 240 operaciones criptográficas en lugar de las 2128 o incluso 2192 que le requeriría en caso de tener que usar algoritmos no EXPORT.

En este post veremos que realmente ni siquiera necesita usar algoritmos EXPORT, sino que incluso le es más conveniente usar un algoritmo no EXPORT, siempre que el servidor SSLv2 sea vulnerable a CVE-2016-0703. Para entender esta vulnerabilidad, vamos a repasar cómo funciona el master-key.

El master-key es un valor aleatorio generado por el cliente y enviado al servidor cifrado con la clave pública de éste.  Las claves simétricas que se usarán en la comunicación dependen de valores enviados en claro por cliente y servidor y de este valor, que es conocido por el cliente (ya que lo ha generado él) y por el servidor (ya que puede descifrarlo mediante su clave privada). El tamaño de este master-key debe coincidir con el tamaño de clave asociado al algoritmo de cifrado escogido, siendo:

  • 8 bytes para DES

  • 16 bytes para IDEA, RC2 y RC4, así como las versiones EXPORT de RC2 y RC4

  • 24 bytes para triple-DES

Centrándonos en RC2 y RC4 vemos una aparente discrepancia. Si el master-key tiene que ser del tamaño de clave del algoritmo escogido, está claro que para la versión no EXPORT los 16 bytes son correctos (ya que el tamaño de clave es de 128 bits) pero las versiones EXPORT se suponía que tenían sólo 40 bits. ¿A qué se debe esta diferencia?
 
Lógicamente, la discrepancia no es tal. Las versiones EXPORT de RC2 y RC4 realmente utilizan también un tamaño de clave de 128 bits, por lo que también requieren un master-key de 16 bytes. La causa de que su fuerza de cifrado sea sólo de 40 bits es que  en este caso el master-key se envía dividido en dos partes. Una primera parte de 88 bits se envía en claro (clear-key), mientras que los últimos 40 bits (secret-key) sí se envían cifrados con la clave pública del servidor (encrypted-key). Esto provoca que el número de posibles claves que hay que romper por fuerza bruta si no se conoce la clave privada del servidor es de 240, lo que es equivalente a tener una clave de cifrado de 40 bits.
Centrándonos un poco más en estos master-key semiencriptados, ambas partes del master-key se envían en el paquete ClientMasterKey. Por ejemplo, para un algoritmo RC2 en versión EXPORT, el procesamiento en el servidor podría ser el siguiente:




Aquí podemos ver claramente las tres secciones mencionadas anteriormente. El paquete ClientMasterKey contiene 11 bytes del master key en claro (clear-key, representado por los bytes marcados con la letra C) y 256 bytes (asumiendo una clave RSA de 2048 bits) del master key cifrados (encrypted-key, representado por los bytes marcados con la letra E) y que tras descifrarse se convierten en 5 bytes (secret-key, representado por los bytes marcados con la letra S) que junto con el clear-key se convierte en el master-key definitivo. Un atacante que desconozca la clave privada RSA tendrá que probar 240 posibles del secret-key para descubrir el master-key real.

Por contra, para un algoritmo RC2 en su versión no EXPORT, el procesamiento es el siguiente:  



No existe clear-key (su longitud es 0) y la encrypted-key se descifra a un secret-key de 16 bytes, con lo que es la master-key completa. La longitud de encrypted-key es la misma que en el caso anterior (256 bytes o 2048 bits) porque depende del tamaño de la clave RSA, y no del contenido realmente cifrado.

Hasta aquí todo correcto. Sin embargo, ¿qué ocurre si mezclamos ambos casos? ¿Cuál es el comportamiento del servidor si usamos un algoritmo de cifrado no EXPORT pero le pasamos un clear-key? Según la especificación de SSLv2 el servidor debe rechazarlo. Sin embargo el comportamiento de OpenSSL es radicalmente distinto. Acepta el clear-key y toma del secret-key sólo la parte necesaria para completar el encrypted key. Es decir:



En este caso si el atacante tiene un secret-key de  16 bytes pero incluye un clear-key de 11 (como si fuese un algoritmo EXPORT), la incertidumbre sobre el master-key es sólo de 240 posibilidades, ya que el atacante conoce los primeros 11 bytes, y OpenSSL está descartando los últimos 11 del secret-key.  Vemos que usando esta vulnerabilidad es posible reducir la complejidad de 2128 a 240  aunque a costa de conocer sólo 5 de los 16 bytes. ¿Podemos mejorar esta situación? ¿Qué ocurre si pasamos como clear-key 15 bytes? Sorprendentemente, OpenSSL vuelve a no validar la longitud (ningún algoritmo necesita un clear-key de 15 bytes) y en este caso:


Vemos que el atacante ha podido fijar hasta 15 bytes del master-key y la única incertidumbre es el valor de S0. Es decir, 28 operaciones criptográficas con las que obtiene el valor de un byte del total de 16 del secret-key. ¿Esto le vale para algo? Por supuesto, porque ahora no tiene más que realizar la misma operación pero con un clear-key de 14 bytes, quedando:



En este caso entran dos bytes del secret-key para generar el master-key. Pero recordemos que en el paso anterior el atacante ha sido capaz de obtener el valor de S0 (razón por la que lo marcamos en amarillo en el gráfico, ya que es un valor conocido para el atacante). De nuevo, con 28 operaciones criptográficas puede obtener el valor de S1. Repitiendo esta operación otras 14 veces, reduciendo en cada paso el tamaño del clear-key, finalmente se llega a:
 

Con las últimas 28 operaciones criptográficas se acaba obteniendo el valor de S15 y por tanto el valor completo del secret-key. El proceso completo ha requerido 16 conexiones al servidor SSLv2 y un máximo de 212 operaciones en lugar de 2128 como habría necesitado de intentar romper por fuerza bruta el secret-key de un algoritmo RC2 no EXPORT. De hecho, aunque el ejemplo lo hemos hecho con RC2 ya que era uno de los dos algoritmos con versión EXPORT, es incluso mejor usar triple-DES (para el que OpenSSL también admite un clear-key aunque en ese caso no tenga ni versión EXPORT) ya que en ese caso con una complejidad inferior a 213 el atacante puede descifrar perfectamente un master-key de 24 bytes.

Esta vulnerabilidad por tanto tiene dos vertientes:
  • Por un lado, permite romper de forma sencilla cualquier conexión SSLv2 que se realice contra un servidor OpenSSL vulnerable. Pueden romperse conexiones que se hayan producido en el pasado, siempre que se disponga de una captura de tráfico. El tiempo de descifrado del master-key y obtención de las claves simétricas es de unos pocos segundos.
  • A nivel del ataque DROWN, en el ataque general era necesario descifrar varios master-key diferentes que se calculaban a ciegas. Esta operación requería 240 operaciones criptográficas para obtener 5 bytes de información (de un total de 256 que había que conseguir para una clave RSA de 2048 bits), o incluso para descubrir que el master-key era inválido (lo que forzaba a tener que probar otro diferente). Con esta vulnerabilidad la validez o no del master-key se descubre en 28 operaciones y en caso de un master-key válido se requieren únicamente 213 operaciones para obtener 24 bytes de información, lo que acelera enormemente el ataque.
Tanto esta vulnerabilidad como la comentada en el post anterior nos deben llevar a darnos cuenta de la necesidad de tener actualizado no sólo nuestro software (y todas las librerías que utilice), sino los propios protocolos que utilizamos. Utilizar SSLv2 con versiones vulnerables de OpenSSL no proporciona más seguridad que una conexión en claro para un atacante mínimamente motivado.

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login