El 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 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 explicar que las ATP (Advanced Persistent Threat) 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.
Todo empieza cuando el atacante envía dos correos en un periodo de dos días a dos pequeños grupos de empleados. Se les envió un correo con el asunto "2011 Recruitment Plan" con un Excel con el mismo nombre adjunto. Uno de los usuarios rescató el email de la carpeta de correo basura.
El Excel contenía una falla no conocida hasta el momento en Flash, que permitía la ejecución de código. Incluso Adobe anunció el 14 de marzo que sabía de la existencia de una vulnerabilidad desconocida que estaba siendo aprovechada para atacar sistemas. Si bien no hace mención explícita a RSA, parece que esta vulnerabilidad apareció a causa de este ataque. Adobe ya ha solucionado esto con un parche emitido fuera de su ciclo habitual.
Luego los atacantes instalaron una variante del conocido RAT 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 y en puertos estándares. En este punto hubiesen sido necesarios inspectores de tráfico e IDS, aunque es cierto que el nivel de éxito de esta medida puede 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 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ó archivos 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 correcta de su mensaje, podría servir como experiencia en la que apoyarse para prevenir incidentes futuros.
Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4545
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 explicar que las ATP (Advanced Persistent Threat) 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.
Todo empieza cuando el atacante envía dos correos en un periodo de dos días a dos pequeños grupos de empleados. Se les envió un correo con el asunto "2011 Recruitment Plan" con un Excel con el mismo nombre adjunto. Uno de los usuarios rescató el email de la carpeta de correo basura.
El Excel contenía una falla no conocida hasta el momento en Flash, que permitía la ejecución de código. Incluso Adobe anunció el 14 de marzo que sabía de la existencia de una vulnerabilidad desconocida que estaba siendo aprovechada para atacar sistemas. Si bien no hace mención explícita a RSA, parece que esta vulnerabilidad apareció a causa de este ataque. Adobe ya ha solucionado esto con un parche emitido fuera de su ciclo habitual.
Luego los atacantes instalaron una variante del conocido RAT 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 y en puertos estándares. En este punto hubiesen sido necesarios inspectores de tráfico e IDS, aunque es cierto que el nivel de éxito de esta medida puede 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 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ó archivos 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 correcta de su mensaje, podría servir como experiencia en la que apoyarse para prevenir incidentes futuros.
Si quieren más información pueden visitar: http://www.hispasec.com/unaaldia/4545
No hay comentarios:
Publicar un comentario