Tenía pendiente escribir una pieza sobre la charla que hace algo más de un mes daba Chema Alonso (ES) en la Rooted, y sobre la cual pude conversar con él a posteriori, pero la actualidad del Coronavirus nos ha comido y he preferido esperar a que Chema fuera publicando toda la info sobre la investigación en su blog (ES/lo ha dividido en 6 artículos, así que tienes para rato :D).
Básicamente, y por resumirlo todo un poco, el equipo de Telefónica estuvo en 2015 profundizando en las maneras que había de transformar una app móvil legítima en un malware, identificando cuatro principales vectores:
- Apps que se venden: Es decir, el desarrollador legítimo para obtener beneficio por su trabajo decide venderla a un tercero que a su vez transforma la aplicación en maliciosa.
- Apps que se roban: Por el mismo motivo, es un tercero quien de alguna manera consigue acceder al control de la app, transformándola en maliciosa.
- Una vulnerabilidad: Que puede ser del propio sistema o de la propia app, y permite a un tercero transformar esa app en maliciosa.
- Un desarrollo malicioso latente: Es decir, que el propio desarrollador ya tuvo en mente diseñar la aplicación para que un buen día pasase de ser “buena” a maliciosa.
La historia es por tanto exactamente igual que la que ya conté en su día con las extensiones de navegador (ES/2014), con las apps de terceros que tienen acceso a nuestros perfiles sociales (EN/2017), o con los dominios caducados que servían contenido a terceros (ES/2016).
Podemos confiar en ellas… mientras ninguno de estos cuatro supuestos se cumplan. Ya que de cumplirse alguno potencialmente perdemos la confianza de que esa aplicación haga lo que dice que tiene que hacer.
Este tipo de ataques son más comunes de lo que pensamos, y el problema por supuesto es que bypasean los controles clásicos de seguridad.
A fin de cuentas para un cibercriminal va a salir más rentable comprar o robar una aplicación/extensión que ya tiene miles o millones de instalaciones y transformarla en malware que desarrollar un malware de cero y buscar la manera de que (primero) pase los controles del market de turno y (segundo) alcance esos miles o millones de instalaciones.
De cara al usuario, el problema está servido ya que hasta el momento ni los markets de aplicaciones de Android y iOS, ni el de las extensiones de Chrome/Firefox alertan al usuario de que una app/extensión ha cambiado de dueño (el primer supuesto).
Y fíjate que es algo de lo que ya hablamos por estos lares en 2014. Suma y sigue.
Los desarrolladores tienen todo el derecho del mundo a vender sus proyectos sin avisar a la plataforma, pese a que esto supone, como vemos, un riesgo de seguridad y privacidad considerable.
Pero vamos al tema que me interesaba tocar en esta pieza.
Las usurpaciones de identidad de identidades abandonadas
En su día expliqué por estos lares cómo cuando cambié mi cuenta de Twitter de @Pablo__Fdez a @PYDotCom, al poco una botnet registró ese mismo nick, creando un perfil fake de un supuesto ruso que estuvo durante meses publicando miles de tweets con tintes mayoritariamente políticos.
La cuenta, al menos la última vez que lo miré, había sido baneada por Twitter, pero mientras tanto y siguiendo con la estrategia habitual de estas botnets, llegó a tener varios miles de seguidores (la mayoría seguramente fakes), y hasta cierto punto se aprovechaba de que aunque por supuesto mi comunidad se había migrado automáticamente a la nueva cuenta (cuando cambias el nick en Twitter los que te siguen pasan a seguir a tu nuevo nick), seguramente había por Internet bastantes enlaces a tweets o a mi perfil que por razones obvias apuntaban al nick anterior.
Es decir, que la estrategia de crecimiento de esta botnet pasa por scrapear Internet en busca de URLs de perfiles de Twitter indexados en los buscadores y abandonados, bien sea porque el usuario, como fue mi caso, cambió de nick, o porque la cuenta ha sido borrada por inactividad o petición del usuario.
Chema recogía en su charla el testigo para explicar cómo esto mismo potencialmente se está explotando con las cuentas de desarrolladores de apps.
Después de la investigación que hizo su equipo, llegaron a la conclusión de que un porcentaje muy significativo de emails de administración de cuentas de desarrollo (es algo público, por cierto) están creados mediante correos de @hotmail.com, @gmail.com o @outlook.com.
Servicios, como bien sabes, gratuitos, que a los X meses de inactividad ponen la cuenta como inactiva, y poco después, si la inactividad sigue presente, eliminan la cuenta.
Para un agente malicioso valdría con hacer un barrido de cuentas asociadas a aplicaciones con relativo éxito (decenas de miles de instalaciones, por ejemplo), comprobar cuáles de ellas están disponibles para volver a registrarlas, y de ser así, crearlas ya bajo su control.
En la práctica estamos ante un ataque de hijacking en el que la víctima no tiene capacidad alguna de protegerse, ya que ya ha perdido el acceso a ese correo.
Y claro, una vez tenemos el control de esa cuenta, podemos con ella pedir recuperar contraseña en la cuenta de developer de Google Play o la App Store, y en efecto hacernos con el control de la o las aplicaciones que estén asociadas.
Que dices tú:
Hombre, ¿quién en su sano juicio deja que su correo asociado a algo tan crítico como una cuenta de desarrollador se elimine por inactividad?
Pues más de los que piensas. El equipo de Chema detectó que de 217 cuentas de correo Outlook asociadas a apps con un total de cerca de 5 millones de instalaciones, 8 de ellas estaban caducadas.
8 cuentas que cualquiera (tú o yo) podemos registrar de nuevo gratuitamente, recuperar la contraseña de la cuenta de desarrollo, y de pronto tener control absoluto de una o varias apps con decenas de miles de usuarios.
El problema no solo afecta a desarrolladores
La razón principal de que esto ocurra es que muchos usuarios crean correos por necesidad y luego extravían u olvidan la contraseña, incluso a veces el propio correo.
Yo esto por ejemplo lo he visto mucho con gente de mi entorno que, cuando tuvo que cambiar de un teléfono a un smartphone se vio forzado a crearse una cuenta de correo, y cada vez que cambian el móvil crean un nuevo correo ya que no se acuerdan de cómo era el anterior.
Un ejemplo más de la importancia de tener controlado los vectores principales de identidad digital: El correo electrónico y nuestro número de teléfono.
En Internet somos lo que somos gracias a uno de estos dos elementos. Y si los perdemos o nos los roban, como puedes ver, estamos jodidos ya no solo nosotros sino también el resto de usuarios que directa o indirectamente estén relacionados con nuestra identidad, como es el caso de todos esos millones de usuarios que han descargado alguna de estas apps.
Ni me quiero imaginar la de cuentas de Google Adsense, la de agendas de contacto, o el simplemente hecho de asociar tarjetas de crédito a cuentas de Google Play y App Store que están por ahí pululando asociadas a su vez a correos eliminados, que pueden ser reclamados por cualquiera.
El caso del hijacking de cuentas de developers es alarmante porque en efecto dichas cuentas son públicamente accesibles en los perfiles de desarrollador del market, pero es que a poco que esto mismo que han hecho los chicos de Eleven Paths se haga con correos asociados, por ejemplo, a filtrados masivos de información, y se tire con ellos del hilo, pueden salir auténticas maldades.
¿Qué podemos hacer como usuarios?
Como decía, y desde el punto de vista de usuario que lleva instaladas varias decenas de apps en su móvil, hay poco que podamos hacer, ya que a ojos del market es el propio desarrollador quien ha actualizado su app.
Un día podemos tener una aplicación legítima, y al día siguiente esa app vía una actualización volverse maliciosa, sin que por ello vayamos a recibir ninguna notificación.
La única opción es que por ejemplo en entornos regulados (como aplicaciones en dispositivos corporativos gestionados mediante un MDM) sea la propia herramienta la que tirando del scraping del market para las apps que tiene instaladas alerte de potenciales cambios.
Sin ir más lejos Chema habló de la mASAPP (ES) de Telefónica que alerta, entre otras cosas, de si una app está a la venta en el mercado, aunque por supuesto esto no va a ser 100% infalible (tú como desarrollador puedes llegar a un acuerdo con un tercero sin pasar por un market de reventa de apps).
Pero eso sí, debemos ser conscientes y tener controlado en todo momento el email o emails que hemos creado y que están asociados a diferentes servicios.
Ya he explicado en más de una ocasión que en mi caso utilizo tres emails:
- El corporativo: Para comunicación corporativa y también asociado a unos pocos perfiles de tinte profesional.
- El personal: Que apenas utilizo a nivel de comunicación, y donde tengo la mayoría de perfiles “importantes”.
- El secundario: Que no utilizo más que para registrarme en servicios secundarios.
Ninguno de ellos me va a caducar a no ser que pase algo muy raro, ya que los miro prácticamente a diario.
Y justamente lo mismo con mis números de teléfono:
- El corporativo: Que es el que expongo públicamente, y que no está asociado más que a la cuenta corporativa de WhtasApp.
- El personal: Que es el que utilizo en mi día a día solo para tintes personales, y que como es normal está asociado a muchos otros servicios.
Más allá de esto lo único que nos queda es exigir que los markets, y en líneas generales toda la industria del software, implemente mayores controles con esto de las cuentas caducadas y/o abandonadas.
Sinceramente no me explico cómo la cuenta de desarrollador de Google Play no queda inactiva en el momento en el que la cuenta asociada (al menos si es de tipo @gmail.com, es decir, de la propia Google) se queda inactiva.
Y para cuentas de correo creadas en servicios de terceros o con dominio propio, bastaba con que trimestralmente, por ejemplo, enviase una notificación pidiendo que confirmáramos que seguíamos teniendo acceso. Al segundo email del que no diéramos señales de vida, la cuenta pasa a inactiva (reteniendo posibles pagos, que ya verás como el desarrollador busca la manera de acceder a ella) y para recuperarla deberemos demostrar que somos nosotros (un 2FA del tipo que sea).
Dejo por aquí algunas ideas por si algún ingeniero de Google o Apple se pasa por esta pieza, así como mi perfil de MyPublicInbox (ES), un proyecto de Chema y compañía por el que podéis escribirme :).
________
Puedes 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 te sirve para estar actualizado en tu día a día, piensa si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
