Hace poco más de 24 horas se hacía público un sistema a través del cual un atacante podía saltar el sistema de doble factor de autenticación de Google para robar una cuenta de otra persona. El fallo ya corregido por Google (previamente a la publicación) abre un interesante debate sobre la seguridad con la que se tratan los ASP.
La empresa Duo Security, descubrió hace casi un año una vulnerabilidad en el sistema de doble autenticación que permitía a través de un ASP (application-specific password) capturado y un nombre de cuenta acceder a la cuenta en si de Google, y poder cambiar todos los datos de la misma para hacerse con el control de la misma.
Una vez logueado en los servicios de Google, se suelen generar contraseñas para cada aplicación que no use el doble factor de autenticación, lo que viene siendo un ASP o application-specific password. Estos ASP no tienen acceso a la cuenta de Google a través del doble factor de autenticación por lo que en principio no suponen un grave riesgo en caso de ser interceptados. En este escenario tenemos que los usuarios iban creando ASP para aplicaciones como thunderbird, apple mail, ical... lo que descubrió Duo Security es que estos ASP se podían utilizar para acceder a casi todos los servicios web de Google, accediendo a la configuración de los mismos y evitando la doble autenticación.
Por ejemplo, el servicio de auto-login para Android o Chrome OS, permitía que tras conectar el dispositivo a la cuenta de Google, el navegador del dispositivo pudiera acceder a estos servicios web sin tener que loguearse, dando acceso a cambiar la información para recuperar una cuenta, con lo que básicamente se podía cambiar esta información, cambiar el password y cuenta totalmente secuestrada.
Aunque estos ASP en muchos casos no se almacenan ni son fáciles de interceptar, el hecho de que puedan ser almacenados en aplicaciones de terceros (como los clientes de correo) siempre dejan la puerta abierta a que o bien se puedan desde el terminal o se pueda interceptar una comunicación no debidamente encriptada. En este caso con el nombre de usuario, este ASP y una visita a https://android.clients.google.com/auth los atacantes ya tenían todo los necesario para acceder a la configuración más sensible de la cuenta con la posiblidad de robarla.
Lo que ha hecho Google en este caso es añadir un estado de sesión para identificar de que manera el usuario está identificado y en el caso que sea a través de un tercero o del propio dispositivo impedir el acceso a determinadas zonas sin pasar previamente por un login clásico en web.
