Continuando con la saga de los artículos que nos hemos propuesto recopilar, hoy le toca el turno a una empresa española dedicada al hosting, housing, gestión de dominios, etc,... Arsys.es
El ataque explicado en esta ocasión es bastante reciente: Abril/Mayo de 2007.
La metodología del ataque fue la siguiente. Unos atacantes (presumiblemente rusos) detectan una aplicación web del área de clientes de Arsys que no validaba correctamente los parámetros de entrada. De esta manera, con un poco de magia en SQL Injections, los atacantes consiguen listar el contenido de la base de datos de usuarios/contraseñas (suponemos que los números de cuenta también aunque esto no podemos confirmarlo afirmativamente).
Con las contraseñas conseguidas de la base de datos (estaban almacenadas en texto claro) intentaron acceder al área de cliente para FTP. En el 90% de los casos el acceso era correcto, puesto que la contraseña de hosting de FTP de los clientes coincidía con la robada del área de cliente.
A partir de aquí los atacantes podían hacer un defacement completo a las páginas de los clientes de Arsys. Sin embargo, su base de actuación consistió en descargar los diferentes index.php o index.asp e introducir un iframe con código javascript ofuscado en las mismas volviéndolas a dejar en su sitio. Este código javascript descargaba un troyano que se ejecutaba en los clientes que visitaban esas páginas.
Nos podemos imaginar los miles de accesos a montones de páginas web de empresas y organizaciones importantes alojadas en Arsys, entre otras el Partido Popular, Izquierda Unida (que sufrió otro defacement hace poco tiempo). Pues todos esos clientes fueron infectados por el troyano.
Para la elaboración de ese ataque los atacantes utilizaron presuntamente un toolkit llamado MPack.
Posteriormente, Arsys intentó ocultar la existencia del ataque (buscad notas de prensa del compromiso de Arsys del 11/06/2007!!!) Para intentar arreglar (parcialmente) el problema causado (recordad la cantidad de usuarios visitantes de las páginas infectados que Arsys no tendría mucha consideración con ellos) se ideó un sistema de scripts que recorrían los diferentes dominios en busca de los iframes maliciosos y se borraban de las páginas de inicio.
Asimismo se hizo un mailing a todos los clientes de Arsys solicitando un cambio de contraseña (por motivos de política de seguridad) para el acceso FTP a las áreas de hosting y se forzó además que en el siguiente login de los clientes se cambiara la contraseña actual.
Los crackers contratacaron mediante scripts que inyectaban la contraseña antigua (la tenían) en el CGI de cambio de contraseña, y ellos mismos modificaban la password de los clientes y actualizaban la suya de manera que la medida no corregía nada.
Finalmente se implementó un sistema de Captchas para evitar que el cambio de contraseñas fuese automatizable y que los usuarios por fin pudieran modificar su contraseña por una más segura y no conocida por los atacantes de forma robada.
Como haría Coco en Barrio Sésamo, analicemos los fallos encontrados, así como las diferentes partes implicadas:
1.- ) En aquella época (2007) los ataques basados en Cross-Site Scripting y SQL Injection ya se encontraban a la orden del día, por lo que no podemos decir que Arsys pagara la novatada de los ataques de nivel 7. En este caso, no tenían la costumbre de forzar auditorías de aplicaciones Web ni de desarrollo seguro para poder garantizar la entrada robusta. Arsys -> Culpable.
2.-) Las contraseñas no se encontraban cifradas en la base de datos (ni siquiera un hash de las originales) sino que podían leerse directamente al almacenarse en claro. Esto es achacable a un fallo de diseño en el almacenamiento, que atenta contra la privacidad de los datos almacenados. Actualmente con la entrada en vigor de la LOPD el poder acceder a datos confidenciales de clientes podría haber tenido consecuencias legales bastante fuertes contra Arsys. Arsys -> Culpable.
3.-) La utilización de la misma contraseña para ser utilizada en dos servicios diferentes teniendo diferentes fuentes de autenticación. En este caso, los usuarios no habían cambiado la contraseña de entrada asignada por Arsys para el acceso web al área de clientes, que era la misma para el área de FTP. Las contraseñas para estas últimas no eran accesibles de forma directa por lo que la integridad de sus sitios web se habría mantenido. Usuarios + Arsys (por no forzar o advertir de la importancia del cambio de contraseña) -> Culpables
4.-) Arsys, como medida correctiva, "tocaba" manualmente las páginas de inicio de los clientes por parte de la empresa de Hosting (cosa que no tengo nada claro que se pueda hacer de una forma legal por parte de Arsys sin consentimiento del cliente.... quizá al ser consecuencia de una negligencia y a fin de evitar un mal superior sea lícito hacerlo) Arsys -> Culpable.
5.-) Por querer callar los errores, arreglarlos y a otra cosa,.... Arsys -> culpable por negligencia y por poca consideración con los usuarios que visitaban las páginas de SUS clientes, al intentar ocultar sobre la posible infección con el troyano descargado.
¿Tendrá algo que decir el señor Sven Olof Sandstrom (director de seguridad de Arsys.es) al respecto?
8 comments :
Sandstrom era (es?) director de seguridad, no director general.
Me he quedado perplejo con la historia... no con el hackeo (que lo conocía y que a fin de cuentas siempre te puede tocar) sino con las 1000 y 1 chapuzas que según contáis se hicieron... Parece un howto de cómo no se deben de hacer las cosas nunca en seguridad... Lo que no entiendo es cómo no rodaron cabezas...
-r
Román,
efectivamente, se me ha ido la pinza cuando lo estaba escribiendo anoche (fue un largo día el de ayer :-( ) Ya está corregido. Muchas gracias por la errata (de hecho en el link que referencia a Olof dice que es Director de Seguridad).
Lo de esa historia fue flagrante. El cómo se quisieron ocultar las cosas (veo normal que protejan su negocio, pero cuando ha habido potenciales víctimas...)
Muchas gracias,
Muy curioso lo que contáis.
Recuerdo en la FIM q la gente no variaba la pass de las cuentas internas para prácticas de la de acceso a internet y asi pasaba lo q pasaba. Además las de prácticas no tenían límite de intentos para logearse. Pero tampoco desde el CC se concienciaba sobre ello.
Salu2
Interesante documento ....
A. MaLdad
de logroño tenían que ser....... que puedes esperar :P
hija de puta tenias que ser.
zorra tenías que ser.
Publicar un comentario