El ataque a la RSA se
produjo a través de un 0 day en Flash
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 APT (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.
Más información
0 day
en Adobe Flash, Reader y Acrobat
http://www.hispasec.com/unaaldia/4524
Anatomy of an Attack
http://blogs.rsa.com/rivner/anatomy-of-an-attack/
Comprometen la seguridad de RSA y roban información sobre el producto SecurID
http://www.hispasec.com/unaaldia/4528/
http://www.hispasec.com/unaaldia/4524
Anatomy of an Attack
http://blogs.rsa.com/rivner/anatomy-of-an-attack/
Comprometen la seguridad de RSA y roban información sobre el producto SecurID
http://www.hispasec.com/unaaldia/4528/
No hay comentarios:
Publicar un comentario