RSA Víctima de un ataque cibernético: Cómo sucedió

Nota: Esta nota está disponible en inglés

Tal como escribí en mi último post con titulo “RSA Víctima de un ataque cibernético” el día 30 de Marzo, RSA fue víctima de un ataque del tipo Amenaza Avanzada Permanente (Advanced Persistent Threat), que logró extraer información de los servidores de la Compañía. El tipo de información extraída no fue hecha pública por la Compañía, pero sí  se estableció que estaba relacionada con los productos de autentificación de dos factores SecurID. Según la Compañía, la información extraída no permitiría realizar un ataque con éxito sobre los usuarios del producto SecurID,  pero podría ser utilizada para reducir la efectividad de implementaciones de autentificación basadas en dos factores como parte de un ataque mayor

Hasta el viernes pasado, RSA no había realizado más declaraciones públicas sobre como fue el ataque, pero un artículo de Uri Rivne en el Blog oficial de RSA dio pistas sobre cómo éste fue realizado.

Como comenta Uri en su Blog, el atacante en un período de dos días inició por correo electrónico un ataque de Phishing . Este correo, con el tema “plan de reclutamiento 2011”, tuvo como objetivo  a un grupo reducido de empleados sin privilegios. Una de las víctimas abrió un archivo Excel adjunto al correo y éste instaló un backdoor por medio de la explotación de una  vulnerabilidad desconocida (ó zero-day exploit)  en el  Adobe Flash (vulnerabilidad CVE-2011-0609).

Una vez instalado el backdoor, el próximo paso fue permitir el control remoto de la computadora afectada. En este caso, el atacante instaló una herramienta de administración remota que se conectaba en forma reversa, siendo difícil de detectar (la conexión se realizaba desde adentro hacia afuera). Luego, el atacante buscó usuarios con mayores privilegios por la red interna que posean acceso a la información deseada. Esto último fue realizado con metodologías de hackeo normales.

Según Uri, el atacante tomó todas las credenciales de acceso de la computadora comprometida, y luego desde ahí ataco usuarios sin privilegios administrativos en sistemas los críticos y por medio de ataques de elevación de privilegios obtuvo acceso a  usuarios con los privilegios adecuados.

Finalmente, hackearon  los servidores que contenían la información deseada con las credenciales apropiadas,  la comprimieron, cifraron y la movieron a un servidor interno. Posteriormente, la extrajeron por medio de FTP a un servidor hackeado de un proveedor de servicios de hosting.

El resto de la historia ya es conocida.

Por Agustin Chernitsky

RSA SecurID Attack: How it happened

Nota: Este post está disponible en español.

Like I wrote in my previous post titled “RSA SecurID Attack” on March 30^th, RSA was victim of a Advanced Persistent Threat (APT) attack, which achieved the goal of extracting information from the Company’s servers. Although the type of information is not publicly specified by RSA, it was said to be related to the SecurID (3) two-factor authentication products. According to the Company, the information extracted does not enable a successful direct attack on any of their RSA SecurID customers, but it might be used to reduce the effectiveness of the current two-factor implementations in a broader attack.

Until last Friday, RSA was keeping for itself any details on how the attack took place, but finally a blog post by Uri Rivne in RSA's official blog gave up some cues on how it happened.

According to Uri, the attacker sent two phishing e-mails over a two-day period. This e-mail, which was targeted to a small group of employees (considered low profile users), contained a subject of “2011 Recruitment Plan”. One of the victims opened the attached Excel file which contained a zero-day exploit that installed a backdoor exploiting an Adobe Flash vulnerability (CVE-2011-0609) (1).

Once the backdoor was installed, the next logical step was to allow remote control of the machine. In this case, the attacker installed a remote administration tool in reverse-connect mode, being difficult to detect. Then the attacker hunted throughout the network for users with more privileges, which had access to the target information. This was done with regular hacking methodologies.

According to Uri, the attacker acquired all access credentials from the compromised user, and then attacked non-administrative users in targeted systems, and then with privilege escalation attacks gained access to high value targets.

Finally, they hacked into the servers of interest with appropriate credentials, moved the target data to an internal server where they compressed and encrypted it. Once this was done, it was extracted through FTP to an external compromised hosting provider.

The rest of the story is already known.

By Agustin Chernitsky

Notes:

(1) Adobe has released a patch.