• Author / Uploaded
• Raul Benitez Martinez

Citation preview

Hackeo de tokens SecurID RSA de EMC Raúl Alberto Benítez Martínez Universidad Nacional de Asunción, Facultad Politécnica, Ingeniería en Informática [email protected]

Abstract. El presente trabajo práctico expone las principales consideraciones referentes de un ataque a una empresa que provee software y sistemas para administración y almacenamiento de información en los Estados Unidos, dicha empresa es EMC en su departamento RSA, su División de Seguridad.

Keywords: EMC, RSA, APT, Phishing, CISOs.

1

Introducción

SecurID, ahora conocido como RSA SecurID, es un mecanismo desarrollado por Dinámica de Seguridad (RSA Security más tarde y ahora RSA, la División de Seguridad de EMC) para realizar la autenticación doble factor para un usuario a un recurso de red. El mecanismo de autenticación RSA SecurID consiste de un "token" - ya sea por hardware (por ejemplo, una llave USB) o software (un software token) - que se asigna a un usuario de la computadora y que genera un código de autenticación a intervalos fijos (normalmente 60 segundos) utilizando un reloj integrado y la tarjeta de la fábrica con codificación de claves aleatorias (conocida como la "semilla"). La semilla es diferente para cada token, y se carga en el correspondiente servidor RSA SecurID (RSA Authentication Manager, anteriormente ACE/Server) como los tokens se compran. El token de hardware está diseñado para ser resistente a la manipulación para impedir la ingeniería inversa. Cuando las implementaciones de software del mismo algoritmo ("tokens software") aparecieron en el mercado, el código público ha sido desarrollado por la comunidad de seguridad que permite al usuario emular RSA SecurID en el software, pero sólo si tienen acceso a un código RSA SecurID actual, y el archivo de semilla original de RSA SecurID introducido en el servidor. En el esquema de autenticación RSA SecurID, el registro de semillas es la clave secreta utilizada para generar contraseñas de un solo uso. Las nuevas versiones también cuentan con un

conector USB, que permite que el token se utilice como una tarjeta inteligente-como dispositivo para el almacenamiento seguro de certificados. Un usuario que se autentica a un recurso de red – por ejemplo, un servidor de acceso telefónico o un firewall tiene que introducir tanto un número de identificación personal y el número que se muestra en ese momento en su token RSA SecurID. Algunos sistemas utilizan RSA SecurID ignorando la implementación PIN del todo, y dependen de combinaciones de código contraseña/RSA SecurID. El servidor, que también tiene un reloj de tiempo real y una base de datos de las tarjetas válidas con los registros de semillas asociados, calcula que el número del token se supone que se muestra en ese momento en el tiempo, se comprueba en contra de lo que el usuario introduce y hace la decisión de permitir o denegar el acceso. Mientras que el sistema RSA SecurID añade una capa fuerte de seguridad a una red, la dificultad puede ocurrir si el reloj del servidor de autenticación se queda fuera de sincronía con el reloj incorporado en los tokens de autenticación. Sin embargo, típicamente los RSA Authentication Manager corrigen automáticamente sin afectar al usuario. También es posible volver a sincronizar un token manualmente en el RSA Authentication Manager. Proporcionar autenticación de tokens para todas las personas que podrían necesitar acceder a un recurso puede ser caro (alrededor de $ 15 al año + los costos de licencias), sobre todo porque los tokens están programados para "expirar" en un tiempo fijo, generalmente de tres años, lo que requiere la compra de un nuevo token. RSA Security ha llevado adelante una iniciativa denominada "Autenticación Ubicua", en asociación con los fabricantes de dispositivos tales como IronKey, SanDisk, Motorola, Freescale Semiconductor, RedCannon, Broadcom, y BlackBerry para integrar el software SecurID en dispositivos de todos los días tales como unidades flash USB y teléfonos móviles, para reducir el costo y el número de objetos que el usuario debe llevar.

2

Descripción

Los ataques APT (Advanced Persistent Threat) suelen tener tres fases principales. El primero es el ataque de ingeniería social, que es uno de los elementos clave que diferencia a un APT del hacking de viejos tiempos. Desde la primera mención de APTs ha sido claro que estos ataques serán difíciles de combatir, ya que utilizan una combinación de ingeniería social con vulnerabilidades en el punto final para acceder a las PC de los usuarios. Una vez dentro ya está en la red, usted sólo tiene que encontrar un camino a los usuarios adecuados y sistemas, y seguir con la actividad "regular" de hacking.

La parte de la ingeniería social es igualmente simple. Como he mencionado en un blog anterior que se centró en algunas de las estrategias de defensa contra APT, sólo pensar en lo que ha cambiado en las últimas décadas. En la década de 1980 que tenía a tipos como Matthew Broderick en Juegos de Guerra, en busca de módems conectados a redes sensibles. Matthew mapeó redes y encontró puntos débiles. Sus ataques no tenían nada que ver con los usuarios, sino que utiliza las deficiencias en la infraestructura. Pero si Matthew estaba organizando un hack APT hoy, lo primero que haría es visitar los sitios de medios sociales. Había reunir información de inteligencia sobre las personas de las organizaciones, no en infraestructura. Entonces él le enviaría un correo electrónico de phishing a los empleados de interés.

3

Etapas del ataque

3.1 Primera Etapa En nuestro caso, el atacante envió dos correos electrónicos de phishing diferentes durante un período de dos días. Estos correos electrónicos fueron enviados a dos pequeños grupos de empleados. Cuando nos fijamos en la lista de usuarios que fueron dirigidos, no se ve ningún indicio evidente, nada que explique los objetivos de alto perfil o de alto valor. La línea del asunto del correo electrónico era "Plan de Reclutamiento 2011". Esto era suficientemente intrigante para que uno de los empleados saque efectivamente el correo electrónico fuera de su caja de basura y haga doble clic en el archivo adjunto de correo electrónico, que era una hoja de cálculo excel titulado “2011 Recruitment plan.xls”.

3.2 Segunda Etapa La hoja de cálculo contiene un exploit de día cero que instala una puerta trasera a través de la vulnerabilidad de Adobe Flash (CVE-2011-0609). Adobe ya ha lanzado un parche de emergencia para el día cero. El exploit inyecta código malicioso en la PC del empleado, permitiendo el pleno acceso a la máquina. El atacante en este caso instala una herramienta personalizada de administración remota conocida como una variante RAT Poison Ivy, si usted está familiarizado con APT reconocerá Poison Ivy, ya que ha sido ampliamente utilizado en muchos otros ataques, incluyendo GhostNet.

3.3 Tercera Etapa La siguiente fase de una APT es moverse lateralmente dentro de la red una vez que están comprometidas algunas de las PCs de los empleados. La cosa es que los puntos de entrada iniciales no son suficientemente estratégico para los atacantes, sino que necesitan usuarios más accesos, más derechos de administrador a los servicios pertinentes y servidores, etc.

3.4 Cuarta Etapa En la cuarta etapa de la APT, el objetivo es extraer lo que pueda. El atacante, en el caso de RSA estableció acceso a los servidores de almacenamiento intermedio en puntos de agregación clave, lo que hizo para prepararse para la extracción. Luego entró en los servidores de interés, eliminó datos y se trasladó a los servidores internos de parada donde los datos se agregan, se comprimen y se cifran para la extracción.

3.5 Quinta Etapa El atacante utilizó FTP para transferir muchos archivos RAR de contraseñas protegidas desde el servidor de archivos RSA a un servidor de almacenamiento intermedio fuera de una externa máquina comprometida de un proveedor de hosting. Los archivos fueron retirados posteriormente por el atacante y se eliminaron del host externo comprometido para quitar cualquier rastro del ataque.

4

Prevención

•

Es interesante observar que el ataque fue detectado por su equipo de respuesta a incidentes en curso (Computer Incident Response Team). Es hora de responder como una industria, definir y ejecutar una doctrina nueva de defensa basada en el intercambio de información, análisis profundos y la gestión avanzada de amenazas. Los departamentos de TI de seguridad pasaron muchas noches largas, tratando de averiguar qué hacer contra los atacantes furtivos, quienes no se molestaron nada con todos los millones derramado en asegurar la infraestructura, atacando en vez al elemento más débil de la cadena: los seres humanos.

•

•

5

Conclusiones

Tal vez este incidente puede ser utilizado como un ejercicio cuando usted mira su propia infraestructura y se preguntan qué opciones de mitigación tienes contra ataques similares. Le di mi opinión sobre el asunto en el blog principal, y puede resumir así: hay una razón por la que las APTs son tan peligrosas, y tiene que decirnos algo. Como industria, tenemos que actuar con rapidez y desarrollar una nueva doctrina de defensa, los días felices de los viejos tiempos de hacking se han ido, y se han ido también los paradigmas de defensa viejos Las nuevas amenazas requieren nuevas estrategias. En RSA ya estamos aprendiendo rápido, haciendo así pequeños plazos de movimientos de endurecimiento y grandes pasos para establecer una doctrina entera de nueva defensa. Estamos implementando técnicas que sólo un par de semanas atrás, pensé que eran en el ámbito de planes de trabajo a largo plazo. Hay ejemplos históricos de tantas campañas que parecían desesperadas en el momento, pero se convirtieron luego a través de la pura voluntad, creatividad y liderazgo, estoy seguro de que en unos pocos años, las Advanced Persistent Threats

serán familiares, forma casi corriente de ataque y que vamos a ser capaces de desplegar defensas eficaces contra los que quieren espiar y controlar nuestra propiedad intelectual, activos digitales y la infraestructura crítica.

Referencias 1. 2. 3. 4. 5. 6. 7. 8. 9.

http://www.delitosinformaticos.com.ar/blog/category/usa/ http://www.f-secure.com/weblog/archives/00002226.html http://blogs.rsa.com/rivner/anatomy-of-an-attack/ http://tecno.americaeconomia.com/noticias/los-riesgos-bancarios-tras-el-hackeo-alproveedor-del-digipass en.wikipedia.org/wiki/SecurID http://es.wikipedia.org/wiki/EMC_Corporation http://www.rsa.com/rsalabs/ http://latinamerica.rsa.com/node.aspx?id=1156 http://conexioninversa.blogspot.com/2011/09/un-ataque-persistente-apt.html