ARSYS sancionada por el ataque que sufrió en 2007
El ataque hacker que comprometió los datos de casi 8000 clientes de Arsys se ha saldado con una multa de 6000 euros a esta entidad, por entender que no cumplía con todas las medidas de seguridad. La Resolución detalla el procedimiento seguido por el atacante (SQL injection) y se pone de manifiesto que en el momento del ataque Arsys tenía un total 20 vulnerabilidades graves que permitían acceder a los datos de los clientes, como la existencia de contraseñas de administradores en el código fuente de algunas aplicaciones.
El 11 de junio de 2007 apareció en diversos medios de comunicación que «unos hackers atacan una empresa de Internet y obtienen claves personales y bancarias de clientes«; en la noticia no se mencionaba la empresa, pero hecha pública la Resolución sancionadora recientemente, descubrimos que se trataba de Arsys, aunque es algo que ya se sabía en el mundillo.
La Resolución describe todo el procedimiento seguido por el atacante para vulnerar los sistemas de Arsys, y que para no extenderme resumo de la siguiente manera:
- El día 15 de febrero de 2007 el atacante se da de alta como cliente de Arsys, proporcionando un NIF y número de cuenta bancaria españoles válidos.
- El día 16 de febrero de 2007 un atacante accede al área de clientes.
- Después de recorrer e interactuar con varias aplicaciones descubre una vulnerabilidad SQL injection en el parámetro de la url de la aplicación servicios.asp.
- El día 17 de febrero de 2007 se reciben 2.136 peticiones a la aplicación servicios.asp que, mediante la vulnerabilidad SQL injection y aprovechando la capacidad de paginación de la aplicación listan los campos CDA_L0G1N y CDA_PASSWORD.Esto es, «se realizó un ataque de inyección SQL, mediante el cual el atacante pudo averiguar las claves de acceso de los usuarios a los servicios FTP».
- Pudo averiguar las claves porque éstas se almacenaban en texto plano en la base de datos.
- Entre los días 13 y 1 de abril de 2007 (antes de terminar el recorrido por el panel de control) se realiza un ensayo contra los servidores FTP para discernir cuales de las contraseñas capturadas son válidas.
- Cuando se produce el ataque entre los días 21 y 22 de abril, el atacante no falla ninguna de las contraseñas que intenta.
- Durante del fin de semana del 21 y 22 de abril usuarios no identificados comprometieron la seguridad de unos 8.000 dominios, utilizando FTP para acceder con las credenciales de usuario y modificar las páginas HTML principales de los dominios.
La modificación realizada en las páginas añade un iframe a un sitio web malicioso, con el objetivo de instalar un troyano en la máquina del cliente que visite el dominio comprometido.
Los dominios infectados fueron 8.264 y el número de clientes afectados fueron 6.686, puesto que muchos de los clientes eran titulares de más de un dominio.
Sin embargo no se puede decir que Arsys no se preocupara por la seguridad de los datos de sus clientes: estaba inmersa en la implantación de la ISO 27001 y de hecho aportó en el procedimiento algunos documentos extraídos del SGSI como por ejemplo:
- Uso del Cifrado, fechado el 1/7/2006.
- Control de accesos, fechado el 11/10/2006.
- Gestión de Crisis, fechado el 1/7/2006.
Todo ello además de tener un Documento de Seguridad actualizado según exigencias de la propia LOPD.
En otras palabras, Arsys hizo todo lo humanamente posible para mantener seguros sus sistemas, pero debemos ser conscientes que la seguridad perfecta no existe.
De hecho, a raiz del incidente, se contrató a una empresa especializada en seguridad informática que arrojó los siguientes resultados:
Existencia de 25 vulnerabilidades graves, que permiten el acceso a información confidencial. Se realiza en el informe una clasificación de las 46 vulnerabilidades halladas. Los tres tipos más importantes son:
- Inyección de SQL, encontrándose 20 vulnerabilidades. Este tipo de vulnerabilidades ponen en peligro la información alojada en las bases de datos de la entidad. Por ello es, en lo que a protección de datos se refiere, una de las vulnerabilidades más peligrosas.
- Guiones de sitio cruzado («XSS» o «Cross Site Scripting»), encontrándose once vulnerabilidades. Este tipo de vulnerabilidades ponen en peligro los equipos que acceden a servidores web alojados por ARSYS. El peligro respecto a la protección de datos seria la inserción de un programa espía en los equipos, de forma que los atacantes podría tener acceso a toda la información del equipo, así como averiguar los sitios web a los que tienen acceso los usuarios del equipo, sus identificadores de usuario y contraseñas.
- Comprobaciones débiles («Weak checks»), encontrándose nueve vulnerabilidades. De difícil clasificación, dichas vulnerabilidades podrían dar, potencialmente, acceso a cualquier servicio del sistema, incluido el acceso a ficheros y bases de datos.
Es de destacar también la aparición, en el código fuente de las aplicaciones, de nombres de servidores, bases de datos alojadas en ellos, claves de usuario (incluso de administradores), y claves de acceso de esos usuarios.
Pero ¿Por qué se sancionó a Arsys si hizo todo lo posible y fue diligente a la hora de solucionarlo?.
La respuesta es sencilla: en materia de seguridad, la ley impone una OBLIGACIÓN DE RESULTADO, consistente en que se adopten las medidas necesarias para evitar que los datos se pierdan, extravíen o acaben en manos de terceros. En definitiva Arsys es, por disposición legal, una deudora de seguridad en materia de datos, y por tanto debe dar una explicación adecuada y razonable de cómo los datos han ido a parar a un lugar en el que son susceptibles de recuperación por parte de terceros, siendo insuficiente con acreditar que adopta una serie de medidas, pues también es responsable de que las mismas se cumplan y se ejecuten con rigor. En definitiva toda responsable de un fichero (o encargada de tratamiento) debe asegurarse de que dichas medidas o mecanismos se implementen de manera efectiva en la práctica sin que, bajo ningún concepto, datos bancarios o cualesquiera otros datos de carácter personal puedan llegar a manos de terceras personas.
Dicho claramente: hagas lo que hagas, tengas los sistemas de seguridad que tengas, si un dato personal se fuga de tu sistema, podrás ser sancionado.
Como curiosidad y para terminar, decir que si Arsys no hubiera denunciado ante la Guardia Civil la intrusión de la que fue víctima, es muy posible que el asunto no hubiera aparecido en los medios de comunicación y la Agencia Española de Protección de Datos no habría actuado de oficio como lo hizo en este caso.
Comments
Roberto J. Alcalá Sánchez
«Pero ¿Por qué se sancionó a Arsys si hizo todo lo posible y fue diligente a la hora de solucionarlo?»
Uhmmm, desde luego NO hizo todo lo posible, el echo que pusiera contraseñas en el código no tiene perdón de dios, pero que además, en 2006 aún guarden contraseñas en plano en una BBDD no tiene palabras.
Otra prueba más es el hecho que la empresa de seguridad encontrara tantas vulnerabilidades, ¿por qué no la contrataron antes? desde luego tanto despropósito les ha salido casi regalado: 1,11 €/cliente afectado (entendiendo que los 6.000 € de multa es el monto total).
Creo que el desarrollo de las aplicaciones internas, así como la configuración y uso de la infraestructura ha sido bastante deficiente. La cuantía de la multa debería haber sido muy superior, y la resolución haber llegado bastante antes, porque creo que es bastante evidente su dejadez. Como he dicho, tanto el poner contraseñas en el código como guardar contraseñas sin cifrar debería haber provocado que se dictase la resolución al momento.
Saludos.
Alejandro Sanchez Valdezate
Arsys no es santa de devoción de la mayoría de los que hacemos web, tanto si somos diseñadores como si damos hosting. En este caso, no creo que a nadie le entristezca mucho. Es más, 6000 euros es una cantidad un poco irrisoria para una empresa de ese calibre. No se sabe si se trata de darle un capón o de que las autoridades no consideraron que la cosa fuera más importante.
Informático
Yo no llamaría a una inyección SQL como esta que «se podía acceder sin restricción a través de Internet a los ficheros, que contienen datos de carácter personal relativos a los clientes de ARSYS.»
Lo que debería haber mirado Arsys es por qué los atacantes sabían que debían buscar la columna CDA_L0G1N. Parece que le hayan dado ese nombre precisamente para dificultar que un ataque a ciegas la encontrase.
Lo que veo más preocupante es que a la hora de adoptar medidas, cifran las contraseñas, y lo hacen con un cifrador débil como RC4, en lugar de usar una función hash como -al menos- md5, o sha1.
Para cifrar las contraseñas que tienen en plano (algo imperdonable) les piden que las cambien, en lugar de cifrarlas ellos mismos (¡ya las tienen!).
Encima, el filtrado de ataques SQL se hace con una función que «filtra las
palabras clave del lenguaje SQL». Si gestionan bien las comillas, no necesitan filtrar las palabras clave. Parece uno de esos módulos genéricos para añadir seguridad que nunca son completos.
Pit
– Un ataque de inyección de SQL hace mas de 5 años podria haber sido perdonado, pero desde entonces para acá resulta ser una grave falta de diligencia, y mas en un ISP.
– Que tuviesen las contraseñas en claro resulta ser una falta de diligencia extrema.
– Evidentemente, alguien vende información a los periodistas, sino la noticia no habria llegado a la prensa, y con ello tampoco a la AEPD, con lo que se habrían librado.
– Tengo entendido que la cosa llegó al juzgado, por lo que pienso que la fuga salió de allí. Y deberia haber sido el propio juez quien trasladase a la AEPD la noticia, en lugar de llegarles a través de la prensa. Pero muchos jueces todavia no saben lo que es la protección de datos o no le dan importancia.
– La levedad en la sanción, pues ya lo sabemos, la AEPD aplica el 45.5 casi como un estandar.
Pit
Roberto J. Alcalá Sánchez dijo:
La cuantia la decide el director de la AEPD, en base a la información de la que disponga, si bien no se hace publica toda la información. Por ejemplo, la auditoria de seguridad seguro que les costó un pico. Y la publicidad de la resolución les hará bastante daño.
Respecto de dictar la resolución de inmediato:
1.- colar este caso delante de otros puede suponer que alguno de esos otros prescriba. A ti este caso te parecerá muy importante, pero al denunciante del otro que prescribiese seguro que su denuncia le parece mas importante.
2.- La AEPD ya ha recibido algun toque del Defensor del Pueblo por no no seguir el orden de entrada de las denuncias en la Agencia. Se les ha perdonado por la falta de medios de la Agencia (la entrada de denuncias se ha doblado en un año, mientras que los inspectores son ahora menos que entonces). El criterio que tienes de respetar el orden de prescripción me parece muy razonable, aunque esto ha sido modificado por el nuevo reglamento, que impone un tiempo de un año entre la entrada de la denuncia y la resolución de archivo/apertura de procedimiento sancionador, con lo que ahora trabajan con lo que llaman en tiempo mas temprano (minimo del fijado por la prescripción o caducidad).
3.- El procedimiento sancionador dura 6 meses maximo. Y eso no se puede evitar, sino se provocaria indefensión y el recurso ante la audiencia nacional siempre tendria éxito.
Así que han tardado lo que tenian que tardar. Tu ves únicamente el problema de este caso. El director de la AEPD debe ver el problema de todos los casos.