¿Y cómo hice esto? Todo comenzó con una aplicación que desarrollé. Por razones obvias, no publicaré el nombre. La aplicación es bastante simple, está diseñada para personas a las que les gusta el fitness y ofrece opciones como ingresar datos sobre la velocidad durante una carrera o complejos de entrenamiento de fuerza listos para usar. Como muchos otros productos, requiere que el usuario cree una cuenta primero. Según los analistas, alrededor del 60% de las personas, en lugar de pasar por todo el proceso de registro, se sienten tentadas por el tentador botón "Iniciar sesión con Google".
Probablemente sepa en términos generales lo que sucede en tales casos: cuando el usuario hace clic en un botón, se abre una ventana del navegador para iniciar sesión en una cuenta de Google dentro de la aplicación.
Este usuario tiene habilitada la identificación de dos factores, por lo que después de haber ingresado el correo electrónico y la contraseña, aparece un cuadro de diálogo preguntando si es él. La ubicación y el tipo de dispositivo son los mismos, por lo que hace clic en "Sí".
Eso, de hecho, es todo. Ahora una persona puede usar la aplicación de manera segura, mientras yo, mientras tanto, obtengo acceso completo e ilimitado a su cuenta desde un servidor remoto. Nunca recibirá ningún mensaje sobre esto. Y si resulta ser meticuloso y comienza a estudiar el tráfico de la red, verá que el dispositivo envía solicitudes de red única y exclusivamente a varios subdominios de google.com.
Pero, ¿cómo es esto posible? Volvamos a nuestro botón "Iniciar sesión con Google". Dejemos una cosa clara de inmediato: para aquellos que no están al tanto, después de hacer clic en este botón, la aplicación puede hacer cualquier cosa. Inicie el proceso de autorización en Google, dé una voz de trompeta, muestre un gif con un gato. No todas las opciones de esta lista son igualmente probables, pero puedes soñar con algo.
En mi caso, al hacer clic en el botón, la aplicación abre un cuadro de diálogo utilizando WebView y establece la dirección web: accounts.google.com/EmbeddedSetup . Corresponde a la página de inicio de sesión de la cuenta de Google, solo una especial diseñada para nuevos dispositivos Android. Esta circunstancia jugará su papel más adelante, cuando amablemente se nos proporcione toda la información necesaria en forma de cookie.
Desafortunadamente, esta página se ve y actúa de manera diferente a la página de inicio de sesión estándar (al menos como debería ser por defecto):
Fíjate en la extraña franja azul, las palabras Learn more, etc. en la imagen de la derecha.
Y ahora comienza la diversión. Utilizo las API estándar integradas tanto en iOS como en Android para inyectar un fragmento de código Javascript bien escrito que hará las modificaciones necesarias para que la página no difiera de la estándar en términos de apariencia o comportamiento.
Los astutos ahora pensarán: "Detente, si puedes inyectar código JavaScript, ¿qué te impide robar tu nombre de usuario y contraseña directamente de los campos de texto?" Absolutamente nada; en términos generales, ya existe un código listo para este propósito existe. Pero hoy en día, el acceso al nombre de usuario y la contraseña ya no es suficiente. A menos que tenga mucha suerte, el servidor estará a unos cientos de millas de la ubicación del usuario. De lo contrario, el usuario recibirá una carta y una notificación con un mensaje sobre "actividad sospechosa" y se detendrá el intento de piratería. Y la autenticación de dos factores hace que nuestra vida sea aún más difícil.
Así que hablemos de otra cosa, como la ficha maestra. A primera vista, parece poco amable, pero a la segunda, resulta ser incluso peor de lo que parecía.
Cuando el dispositivo Android inicia sesión por primera vez, envía el token recibido desde la página de inicio de sesión incorporada antes mencionada a un punto final especial. A continuación, se muestra un ejemplo de una solicitud típica:
POST /auth HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 349
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: GoogleLoginService/1.3 (a10 JZO54K);gzip
app: com.google.android.gmsapp=com.google.android.gms&client_sig=38918a453d07199354f8b19af05ec6562ced5788&callerPkg=com.google.android.gms&callerSig=38918a453d07199354f8b19af05ec6562ced5788&service=ac2dm&Token=oauth2_4%2F4AY0e-l5vPImYAf8XsnlrdshQQeNir3rSBx5uJ2oO9Tfl17LpsaBpGf1E2euc18UyOc8MnM&ACCESS_TOKEN=1&add_account=1&get_accountid=1&google_play_services_version=204713000
El token en esta solicitud se toma de las cookies de la página de inicio de sesión de la cuenta, y todo lo demás es información que está disponible públicamente (¡gracias, microG !). La misma página de inicio de sesión de la cuenta maneja las cosas con la autenticación de dos factores: no tenemos que hacer nada en absoluto.
Después de eso, el punto final mencionado envía el mismo token maestro. Pero, ¿cómo podría acceder a él sin solicitudes de red sospechosas? Muy simple: a través de un registro en Google Firebase.
Y la ficha maestra es poderosa. Tiene un período de validez ilimitado, siempre que el usuario no cambie la contraseña o la configuración de autenticación de dos factores. Hasta donde yo sé, no está sujeto a ningún control de seguridad, independientemente de la ubicación, la IP y las acciones. Nunca provoca que el sistema envíe una notificación o carta al usuario.
Y lo más importante: me abre el camino a todos, sin excepción, los servicios que alguna vez han estado disponibles desde un dispositivo móvil, en nombre del propietario de la cuenta correspondiente. Una solicitud POST es suficiente para pretender ser una cuenta oficial de Google y obtener un token de OAuth para acceder a cualquier cosa, incluidas las API privadas (y probablemente no publicadas en ninguna parte). Puedo leer correos electrónicos, navegar por Google Drive, ver copias de seguridad de mi teléfono y fotos en Google Photos, y al mismo tiempo leer el historial web del usuario y chatear con sus amigos en Google Messenger. Incluso creé una versión modificada de microG con la que puedo administrar todas estas cuentas de usuario directamente desde las aplicaciones normales de Google.
Y te recuerdo, todo el proceso se ve así... Los invito a todos a hacer la pregunta: ¿los atraparían?
Exposición
Como muchos de ustedes han adivinado, no todo en este artículo es cierto. No he publicado ninguna aplicación de fitness en Play Store y no he recopilado millones de Master Tokens. Gracias a esta publicación por la inspiración. Pero el método en sí funciona. Yo, y cualquier otro desarrollador, definitivamente podríamos hacer una aplicación con tal sorpresa (tal vez alguien ya lo hizo).
Preguntas más frecuentes
Pero la página es diferente del inicio de sesión normal. ¡Me habría dado cuenta!
Las diferencias no son tan llamativas, por lo que lo más probable es que no se hubieran dado cuenta. La página de inicio de sesión de la cuenta de Google en Android generalmente tiene una interfaz para "seleccionar una cuenta", pero hay excepciones, por ejemplo, muchas aplicaciones web, como las que se crean en Ionic y Cordova. La mayoría de las aplicaciones de iOS también suelen preferir la versión web, que es muy similar a la opción anterior. Además, incluso si le parece que la ausencia de una pantalla con "tal o cual aplicación solicita acceso ...", definitivamente se le alertará, entonces es muy posible que se implemente a costa de algunas horas adicionales. de trabajo.
¿Esto también funciona en iOS?
No lo he probado, pero no hay razón para creer que no funcionará.
¿Y qué hacer con él?
En general, la pregunta es compleja. Ninguna de mis acciones, estrictamente hablando, entra dentro de la definición de exploit, pero el resultado es, sin embargo, muy peligroso. Para empezar, a Google le gustaría ordenar sus notificaciones de "iniciar sesión con un nuevo dispositivo" para que funcionen bien. Personalmente, los obtengo cuando intento iniciar sesión en mi cuenta desde una computadora, pero mientras probaba esta aplicación, el sistema nunca funcionó. Otra buena idea es actualizar las pautas para los botones "Iniciar sesión con Google"; ahora no dice nada sobre los requisitos de implementación. Quizás deberían profundizar en la jungla de la seguridad a través de la oscuridad: un principio, a pesar de todos sus defectos, hasta ahora le sirve a Apple para la seguridad de iMessage.
Tengo que admitir: no estoy seguro de que se pueda encontrar una solución técnica que elimine por completo el problema. Si la aplicación oficial de Google tiene la capacidad de realizar alguna acción, los programas de terceros, con la debida diligencia, podrán repetirla. Sin embargo, la empresa emplea a personas inteligentes, así que espere y verá.
¿Es este problema relevante para todos los sistemas de autorización en aplicaciones de terceros?
Muy posiblemente. No entendí bien en qué casos se enviaron notificaciones y en cuáles no, pero incluso cuando llegan notificaciones, no siempre queda claro qué está sucediendo. La función "Iniciar sesión con Apple", sin embargo, está equipada con pautas muy estrictas, y la administración de la App Store (donde la función, creo, se usa principalmente) monitorea estrictamente el cumplimiento de los requisitos. Por otro lado, tienen sus propios problemas con la autorización, contra los cuales esta se desvanece.
Historia real
Incluso si no eran millones, de alguna manera realmente recogí una pequeña cantidad de tokens maestros de usuarios desprevenidos, y sin querer.
La verdadera historia de mi epifanía comenzó cuando desarrollé la aplicación Carbon Player; ahora ya se ha hundido en el olvido y no ha recibido una distribución generalizada. La aplicación fue concebida como un reemplazo de Google Play Music (¿recuerdas los días en que existía?), Solo que con un diseño mucho más genial. Para acceder a la carpeta de música personalizada, traduje gmusicapiSimon Weber en Java, pero, mientras reescribía el código, al principio no entendí realmente cómo funciona el proceso de autorización allí. Solo me di cuenta de que necesitaba un usuario y contraseña, que solicité a través de un simple cuadro de diálogo, y luego vienen algunas solicitudes y se caen algunos tokens que me son adecuados para extraer música.
Antes de transferir la primera versión de la aplicación a un pequeño grupo de probadores, revisé el código, agregué registros en todas partes y también implementé un interceptor, que se suponía que cargaba automáticamente todos los registros en Firebase. Por supuesto, fui lo suficientemente inteligente como para no registrar contraseñas, pero prometí los tres tokens recibidos por mi implementación de gmusicapi por error. Dos de ellos eran bastante inofensivos, solo daban acceso a diferentes tiendas de música. Pero el tercero resultó ser una ficha maestra.
En general, la aplicación ha recopilado como máximo veinticinco descargas durante toda su existencia, y rápidamente le hice un gesto con la mano para no distraerme de mis estudios. Pero antes de eso, logré lanzar un par de actualizaciones, una de las cuales fue un rediseño de la nueva y asombrosa (bueno, en ese momento) página de inicio de Google Play Music, uno de los pocos elementos del producto original que se veía bien.
El proceso resultó ser mucho más confuso de lo que pensaba, e inesperadamente tuve que hacer mucha ingeniería inversa de Protocol Buffers. Más importante aún, por alguna razón, ahora requería un token completamente diferente, que ya no estaba implementado en gmusicapi. Como resultado, para implementarlo, indagué en el sistema de autorización durante varias horas, tratando de averiguar cómo funciona. Esto me llevó a un terrible momento de epifanía cuando me di cuenta de que estaba registrando la información más sensible que podía. Diré una cosa: el registro se ha detenido. Veinticinco personas que descargaron la aplicación, perdónenme, por favor (¡borré sus tokens de Firebase!).
Hubo otro, no relacionado con la primera vez que trabajé en una startup creando un administrador de contraseñas. Una de las principales ventajas de la aplicación era que almacenaba contraseñas estrictamente en el teléfono, pero al mismo tiempo permitía la autorización desde la computadora gracias a un bookmarklet de JavaScript que “conectaba dispositivos” a través de un código QR. Para que todo saliera bien, cuando un usuario abría un sitio en una computadora, la aplicación accedía al mismo sitio desde el teléfono e inyectaba un fragmento de código JavaScript cuidadosamente escrito que capturaba inicios de sesión, contraseñas y todo lo demás. ¿Suena familiar?
Al final, estas dos ideas se juntaron en mi cabeza. Tenía un prototipo de Carbon Player, pero no tuve tiempo suficiente para hacerlo funcionar. Unos años más tarde, finalmente comencé a crear algo parecido a una versión de demostración sobre esta base. Se tuvo que cambiar mucho en el proceso: el método descrito en este artículo es significativamente diferente de lo que se implementó en el prototipo, ya que Google realizó cambios en el sistema de autorización. Pero el resultado final sigue siendo el mismo y no es menos aterrador de lo que era entonces.
Si lo desea, puede descargar la versión demoy ver el sistema en acción; Doy mi palabra de que no se registra nada en la nube. Tenga en cuenta que la aplicación es muy simple y apenas ha sido probada, por lo que es muy probable que el método no funcione si su cuenta tiene una configuración diferente. Gracias por leer el artículo, espero que hayas disfrutado de un pequeño recordatorio de la importancia de cuestionar todo. Incluso las cosas más inofensivas a veces esconden algo no muy agradable en su interior (aunque en el caso de la tarta de helado ocurre al revés).