Como explicaba recientemente al hilo del tutorial sobre qué hacer cuando extravías o te roban un portátil, uno de los puntos que más miedo dan cuando te ocurre un percance de este tipo es que en efecto el ladrón pudiera acceder al llavero de contraseñas que tenemos en nuestro navegador.
Para ello, bastaría con que fuera capaz de acceder a mi cuenta de Windows, lo que significa adivinar una contraseña que si bien es compleja, acabaría por caer frente a un ataque de fuerza bruta.
Únicamente con esa contraseña se puede acceder a la sesión personal, y además, a las credenciales de acceso de los cerca de 600 servicios que de una u otra manera Chrome ha ido almacenando en mi cuenta desde que lo utilizo como navegador por defecto. Cosa que se solucionaría implementando por ejemplo el login de Google (que para colmo cuenta con 2FA) para acceder a esos datos tan críticos.
Contraseñas que utiliza para autocompletar las solicitudes de sesión que reciba, y que se unen así al resto de autocompletados (nombre y apellidos, DNI, teléfono, emails, direcciones postales e incluso tarjetas de crédito y débito) que dicha cuenta puede almacenar.
Todo ello sin tener que conectarse a la red, simplemente bypaseando el login de Windows.
Sobra decir que lo primero que hice (y lo primero que recomiendo hacer en estos casos) fue cambiar las contraseñas de todas aquellas cuentas y servicios críticos para mi identidad digital, empezando por la cuenta de Google, y ya de paso, borrar todo registro de autocompletado que tuviera asociado a dicha cuenta.
De esta manera, si en algún momento el atacante consiguiera bypasear el login de Windows y se conectara, Chrome actualizaría al último estado conocido para esa contraseña y borraría en local todo el contenido. Pero recalco, es necesario que el ladrón se conecte a Internet, cosa que en smartphones es relativamente sencillo (la mayoría tiene asociada una SIM con conectividad), pero que en portátiles debe hacerse de forma proactiva.
Lo que quiere decir que estoy sencilla y llanamente vendido. Que no existe hoy en día manera de forzar el cierre o borrado de una sesión de Chrome remota, a sabiendas que su acceso de forma local se hace mediante la propia contraseña de inicio de sesión en el sistema operativo.
Es, a todas luces, una debilidad (tampoco podemos considerarlo vulnerabilidad) de este tipo de sistemas.
Investigando sobre el asunto llegaba estos días al artículo de Viljami kuosmanen (EN), un experto en seguridad finlandés que había encontrado una «nueva» manera creativa de robar datos de usuario de forma remota utilizando precisamente los autocompletados.
Y algo así nos afecta a TODOS.
Ingeniería social aplicada al robo de datos mediante el autocompletado en navegadores
La estrategia seguida por este investigador es tan sencilla como efectiva.
Para realizar el ataque bastaría con que el usuario tuviera que meter su nombre e email en un formulario al que de una u otra manera tenga acceso el atacante.
Ya sabe, o bien mediante campañas de phishing que emulan ser webs legítimas, o bien mediante un ataque inicial que comprometa la seguridad de una web legítima.
Una vez la víctima teclea la primera letra de su nombre, el autocompletado del navegador le sugerirá seguir completando el resto (su nombre y su email). Y aquí viene el truco: Basta con que el formulario cuente con campos ocultos abiertos para obtener el resto de datos que estén asociados a ese autocompletado. Datos como el NIF, la dirección postal, el teléfono, los apellidos. Incluso los números de una tarjeta de crédito o los credenciales de acceso utilizados para acceder a esa supuesta página.
En la imagen que acompaña a esta pieza se puede ver cómo, a la petición de un formulario compuesto por el nombre y el email, realmente el atacante lo que recibe es el nombre junto a todos los demás datos asociados a dicho autocompletado.
De nuevo estamos ante una debilidad del sistema de autocompletado, no ante una vulnerabilidad. El atacante únicamente se aprovecha de que la funcionalidad opera bajo cualquier circunstancia (aunque esos campos a rellenar no se muestren por pantalla), no a costa de explotar la seguridad del sistema, por lo que me temo que tardaremos en ver algún movimiento por parte de Chrome, Firefox, Safari y compañía, si es que en algún momento se dignan a solucionarlo.
Y sí, quien conozca del tema sabrá que esta estrategia es al misma que utilizamos la mayoría de administradores para defendernos del spam en la red mediante honeypots.
Sin ir más lejos, todos los formularios de este blog (página de contactos, sección de comentarios, suscripción a la Comunidad…) cuentan con campos ocultos y abiertos que un usuario legítimo no va a poder completar (tendría que meterse en la vista de desarrollador y modificar a mano la petición), pero que en cambio son cubiertos por defecto por la mayoría de bots de spam. Esto ocurre por el simple hecho de que para un bot es virtualmente imposible saber qué campos de un formulario debe completar (son obligatorios) y cuáles podría no hacer. Existe una estandarización de formularios (ES) que por ejemplo nos sirve para saber que un campo de contraseña debe mostrar asteriscos en vez de los caracteres que se están tecleando para evitar que terceros puedan verla, o que el email tiene que tener un formato de [email protected], pero después cada desarrollador puede o no seguirlo, y puede que dicho formulario requiera obligatoriamente de elementos que a priori no están contemplados en la estandarización. De esta manera, los administradores evitamos tener que meter campos de captcha que «penalizan» a aquellos que no queremos penalizar (los usuarios) en la lucha contra el dichoso spam.
Frente al spam se utiliza para evitar el acceso de una serie de peticiones que sabemos que son fail (si lo has completado, es que eres un bot). Con el uso de los autorespondedores, el objetivo es atacar directamente al usuario (aunque no lo completes, obtengo tus datos). Pero la estrategia es la misma en ambos casos.
¿Qué podemos hacer para evitar este tipo de ataques?
Lamentablemente, la única que de verdad funcionaría es desactivar el autocompletado en nuestro navegador.
- En Chrome, la opción estaría en el menú > Configuración > Mostrar configuración avanzada > Contraseñas y formularios, desactivando el «Habilitar la función de Autocompletado…». Desde ahí, por cierto, también podemos ver qué autocompletados tenemos definidos, pudiendo eliminar aquellos que no queramos que se queden registrados.
- En Firefox, la opción se encuentra en el menú > Opciones > Privacidad > Usar una configuración personalizada para el historial. Desde ahí podemos desactivar la función «Recordar el historial de formularios y búsquedas» y/o administrarla.
- En Safari, la opción está en Preferencias > Autorelleno.
Como punto positivo, para la realización del ataque es necesario que de antemano nos dirijan hacia un formulario que está bajo el control del atacante. Y la única manera de hacer esto es mediante una campaña de phishing (un enlace que nos envían por algún canal haciéndose pasar por una web legítima) o hackeando una web legítima.
En el segundo caso poco podemos hacer como usuarios. Depende de la seguridad del servidor y/o servicios que se utilicen en la web, y por ello no es algo tan sencillo de realizar.
Para defendernos del primero, basta con ser conscientes del riesgo que entraña acceder a enlaces acortados o enviados desde emails y cuentas de dudosa identidad. Las prisas y demás estrategias que los cibercriminales utilizan para engañarnos no son buenas consejeras, por lo que ante un formulario que no parece ser el de la web correcta, lo mejor es preguntar por los canales oficiales y aplicar el sentido común:
«Si algo huele mal, lo más probable es que esté podrido»
Dicho sea de paso que en este ataque solo se podrán obtener datos identificativos de la persona (nombre, apellidos, NIF, dirección postal, teléfono, email…). Para obtener tarjeta bancaria y/o credenciales de acceso, además de que la víctima las tenga asociadas al autocompletado, tendría que usurpar la web legítima (quizás mediante técnicas avanzadas como el envenenamiento de DNS) y encontrar la manera de autoaceptar la alerta que la mayoría de navegadores ya implementan antes de colocar una tarjeta en un campo.
El problema sigue siendo gordo (a fin de cuentas son datos identificativos de la persona), pero en la mayoría de ataques no se llegará al nivel de ver expuestas nuestras cuentas ni nuestro monedero. Al menos no directamente, ya que abre la veda a futuras extorsiones.
He diseñado este curso online en 8 módulos en el que cubriremos todos los fundamentos de la presencia digital sana, ayudándote paso por paso a parametrizar la seguridad y privacidad de tus cuentas digitales y de tus dispositivos.
________
Puede ver más artículos de esta serie en #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.
Y si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
