Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Suplantación de aplicaciones en Android <=2.3.3
A raíz de algunos estudios previos en los que se monitorizaban los datos transmitidos por dispositivos Android, un grupo de investigadores de la Universidad de Ulm ha estudiado la viabilidad de realizar ataques de suplantación en determinados servicios de Google utilizados por dispositivos Android.
El estudio se ha centrado en el protocolo ClientLogin de Google, orientado a facilitar el acceso de las aplicaciones a los servicios de google de una cuenta. Este acceso se basa en una identificación inicial con las credenciales de la cuenta de google, y la generación de un token de acceso temporal a dichos servicios.
Figura 1: Arquitectura ClientLogin
Algunas de las ventajas de este sistema de tokens son el rendimiento y la seguridad, como indica la página de google:
Figura 2: Ventajas descritas por Google
Es cierto que el sistema es en general más seguro, pero dicha seguridad puede verse afectada por dos factores:
• El tiempo de validez de dicho token: cuanto mayor sea menos veces me tendré que volver a autenticar con mis credenciales, pero menos seguro será puesto que este token no va asociado a ninguna sesión o dispositivo en concreto (si un atacante se hace con él, podrá suplantarnos). En nuestro caso, la validez del token puede ser de hasta dos semanas:
Figura 3: Explicación de token en documentación
• La forma de transmitir nuestro token: si se envía cifrado, se reducirán las posibilidades de que sea interceptado por un atacante. En nuestro caso, si bien la autenticación de las credenciales se hace de forma cifrada, Android envía los tokens en claro en cada petición. Esto, al igual que ocurrió con las cookies de Facebook, se convierte en un grave problema en redes inseguras; si consideramos posibles escenarios como Hot-Spots que están a la orden del día, y tenemos en cuenta que muchos de los dispositivos Android tienen configurada una sincronización automática periódica, facilita enormemente el ataque.
Ejemplos de aplicaciones nativas que funcionan de esta forma son el calendario, los contactos, y los álbumes de Picasa, de forma que un atacante podría ganar acceso de lectura y escritura a estos tres componentes de nuestra cuenta.
Figura 4: Captura de aplicaciones Android accediendo a aplicaciones
Figura 5: Captura de tokens
Google recomienda en su documentación revocar estos tokens cuando la aplicación haya terminado, pero en la práctica no parece ser así ya que las pruebas realizadas en el estudio indican una validez del token de 14 días para el calendario. Según se comenta también en dicho artículo, Google ha corregido esto en Android 2.3.4/3.0 realizando el envío del token en https (aunque sólo para los contactos y el calendario, en Picasa se sigue enviando en claro). No obstante, los dispositivos Android del mercado con versiones inferiores a 2.3.4/3.0 representan el 99,7% del total.
Android, además, intenta conectarse por defecto a cualquier red inalámbrica que recuerde (en base a su SSID, no su MAC) y si la sincronización automática está activada, intentará la sincronización de servicios. Un atacante podría simplemente usar nombres de puntos de acceso comunes para intentar capturar tokens a mayor escala.
Por último, las implicaciones de esta amenaza no pasan sólo por la pérdida de privacidad de nuestros datos, sino porque el atacante pueda realizar modificaciones en los mismos, como cambiar alguna dirección de correo con la esperanza de capturar información sensible.
Autor: Kabracity
El estudio se ha centrado en el protocolo ClientLogin de Google, orientado a facilitar el acceso de las aplicaciones a los servicios de google de una cuenta. Este acceso se basa en una identificación inicial con las credenciales de la cuenta de google, y la generación de un token de acceso temporal a dichos servicios.
Figura 1: Arquitectura ClientLogin
Algunas de las ventajas de este sistema de tokens son el rendimiento y la seguridad, como indica la página de google:
Figura 2: Ventajas descritas por Google
Es cierto que el sistema es en general más seguro, pero dicha seguridad puede verse afectada por dos factores:
• El tiempo de validez de dicho token: cuanto mayor sea menos veces me tendré que volver a autenticar con mis credenciales, pero menos seguro será puesto que este token no va asociado a ninguna sesión o dispositivo en concreto (si un atacante se hace con él, podrá suplantarnos). En nuestro caso, la validez del token puede ser de hasta dos semanas:
Figura 3: Explicación de token en documentación
• La forma de transmitir nuestro token: si se envía cifrado, se reducirán las posibilidades de que sea interceptado por un atacante. En nuestro caso, si bien la autenticación de las credenciales se hace de forma cifrada, Android envía los tokens en claro en cada petición. Esto, al igual que ocurrió con las cookies de Facebook, se convierte en un grave problema en redes inseguras; si consideramos posibles escenarios como Hot-Spots que están a la orden del día, y tenemos en cuenta que muchos de los dispositivos Android tienen configurada una sincronización automática periódica, facilita enormemente el ataque.
Ejemplos de aplicaciones nativas que funcionan de esta forma son el calendario, los contactos, y los álbumes de Picasa, de forma que un atacante podría ganar acceso de lectura y escritura a estos tres componentes de nuestra cuenta.
Figura 4: Captura de aplicaciones Android accediendo a aplicaciones
Figura 5: Captura de tokens
Google recomienda en su documentación revocar estos tokens cuando la aplicación haya terminado, pero en la práctica no parece ser así ya que las pruebas realizadas en el estudio indican una validez del token de 14 días para el calendario. Según se comenta también en dicho artículo, Google ha corregido esto en Android 2.3.4/3.0 realizando el envío del token en https (aunque sólo para los contactos y el calendario, en Picasa se sigue enviando en claro). No obstante, los dispositivos Android del mercado con versiones inferiores a 2.3.4/3.0 representan el 99,7% del total.
Android, además, intenta conectarse por defecto a cualquier red inalámbrica que recuerde (en base a su SSID, no su MAC) y si la sincronización automática está activada, intentará la sincronización de servicios. Un atacante podría simplemente usar nombres de puntos de acceso comunes para intentar capturar tokens a mayor escala.
Por último, las implicaciones de esta amenaza no pasan sólo por la pérdida de privacidad de nuestros datos, sino porque el atacante pueda realizar modificaciones en los mismos, como cambiar alguna dirección de correo con la esperanza de capturar información sensible.
Autor: Kabracity
2 comentarios:
El protocolo ClientLogin está en la lista de los que google ha declarado como obsoletos. Ahora usan oauth1 y 2.
Sí, de hecho una de las opciones que se proponía era migrar a oauth.
El problema es que hoy por hoy la situación afecte a un % tan elevado de terminales ya no en aplicaciones que hagan uso de él, sino en las propias aplicaciones de stock.
Publicar un comentario