El "Leak Del Login", El GDPR Y El Esquema Nacional De Seguridad

No es la primera vez que hablo del "Leak del Login", pero como sorprendentemente me lo sigo encontrado en muchos sitios, voy a volver a hacer un pequeño artículo hoy sobre él, pero centrándome en su relación con el GDPR y el Esquema Nacional de Seguridad, pues es común encontrarlo en webs que han pasado la auditoría del ENS y tienen sus documentos de GDPR en regla. Voy a volver a hablar un poco de él, solo por hacer hincapié de la necesidad de que se eliminen las webs "verbose" que dan afiliación de personas a sus servicios de manera tan sencilla.

Figura 1: El "Leak del Login", el GDPR y el Esquema Nacional de Seguridad

Por supuesto, no soy experto en leyes y regulación, que para eso cuento con un equipo maravilloso, pero creo que erradicar estos bugs en las webs - sea un incumplimiento o no - es bueno para los clientes o usuarios de un servicio online, sea este el que sea.

"Leak del Login"

He hablado mucho sobre este tema, pero en resumen es tan sencillo como utilizar alguna de las capacidades de un servicio digital que se pueden utilizar sin haberse autenticado aún para saber si un usuario tiene o no cuenta en esa plataforma. Estas capacidades son tan comunes como:

Proceso de iniciar sesión o "Login".
Proceso de darse de alta o "Sign in".
Proceso de recuerpar contraseña o "Forget Password".

Estos tres procesos, que pueden parecer asociados a entornos autenticados, no lo son, pues todos pueden ser invocados sin necesidad de estar autenticado. Es normal que el proceso de "Iniciar Sesión" se lance desde una sesión no autenticada, al igual que es normal que un proceso de "Registro" deba realizarse desde una cuenta aún no regristrada, y lo mismo con el proceso de "Recuperar la contraseña".

Gestión de errores "verbose"

Todos son procesos tienen en común que en un determinado momento deben comprobar la identidad de la persona, ya sea por medio de un DNIe, un número de teléfono, un usuario o un correo electrónico, que es muy común. Y en todos ellos, la gestión de errores, debe ser clave, ya que si alguien puede usar un DNIe, un número de teléfono, un nombre de usuario o un correo electrónico de una persona que no sea ella, podría saber si tiene afiliación con esa plataforma. Es decir, si tiene una cuenta en ese servicio digital, lo que es un problema de privacidad, que puede ser utilizado como una forma de ataque contra la seguridad de la persona.

Figura 2: Se informa al que introduce el e-mail de si la cuenta existe o no
en un proceso de Registro

Para que entendáis el proceso, es como si alguien llegara a la recepción de una empresa y comenzara a preguntar si es cliente suyo una persona, y luego otra, y luego una tercera, y así hasta el infinito. Lógicamente, esto es una aberración y seguro que ninguno de vosotros lo permitiría en su empresa. Dar la lista de personas que han usado los servicios es algo que no entra dentro de lo entendible. Si eres una plataforma de masajes, ¿dejarías que alguien preguntara si una persona es cliente o no te tu empresa? No.

Figura 3: Proceso de Recuperación de contraseña con Leak

Pero por desgracia si los mensajes de error en esos tres procesos no están controlados, es como si hicieras eso. Si cuando alguien pide iniciar sesión y el sitio dice "Esta cuenta no existe" cuando la cuenta no existe, y "Contraseña errónea" cuando la cuenta existe, pues ya has dado todas esa información en el Login.

Figura 4: Cuando la cuenta existe, envía el email de recuperación.

Lo mismo para Recuperar la contraseña, si cuando pones un e-mail, un DNIe o un número de teléfono, la web dice "La cuenta no existe" cuando no se ha dado de alta y "Te hemos enviado un mensaje para que continúes con el proceso" si la cuenta existe, pues lo mismo. Y en el proceso de Registro lo mismo, si te dice "esta cuenta ya existe" entonces, más claro el agua.

Cómo no ser "verbose"

Resolver este bug consiste en construir la lógica de manera que no llegue nunca un mensaje que sirva para saber si la cuenta existe o no en ninguna zona no autenticada. Y las soluciones son sencillas y se hacen en comunicaciones privadas. Cada uno de forma diferente, por ejemplo:

Login: Un mensaje de error de "Error en el usuario o la contraseña" en todas las situaciones en las que falle el proceso de login, no da ninguna información.

Registrarse: Se pide un correo electrónico o un número de teléfono, y se le informa por la web que se le va a enviar un mensajes para continuar con el proceso. Si la cuenta existe se informa por mensaje que alguien quiere crearse una cuenta con su identificador, que si es él ya tiene cuenta y puede recuperar la contraseña si no la tiene. Si es una cuenta nueva que aún no existe, se le envía un enlace al dueño del identificado para que continúe con el proceso de registro. De esta forma solo el dueño del e-mail o del número de teléfono pueden tener la información.

Figura 5: Proceso sin leak de información en proceso de Registro

Recuperar la contraseña: Con un mensaje de "Si esta cuenta existe, recibirá un mensaje en us buzón". Y se aplica la misma política que en el caso anterior. Se le envía el mensaje para recuperar la contraseña si existe y el enlace de darse de alta si la cuenta no existe.

En los tres casos, se consigue que no se dé información de afiliación de una identidad a un servicio, y por lo tanto se mejora la privacidad y la seguridad del cliente o usuario de la plataforma.

Riesgos de conocer la afiliacion.

No somos nuevos en esto, y ya hemos visto que conocer la afiliación de una persona es un riesgo para esta persona a varios niveles:

Privacidad Personal: En el caso del leak de datos de Ashley Madisson, las personas que estaban dadas de alta en esta plataforma sufrieron acoso público, extorsiones, y algunos llegaron a cometer suicidio o ser despedidos de sus puestos de trabajo. Si hablamos de webs de contactos con orientaciones sexuales concretas, puede ser un incumplimiento de la privacidad de las personas.

Perfilado social: Por desgracia, los algoritmos de generación de insights con Machine Learning nos etiquetan en todo, desde reputación en Internet hasta Credit Scoring, hasta los anuncios que recibimos en la web. En casos como los de Cambridge Analytica, vimos que este perfilado de forma masiva podría llegar a utilizarse para difundir Fake News adaptadas que cambiaran el curso de votaciones políticas. A muchos se les ha olvidado ya.

Figura 6: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

Ataques de Spear-Phishing: Si se tienen datos de que una persona tiene cuenta en una plataforma, hacerle un ataque dirigido de phishing para robarle credenciales, tokens OAuth o simplemente infectarle con malware es mucho más efectivo. Si recibes un phishing de un banco donde tienes cuenta es más fácil que piques.

Ataques de Watering Hole: Si se sabe que una persona visita un servicio o una plataforma, se puede encontrar con que la web sea vulnerada para atacarle a él, o simplemente que aparezcan otros usuarios maliciosos dentro de la plataforma que le hagan una encerrona más imaginativa. Como encontrar al amor de tu vida dentro de esa plataforma, y que no sea más que un ataque elaborado.

Así que, filtrar el "Leak del Login", genera muchos problemas para la privacidad y seguridad de las personas que es lo que hay detrás de los usuarios y clientes y de un servicio online. Personas.

GDPR y Esquema Nacional de Seguridad

Dicho esto, el "Leak del Login" es un bug de privacidad. Un fallo. Algo que es muy sencillo de explotar, pero que es un fallo, ya que filtra la afiliación de personas a una web, y por tanto hay que eliminarlo. Sin embargo, he visto muchas webs de grandes empresas - y seguro que es fácil localizarlo en muchas apps, y muchos dominios - que no le prestan la menor atención a esto.

Figura 7: Leak del Login en WordPress.com

Incluso los componentes comunes de login de plataformas de e-Commerce, CMS, Blogs, redes sociales como Instagram o TikTok sufren este bug. La propia WordPress.com tiene este "Leak del Login", pero es fácil encontrarlo en Bancos con DNIs, en redes sociales, empresas de transportes, etcétera.

Figura 8: Libro de Ethical Hacking 2ª Edición de 0xWord
escrito por Pablo González Pérez

Y por supuesto, con procesos de GDRP y de Esquema Nacional de Seguridad pasados, lo que me deja un poco perplejo. Creo que esto debería estar entre las pruebas de auditoría básica de cualquier servicio digital, al igual que la búsqueda de metadatos en todos los documentos ofimáticos publicados externamente. Así que, si haces auditorías de GDPR, de ENS o simplemente un Hacking Ético, por favor, reporta todos los "Leak del Login" a ver si somos capaces de mejorar un poco la privacidad de las personas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)