miércoles, 10 de octubre de 2012

ATAQUE A RSA SECURITY





¿A QUE SE DEDICA LA EMPRESA RSA?

“El enfoque de seguridad centrado en la información que ofrece RSA protege la integridad y la confidencialidad de la información durante todo su ciclo de vida, sin importar adónde se transfiera, quién acceda a ella ni cómo se utilice. RSA ofrece soluciones líderes en la industria para verificación de identidad y control de acceso, encriptación y administración de claves, administración del cumplimiento de normas y de la información de seguridad, y protección contra fraudes. Estas soluciones brindan confianza a millones de identidades de usuarios, las transacciones que estos realizan dichos usuarios y los datos que se generan a partir de dichas transacciones.
RSA permite que los clientes tengan la confianza de que sus recursos de información están protegidos y disponibles para aprovechar nuevas posibilidades del negocio.” [1]
Si bien podemos decir que la empresa RSA SECURITY es una empresa que se dedica a la seguridad informática que garantiza en cierto modo la seguridad de la información, sin embargo este ataque deja muchas cosas que pensar de ella.
A continuación se  explica en qué consistió el ataque.

¿EN QUE CONSISTIÓ EL ATAQUE?

“ 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.” [2]




CONCLUSIONES.

Podemos concluir que aun cuando una empresa está 100% dedicada a la seguridad de la información, nunca se va a tener el porcentaje máximo de seguridad, tal y como le sucedió a esta empresa de alto prestigio, es común hoy en día no solamente surjan ataques a empresas que no están inmersas en desarrollo en cuanto a la seguridad no sean las únicas que sean atacadas, sino que también es factible el atacar a empresas que manejan altos niveles de seguridad y que este es su giro principal.

Es importante resaltar que los servicios no garantizan la inmunidad a ataques, esto también depende de las medidas de seguridad que tenga la entidad  que está siendo beneficiada por  el servicio, depende de que se sigan las recomendaciones hechas por la empresa y así poder tener un mayor porcentaje de seguridad.


BIBLIOGRAFIA



No hay comentarios:

Publicar un comentario