Parece increíble, que a día de hoy, una empresa de la supuesta categoría de Yahoo! pueda sufrir un ataque de estas características, tanto por el sistema que habrían usado los Hackers como por tener dicha información Yahoo! en texto plano.

La noticia saltaba en todos los noticieros de tecnología hace unas horas, y es que un grupo de Hackers había filtrado un listado de más de 450.000 cuentas de correo, con sus respectivas contraseñas, de un servicio de Yahoo! llamado “Yahoo Contributor Network”. Dado que no es un servicio solamente asociado a las cuentas de Yahoo, la filtración afecta a cualquier usuario con independencia del proveedor de correo electrónico que use. El listado hecho público puede verse en el enlace publicado por el mismo grupo en la siguiente dirección por si cualquier usuasrio quiere comprobar si está o no en la lista.

http://74.208.161.170:81/yahoo-disclosure.tar.gz

 

Pero antes de ver las negligencias por parte de Yahoo! creo que es igualmente importante ver las repercusiones de filtraciones de este tipo y calibre:

 

-El eterno problema de usar una contraseña para todo

La filtración tan solo son credenciales de acceso a un servicio de Yahoo!, eso quiere decir que cualquier usuario podría haberse dado de alta con una cuenta de correo cualquiera y una contraseña cualquiera, no necesariamente la contraseña de su cuenta de correo. ¿Que sucede? Que de todos es bien sabido que la mayoría de los usuarios usan una o dos contraseñas a lo sumo para todo. Eso quiere decir que muchos de los usuarios/contraseñas del listado, son las mismas credenciales de esos usuarios de sus correos electrónicos y otros servicios.

-Cuentas antiguas

Es cierto que la filtración pertenece a cuentas antiguas, muchos de los correos electrónicos que aparecen ya no existen desde hace años, y la mayoría del resto modificaron hace tiempo sus contraseñas. Eso no quiere decir que no existan muchas cuentas válidas. Hablamos de algo menos de medio millón de cuentas, y son muchos los que desde hace casi 24 horas están apurándose en cambiar al verse en la lista publicada.

 

Comencé hablando de negligencia por parte de Yahoo!, y es así. Veamos, es evidente que a día de hoy no hay un sistema de seguridad que sea totalmente invulnerable, y los métodos de ataques de los hackers pueden ser extremadamente sofisticados. No obstante, parece mentira que una gran empresa como Yahoo! se vea expuesta primero por vulnerabilidades más que conocidas, y por otro lado que no tenga el grado de seguridad que se exige a cualquier particular o empresa que maneje datos sensibles.

 

Inyección SQL

En primer lugar, los hackers lograron el acceso a la base de datos por medio de una técnica llamada SQL Injection. Básicamente lo que se hace en estos casos es tomar cualquier formulario, campo de búsqueda,URL preformada… lo que sea haga uso directo de la base de datos que se quiere tomar, y se introducen datos específicos para lograr un comportamiento deseable y predecible a esa base de datos, generalmente volcar de ella determinados campos como por ejemplo los usuarios y las contraseñas. En realidad el ataque en sí es simple es simple, lo complicado es saber donde, como y por qué.

Para quien quiera saber algo más del asunto. A día de hoy prácticamente todas las aplicaciones web o servicios web usan bases de datos para almacenar toda nuestra información, desde nuestras credenciales de seguridad, fechas y horas de accesos, flags, comentarios, cookies de sesión… de todo. El ejemplo más minimalista sería por ejemplo que la base de datos tan solo tuviese una tabla con dos columnas: Usuario y Contraseña. ¿Que utilidad podría tener una tabla así? Es evidente, el sistema tiene que tener almacenados de algún modo la información de sesión de los usuarios, así cuando este quiere acceder a esos servicios, al introducir la información esta pueda cotejarse en la base de datos, si ambos valores coinciden, se permite el acceso. Por tanto, es evidente que en algún momento del proceso de identificación, cambio de contraseña, validación… de este ejemplo, los datos introducidos por el usuario deben de ser enviados al servidor del proveedor de servicios, una vez allí se usarán en alguna petición que se hará frente a la base de datos y la base de datos simplemente se limitará a responder en función de la información suministrada. A priori este sistema tendría que ser totalmente seguro ya que está todo gestionado en el mismo servidor, pero el usuario podría introducir en sus casilleros (ya sea en el del a contraseña, en el del nombre de usuario, en el de búsqueda…) un valor que inteligentemente haga que la petición teórica que debía de hacer el servidor a la base de datos sea otra. Esto es posible cuando el servidor no comprueba (o se le escapa algo) sobre todo los caracteres especiales tipo $, >, <, “, @… Dichos caracteres generalmente son usados en consultas en las bases de datos, o son simplemente caracteres de fin de petición o inicio de otra, caracteres condicionales… si el servidor no es capaz de filtrarlos correctamente, el usuario en vez de a lo mejor estar introduciendo su nombre de usuario para que sea cotejado en la base de datos, está introduciendo una cadena de caracteres que hará que la petición inicial de devolver el nombre de usuario realmente devuelva su contraseña, o por ejemplo el listado completo de la tabla:

Pongamos que el código SQL de un servidor para una petición es el siguiente:

SELECT lista
  FROM tabla1
 WHERE campo1 = '$EMAIL';

En teoría es una petición simple sin ningún posible error. Lo que haría esa petición sería seleccionar de la tabla1 en la base de datos las filas en las que el campo (columna) “campo1″ coincidiese con la variable $Email que el sistema toma de nosotros. Es decir, si el usuario hubiese introducido el correo: pepe@perico.es, la variable $Email sería dicho correo electrónico, y dicha petición por tanto devolvería al servidor un listado con todas las filas en las que aparece dicho correo electrónico en la columna correo. Como digo esto a priori no tiene mayor problema. ¿Pero que pasaría si el sistema no es capaz de filtrar correctamente el caracter especial ‘ (apostrofe)? Si dicho caracter fuese posible introducirlo, al servidor en la variable $Email le llegaría como dato simplemente ese apostrofe, quedandose la última línea en algo como esto: WHERE campo1 = ”’;

Esto es un problema enorme. Si jugásemos un buen rato, a lo mejor podríamos introducir algo como “z’ OR apellido like ‘%Ruiz%”. Eso haría que en el lado del servidor se construyese algo totalmente diferente:

SELECT lista
  FROM tabla1
 WHERE campo1 = 'z' OR apellido LIKE '%Ruiz%';

Es decir, habríamos inyectado códjgo SQL en la petición original. Con z’ el servidor tomaría la sentencia en dos partes, la primera como ‘z’ (y de ahí a la utilidad de poder enviar un apostrofe) . De este modo el servidor ejecutaría simplemente nuestra segunda sentencia por estár condicionada con un simple OR, devolviendonos a lo mejor el correo electrónico o el nombre o incluso la contraseña (dependiendo de la base de datos claro está) de cualquier usuario en el que se encontrase “ruiz” en su apellido.

 

 

Texto Plano

 Igualmente peligroso y complementa inexplicable es el almacenaje de contraseñas en texto plano. De echo aquí en España la LOPD (Ley Orgánica de Protección de Datos) prohíbe taxativamente que cualquier organismo, entidad e incluso usuario. que almacene contraseñas sin estar protegidas. Así queda establecido en el Reglamento de la Ley Orgánica de Protección de datos (RLOPD) en su artículo 93 (Real Decreto 1720/2007):

 

Artículo 93. Identificación y autenticación.

1. El responsable del fichero o tratamiento deberá adoptar las medidas que garanticen la correcta identificación y autenticación de los usuarios.
2. El responsable del fichero o tratamiento establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado.
3. Cuando el mecanismo de autenticación se base en la existencia de contraseñas existirá un procedimiento de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad.
4. El documento de seguridad establecerá la periodicidad, que en ningún caso será superior a un año, con la que tienen que ser cambiadas las contraseñas que, mientras estén vigentes, se almacenarán de forma ininteligible.

 

Queda por tanto totalmente prohibido bajo sanciones muy duras (repito, aquí en España al menos) el uso de cualquier sistema que almacene nuestras credenciales en texto legible/reversible (lo que llamamos comunmente “texto plano”). La siguiente pregunta que se hacen mucho es que si no se almacena nuestras contraseñas en texto plano ¿como puede verificar un servidor si los datos introducidos son correos o no? Muy simple, simplemente por comparación, usando hash criptográficos por ejemplo. Un ejemplo simple:

Contraseña en texto plano introducida por el teclado por el usuario: Mariposa
Hash SHA1 aplicado a Mariposa: 8ACEF7C1C4B46DABCAB5A7B70AF2C52CD72FD00A

El servidor en este caso no almacenaría en su base de datos en el campo contraseñas el texto “Mariposa” sino la cadena “8ACEF7C1C4B46DABCAB5A7B70AF2C52CD72FD00A”. El usuario cuando introduce su contraseña en la página de inicio de sesión de este servicio de ejemplo, esta sería convertida en el mismo equipo del usuario a su Hash SHA1. El Hash sería el que viajaría por todo internet hasta llegar al servidior de destino, donde simplemente se cotejaría con el valor almacenado en su base de datos. Si coincidiesen se permitiría el acceso.

Este sistema garantizaría que aun cuando se filtrase un listado que incluyese tanto nombres de usuarios como sus contraseñas (en forma de Hash criptográfico), la repercusión sería mínima, ya que una de las propiedades principales de los Hash Criptográficos es la de convertir cualquier cadena (por ejemplo una contraseña) en una cadena de caracteres hexadecimales generalmente de longitud fija IRREVERSIBLE, en la que cualquier cambio en la cadena de entrada alteraría totalmente la cadena de salida. Eso quiere decir que aunque supiésemos que la contraseña cifrada de un usuario es 8ACEF7C1C4B46DABCAB5A7B70AF2C52CD72FD00A, no tendríamos forma humana (aceptable) para revertirlo a su origen, “Mariposa”.

Por supuesto, se podría crear una tabla en nuestro equipo con los Hash SH1 de todo el diccionario español y se podría comparar el hash obtenido con nuestra base de datos de Hash y ver si existiese una correspondencia… pero para evitar esto existe igualmente multitud de técnicas como el uso de Salt, Hash aplicados dos veces… etc etc etc.

Esta es la razón por la que cualquier servicio que tenga una seguridad mínima, siempre podrá permitirnos resetear nuestra contraseña, pero jamás debería poder reenviarnos la contraseña antigua, puesto que ni el propio servidor debería de ser capaz de conocerla. Dicho de otro modo, si le damos a recordar contraseña a cualquier servicio que tengamos que esté en un servidor Español, y nos llega un correo con la contraseña antigua, podemos denunciar ante la Agencia de Protección de Datos Española dicha empresa, y les caerá un buen paquete.

 

 

Como protegernos

Nunca hay que ser alarmista, a día de hoy existen medidas de seguridad prácticamente invulnerables, y en conjunción con la buena praxis debería de mantenernos siempre alejado de posibles peligros. Evidentemente no siempre depende de nosotros, y no podemos saber como son tratados nuestros datos por terceros o si sus sistemas cumplen con un mínimo de seguridad. Pero por otro lado si hay mucho que podamos hacer, y que en su gran mayoría nadie hace… ya sea por desconocimiento o por pura imprudencia. Todas ellas son de fácil aplicación:

 

  • Acceso mediante Certificado electrónico (DNI-e, CERES) cuando sea posible: Bancos, Administración Pública…
  • No acceder jamás a sitios sensibles en redes públicas o privadas de gran difusión sin conocer bien los sistemas de seguridad que usan dichos con antemano: En el trabajo, universidades, redes Wifi de terceros…
  • Proteger correctamente las redes WIFI Domésticas para que sea imposible que un topo se cuele y pueda acceder a nuestro tráfico que no se esté cifrando: Usar WPA2-PSK con AES y frases de paso.
  • Jamás usar contraseñas repetidas en la medida de lo posible, o por lo menos en aquellos servicios importantes: Paypal, Bancos, Correo Electrónico…
  • Usar siempre contraseñas alfanuméricas combinando letras mayúsculas/minúsculas y números para evitar que sea posible ataques de FuerzaBruta: SoyLaRe1naDeLosMares
  • No usar jamás palabras simples de nuestro diccionario, no usar jamás nombres propios, de mascotas…
  • Conocer un poco los servicios que usamos y si brindan un mínimo de seguridad, comprobar si almacenan nuestras contraseñas haciendo uso del restablecer contraseña clásico
  • No usar preguntas de seguridad, existen método de identificación auxiliares infinitamente más fiables: SMS con códigos de identificación, llamadas al móvil para verificar la identidad…
  • No almacenar en los navegadores de equipos de terceros las contraseñas de nuestros sitios, e incluso pensar detenidamente si queremos que se guarden en el nuestro ante la posibilidad de que alguien tenga acceso a nuestro equipo
  • No usar en lo posible dispositivos de terceros para acceder a nuestros datos, no sabemos si han sido manipulados.
  • Asegurarnos de que antes de introducir cualquier contraseña el tráfico se esté realizando bajo protocolos seguro tipo TLS/SSL (https en las webs), y que por supuesto la comunicación se mantiene cifrada durante toda la sesión.
  • Usar cuando sea posible sistemas de autentificación doble: SMS o tablillas de coordenadas de los bancos, la Doble autentificación de Gmail…

Por mucho que duela, el 90% de todas las infracciones de seguridad, de todos los robos de contraseñas, accesos a cuentas y otros comienzan porque el usuario cometió alguna imprudencia. En este caso concreto es cierto que fue Yahoo! el responsable por culpa de un doble fallo de seguridad (La injección SQL y el almacenaje en texto plano de las contraseñas), pero es el usuario quien si hubiese sido un poco cauteloso habría usado primero una contraseña totalmente independiente a sus servicios más importantes, y segundo habría comprobado si almacenan sus credenciales en texto plano o cifrado. Igual que a día de hoy se enseña a los más pequeños el uso de las tecnologías, de Internet, de las redes sociales, de los correos electrónicos, de los foros, de… sinceramente no entiendo como Educación no ha impuesto igualmente temas sobre seguridad básica. No hablamos de ser un experto, hablamos que tomando unas medidas básicas que pueden enseñarse a la perfección en una hora como muchísimo, el usuario podría tener prácticamente la total seguridad de que navega de forma segura y de que sus datos también están a buen recaudo. Por supuesto siempre hay alguien que es capaz de lidiar con todas las medidas de seguridad y hace posible lo imposible, pero al menos no dejemos la puerta de nuestra casa abierta de par en par con un letrero que diga: “Por favor, entren a robar.”

Al margen de todo ello, es evidente que a Yahoo! le espera posiblemente una buena sanción económica por parte de las autoridades estatales. Como digo aquí en España y posiblemente en Europa sería una violación directa, y dado el tamaño del a filtración (casi medio millón de afectados), la multa sería muy severa…

 

Un saludo.