Breaches: el negocio de nuestras contraseñas



Modo noche


Hace días asistimos a una fuga de información en una aplicación de Facebook y nos echamos las manos a la cabeza. Sin embargo, pocos conocen que nuestros datos llevan años online (incluyendo nuestras contraseñas y tarjetas de crédito) a la vista de todo el mundo. Si, hablo de nuestras contraseñas. No, no es un eufemismo.

Una simple búsqueda en Google (desde la sencilla “email combo list” hasta el dork inurl:pastebin intext:”*@*.*:*”) devuelve millones de resultados de volcados de datos.

Adentrándonos en sólo una de las páginas descritas, nos encontraremos de cientos a miles de archivos. Cada archivo contendrá de cientos a millones de cuentas “hackeadas”, con su respectiva contraseña.

Entre todas ellas estará más que probablemente la tuya.

image

Un típico dump en pastebin, censurado.

Un breach (a.k.a. leak / dump / combos) es un incidente de seguridad conocido como fuga de datos, habitualmente relacionada con la publicación de datos personales y de acceso a diversos servicios.

El término acoge tanto a la fuga involuntaria de datos, como el acceso de persona no autorizada a los mismos, el fallo de sistemas de seguridad, la pérdida de volúmenes físicos (dejarse el pen en la copistería, etc.) inside jobs… En esta ocasión, nos vamos a centrar en el escenario típico, donde alguien voluntaria e ilegitimamente se introduce en un sistema, se apodera de los datos y los recopila para diversos usos.

No se trata de un fenómeno novedoso, y afecta a más usuarios de lo que se piensa, con unas consecuencias imposibles de determinar. No obstante lo anterior, tiene un ciclo de vida determinado que a continuación detallamos. Aquí te dejo una nube de breaches que han ocurrido y la cantidad de usuarios que fueron afectados.

Cómo se consigue un dump, y por qué se venden en el mercado negro

Un grupo de hackers encuentra una vulnerabilidad en una web de uso masivo (ej. Yahoo Mail, Dropbox, Tumblr…) y se organizan para realizar una raid. Dependiendo de la vulnerabilidad, cada uno tendrá una misión en la operación, que tendrá por objetivo la obtención de los máximos datos personales de los usuarios del sericio atacado.

image

117 millones de passwords fueron robadas de LinkedIn (y vendidas) hace escasos años

Las bases de datos son volcadas en uno o varios archivos (dumps), que se organizará en un formato machine friendly para la posterior automatización de los ataques individualizados. Es habitual encontrarse con combos con este formato:

[email protected]:contraseña

[email protected]:clave ….

La venta 0day en la dark net

Los datos son habitualmente utilizados para realizar ataques automatizados, enviar spam, obtener información sensible de las cuentas de correo, beneficiarse de servicios de pago contratados por los usuarios hackeados, e incluso escalar privilegios desde el correo (por ej. haciendo uso de la opción de recordar contraseña, o probando las credenciales de forma automatizada en cientos de webs). Imagináos los usos ilícitos: blackmailing (chantaje), robo de información secreta, propiedad industrial, ataques a sistemas críticos (v.gr. SCADA)…

Es muy habitual que estos datos se vendan a personas que buscan concretamente usuarios de una página o de un sector concreto, habitualmente en foros de redes I2P o Tor, que supuestamente conservan el anonimato (en otro post hablaré de las lindezas de estos sistemas).

image

Un usuario busca un producto concreto, pero quiere saber primero si la mercancía es buena.

Estos datos ilícitamente obtenidos no se hacen públicos en un primer momento, porque su frescura (conocido en el argot como 0day, día cero) y el desconocimiento del breach los hace especialmente valiosos. En la gran mayoría de los casos, ni los usuarios ni las empresas saben que han sido hackeados en este momento.

Le puede interesar también:   Tres herramientas probatorias gratuitas para el abogado 3.0

La reventa en la deep web

Después de haberse vendido escasas horas desde su obtención, los mismos compradores primarios revenden la información en foros especializados por cantidades muy bajas, pero masivamente.

image

Todo un catálogo de datos robados para comprar.

Estos nuevos compradores van a comprobar si la información sigue siendo útil (si los usuarios todavía no han cambiado las claves, o no han anulado las tarjetas de crédito por ejemplo) y continuarán revendiéndolas, hasta que cualquiera de ellos la publique gratuitamente.

Public leaking en la surface web

Es un paso que siempre llega, aunque nunca me quedó del todo clara la causa. Es muy habitual que un usuario que posea la base de datos la publique libremente en Internet. Entiendo que las causas pueden ser [1] el cumplimiento de una amenaza de divulgación de datos privados, al no haber sido atendido el rescate, [2] la ideología del libre accesoa la información llevada al extremo, o [3] una venganza contra los “revendedores” por la mala calidad del producto, evitando que sigan ganando dinero con su reventa [nadie compra lo que es gratis].

image

Sírvase ud. mismo. Un pequeño trozo de una página inmensa dedicada a la recopilación de breaches.

A medida que el breach se conoce, la gente cambia sus claves y ello provoca una pérdida de funcionalidad del mismo. En esta fase, aunque se hayan cambiado las claves, siguen restando ataques de ingeniería social, como ahora veremos.

El residual credential reuse y el escalado de privilegios

La reutilización de credenciales es un ataque de ingeniería social que se aprovecha de que muy habitualmente reutilicemos las mismas contraseñas en distintos servicios. Así, aunque el breach fuera descubierto y se obligaran a los usuarios a cambiar sus claves, este ataque se basa en que “en algún servicio se te ha olvidado cambiarla”…

image

Captura de Cr3d0v3r, un script que comprueba si nuestras claves antiguas publicadas en incidentes de seguridad siguen valiendo en diversos servicios (linkedin, gmail, etc.)

El “derecho al olvido” puede eliminar breaches de la Internet superficial, pero difícilmente de otros niveles y redes como Tor. Por eso, la prevención y la rápida actuación por parte de las empresas es esencial.

Qué dice la normativa española y europeaante una fuga de datos

El RGPD es claro al respecto: protocolo, protocolo y protocolo. Otra manifestación más de la autorresponsabilidad, de la due diligence americana, que cada vez tiene mas calado en Derecho Europeo.

Para resumir al máximo, vamos a atender a las directrices de la LOPD (y el RGPD) y sin perder de vista a la LSSI, para tener una idea somera de cómo actuar.

Antes de 72 horas debemos poner en conocimiento de la AEPD el problema (data breach notification, art. 33 y ss. del Reglamento), tratar de identificar a las personas responsables (insiders / outsiders), recopilar información, buscar una forma de mitigar el problema, ejecutarla y comprobar los resultados obtenidos.

El incidente se ha de comunicar a los afectados (art. 34 del Reglamento) lo que pondrá en riesgo la credibilidad e imagen de la empresa sin lugar a dudas, pero beneficiará a los interesados dado que podrán iniciar acciones tendentes a la mitigación de la fuga (anulación de tarjetas de crédito, cambio de contraseñas, etc.)

Le puede interesar también:   ¿Es legal hacerse un perfil falso?
image

Magnífico esquema de gestión de la fuga de información, realizado por el INCIBE a la luz del RGPD.

Pérdida de datos relacionada con el incidente de seguridad

No es raro encontrarnos con el problema de que los intrusos han borrado la información sustraída. En estos casos, la solución siempre viene dada por actividades preventivas (data loss prevention) realizadas con anterioridad al ataque, tales como la creación periódica de copias de seguridad. Virtualizar e isolar los equipos es una buena idea, pero mejor aún es tener un sistema de copias de seguridad automáticas (ej. creación diaria de snapshots cifrados de las máquinas).

El mercado gris: Qué dice la normativa americana, y por qué abre la puerta a nuevos modelos de negocio en la ciberseguridad

La legislación norteamericana relativa a las fugas de datos cambia en cada Estado, pero todos ofrecen protección al consumidor y establecen medidas de reparación como la indemnización civil e incluso de represión, con condenas penales. Aquí tienes un cuadro resumen de la legislación en materia de data breaches en Estados Unidos.

En la zona oeste de EE.UU. (probablemente también ocurre en otras zonas) la jurisprudencia establece ha establecido el criterio de considerar información pública el contenido del breach cuando la información ha acabado en un buen número de personas no intervinientes en el ataque, permitiéndose su distribución y uso. No obstante lo anterior, no consideréis que ocurre lo mismo en Europa.

image

Snusbase lo tiene claro.

Nuevas empresas están ofreciendo un servicio gris pero muy útil, basado en recopilar todas las fugas de datos en un gran servidor constantemente actualizado, y ofreciendo un servicio de aviso a sus clientes cuando se detecta un nuevo incidente de seguridad donde sus datos se han visto comprometidos, a fin de cambiar las claves lo antes posible.

La versión gratuita y mas ética del mercado la encontramos en haveibeenpwned.com, aunque la efectividad del mismo dependerá de la diligencia que tengan sus creadores en recopilar los dumps. La página anterior tiene la decencia de no publicar las claves y limitarse únicamente a indicar si existen registros. No podemos decir lo mismo de otros servicios, que nos abstendremos de citar aquí por motivos evidentes.

No nos vamos a librar de las fugas de datos – probablemente – nunca, así que mientras más nos acostumbremos y aprendamos de ellos, más seguros permanecerán.

image

Jaula de Faraday para servidores, de Argent. Puede parecer una locura, pero se pueden descifrar contraseñas gracias a las interferencias electromagnéticas (ataques de canal lateral)

¿Qué podemos hacer?

Cambiar las contraseñas periódicamente. Ello limita el tiempo de exposición que pudiera tener nuestra clave actual en un breach. A todos desagrada cambiarlas, pero es básico. Hay que hacerlo.

Formación. El eslabón más débil es el factor humano. En el caso de las empresas que manejen este tipo de información protegida, una sólida formación especializada (para evitar por ej. ataques de phishing o de ingenieria social) es fundamental.

– Usar una clave distinta para cada servicio. Es un coñazo, pero el credential reusing se aprovecha del gravísimo error que cometemos todos al designar la misma contraseña para todos nuestros servicios, de forma que hackeado uno, hackeados todos. También sería acertado no utilizar direcciones de correo corporativas con estos servicios. Evitemos registrarnos con las direcciones del curro en cualquier servicio, especialmente si es gratuito (si el producto es gratis, el producto eres tú).

Le puede interesar también:   Deber de sigilo y Ley de Secretos Oficiales

Antes de mitigar, detectar. Se producen millones de ataques automatizados a diario. Lo esencial es detectar y registrar el comportamiento de los potenciales atacantes, evitando por cualquier medio que puedan borrar rastros (fuzzing). Me juego una cerveza a que si miras los logs del router de tu casa verás cientos de intentos de ataque desde algún lugar recóndito de China.

Custodiar los datos de propia mano. Pese a que podemos tener los datos de nuestros clientes en servicios cloud, me parece una absoluta falta de responsabilidad, y bastante gris en relación al nuevo RGPD. Aunque un servicio cloud puede tener (no siempre) expertos en seguridad, a los hackers les conviene atacar un servicio que contenga muchos clientes en vez de jugársela a una sola carta. Un servidor discreto e isolado debería bastar.

Contratar a expertos en ciberseguridad. Es algo que no puede seguir postergándose. Es necesario la constucción de un blue team en cada empresa, que analice cada conexión entrante y saliente, y permita el parcheo en caliente de los problemas que puedan surgir. El desarrollo de algoritmos de detección comerciales está muy bien, pero cada negocio (y producto) es un mundo. Un antivirus/antimalware/firewall puede proteger nuestro Magento (por ej., o cualquier aplicación conocida y de uso generalizado) pero puede que no lo haga en el caso de aplicaciones propietarias hechas a la carta. Todos necesitamos seguridad también a la carta y tener un protocolo legal y que exima lo máximo de responsabilidad al responsable de tratamiento y/o a la empresa.

Isolar. Aislar físicamente los servidores y utilizar redes privadas virtuales. No basta únicamente con utilizar firewalls, hay cientos de formas de transmitir información sensible (por ej. con el ruído de los ventiladores de refrigeración, con las bombillitas parpadeantes de la CPU, por las variaciones de consumo eléctrico… son los llamados ataques de canal lateral). No estoy exagerando cuando hablo de la efectividad de las jaulas de Faraday, en pocos años será un must have. Si te sigue pareciendo una exageración, deberías saber que la carcasa metálica de las CPUs son jaulas de Faraday, como también lo es la malla de pantalla que tienen los cables coaxiales. Allá donde hay pérdida, hay emisión involuntaria de datos (EMI’s) que pueden reinterpretarse.

Encriptar. Una fuga de datos de información encriptada tiene un tratamiento mucho más benévolo por parte de las Autoridades. Mezclar una conocida encriptación estandarizada con una propia del servicio parece una idea genial. Si los hackers sólo consiguen basura encriptada (y si no tienen procesadores cuánticos) tardarían años en descifrarla.

– Actuar para que exista una regulación ad hoc que proteja a usuarios y a prestadores de servicios de la información. Hablo de actuar por vías democráticas para promover la regulación responsable. La máxima de “los delitos son los mismos, los medios son los distintos” no implica que debamos dejar inactivo al legislador. Hay que crear una legislación exhaustiva contra los delitos informáticos y fraudes online, especialmente en lo relativo al big data (¿acaso los data breaches no son bases de datos?), manteniendo la neutralidad de la red. La normativa actual se queda muy corta y regalará espacios de impunidad ante la injusticia.



~

Este post ha sido escrito por José Carlos Rueda, abogado. Puede hacerle una consulta haciendo click aquí.

0 comentarios

Añade el tuyo →

Deja un comentario