RSA: Ataque de Virus - Ejemplo "Para Prevenir Incidentes"

 

 

El pasado 18 de marzo RSA confesó que había sufrido un ataque dirigido 
en el que le robaron información relativa a su famoso producto SecurID. 
En estos momentos ya se sabe cómo accedieron a la información los 
atacantes y, de paso, que RSA tardó varios días en hacer público el 
incidente. 

En una entrada oficial llamada "anatomía de un ataque" RSA explica cómo 
ocurrió un grave incidente de seguridad en su compañía. Si bien explica 
muy bien el ataque, se centra en buena medida en explicar que las ATP 
(Advanced Persistent Threat, amenazas avanzadas y persistentes sobre una 
misma compañía) son muy complejas, que ocurren en las mejores familias y 
que ellos hicieron lo correcto. Parece que es así, pero lo interesante 
es centrarse en los errores para poder aprender de este tipo de 
situaciones. 

Cómo empezó 

Según la RSA, el atacante envío dos correos en un periodo de dos días, a 
dos pequeños grupos de empleados. RSA concreta que "no se consideraría a 
estos usuarios particularmente de perfil alto u objetivos valiosos". 
¿Quiere decir con esto, que se encontraban menos protegidos que el 
resto? Dentro de una organización de este calibre, todos los usuarios 
con acceso a la red deberían ser considerados de alto riesgo y 
protegidos por igual. Se les envió un correo con el asunto "2011 
Recruitment Plan" con un Excel del mismo nombre adjunto. Uno de los 
usuarios, incluso, rescató el email de la carpeta de correo basura. 
Según RSA, es porque el correo estaba muy bien construido. Una buena 
política de seguridad debería prohibir y entrenar expresamente a los 
usuarios para no abrir archivos no solicitados, sin excusas. 

El Excel contenía en su interior un fallo no conocido hasta el momento 
en Flash, que permitía la ejecución de código. De hecho, Adobe anunció 
el 14 de marzo que sabía que una vulnerabilidad desconocida estaba 
siendo aprovechada para atacar sistemas. Si bien no hacía mención 
explícita a RSA, parece que la vulnerabilidad apareció a causa de este 
ataque. Adobe ya lo ha solucionado con un parche emitido fuera de su 
ciclo habitual. 

De esto se deduce que, aunque RSA hubiera mantenido todo su software 
actualizado, el atacante hubiese igualmente conseguido ejecutar código. 
En estos casos, es en los que se echa de menos el uso de herramientas 
como DEP o ASLR o cualquier otro software que prevenga los 
desbordamientos de memoria. Es irrelevante el uso de Office, LibreOffice 
o Flash... si los atacantes han tenido acceso a un 0 day en Flash... 
podrían haberlo conseguido de cualquier otro programa. 

Una vez dentro 

Luego los atacantes instalaron una variante del conocido RAT 
(herramienta de administración remota) Poison Ivy y crearon una conexión 
inversa hacia un servidor propio del atacante. RSA afirma que "esto lo 
hace más difícil de detectar", pero no es del todo cierto. Lo que hace 
más difícil de detectar estas conexiones es el hecho de que suelen estar 
cifradas, ofuscadas y en puertos estándares que no levantan sospechas, 
no el hecho en sí de que sean "inversas". En realidad, esto está asumido 
como estándar. La opción contraria, establecer una conexión desde fuera 
a la máquina infectada está descartado desde un primer momento en la 
mayoría de los escenarios y es una opción que los atacantes serios ni 
siquiera contemplarían. En este punto hubiesen sido necesarios 
inspectores de tráfico e IDS, aunque es cierto que el nivel de éxito de 
esta medida podría ser menor si los atacantes realmente se lo proponen. 

Según la RSA, el ataque fue detectado por su Computer Incident Response 
Team mientras se estaba produciendo. Insiste en que, en muchos otros 
casos, el ataque se desarrolla durante meses antes de ser detectado. 
Sin embargo, los atacantes tuvieron tiempo de hacerse una idea de la 
red interna y buscar usuarios con más privilegios que los infectados 
inicialmente. Llegaron a comprometer cuentas de administrador. 

El atacante más tarde transfirió muchos ficheros RAR protegidos por 
contraseña desde el servidor de la RSA hacia un tercero externo y 
comprometido. Descargó la información, la borró de ese servidor... 
y se quedó con ella. 

RSA sigue sin aclarar qué fue lo robado exactamente, aunque explica 
bien cómo funcionó el ATP y, extrayendo la información adecuada de su 
mensaje, podría servir como experiencia en la que apoyarse para prevenir 
incidentes futuros.

From: Hispasec

  FEELPCS
In god we trust