Estos días se ha hecho bastante famosete un artículo publicado en el blog del desarrollador Felix Krause (EN), en el que explicaba lo sencillo que había sido, utilizando el SDK de iOS, realizar una campaña de ingeniería social en una aplicación demo que robaría la cuenta de iTunes.
El ataque no es nada novedoso, pero me ha parecido un ejemplo de guión de cómo un ecosistema profundamente dependiente del control absoluto por parte de una compañía también entraña problemas de seguridad que no afectan con tanta intensidad a otros ecosistemas más abiertos (como ocurre con Android).
El ataque
Básicamente, Krause lo que hizo fue una aplicación en la que en algún momento, y ante alguna situación, pediría al usuario la contraseña de su cuenta de iTunes.
Para ello hace uso del método UIAlertController (EN), dentro del SDK de iOS, y que permite mostrar alertas como las que el propio sistema operativo muestra.
La idea por tanto pasa por cambiar el mensaje que aparece en el popup por uno que sea exactamente igual que el que por defecto pide iOS cuando necesita identificar al usuario en iTunes. Y para ello, necesita conocer el email del usuario… que gracias a los permisos de la aplicación, puede obtener.
El resultado, como se puede ver en la imagen que acompaña esta pieza, es exactamente igual al oficial. La única diferencia es que en el oficial lo que escribamos en ese recuadro se verifica con el propio sistema operativo, mientras que en el de la aplicación fraudulenta, se envía directamente a donde quiera el desarrollador. Puesto que tenemos usuario y contraseña, ya bastaría probar si la víctima tiene algún 2FA activo en su cuenta, y si no es así, tenemos una cuenta más de iTunes (ojo, asociada habitualmente a una tarjeta de crédito) para hacer maldades.
Como además muchos usuarios repiten contraseña en distintos servicios, el ataque podría saldarse con una serie de cuentas más comprometidas.
Pero, ¿por qué ocurre esto?
Hasta aquí todo normal, ¿verdad? Una campaña de phishing típica con algunas pinceladas de ingeniería social, que en vez de atacar por email, lo hace mediante aplicaciones que ya tengamos instaladas y gracias a una serie de métodos disponibles en el propio SDK que permiten hacer maldades.
El problema, no obstante, es que esto funciona por la unión de dos detonantes principales:
- La costumbre: El usuario de iOS está acostumbrado a que ante algunas acciones tenga que volver a escribir la contraseña de su cuenta de iTunes (por ejemplo, cuando descarga una nueva aplicación). Que esto se lo pidan dentro de una aplicación debería ser motivo más que de sobra para que saltaran todas las alarmas, pero como normalmente no estamos a lo que estamos, lo más probable es que a poco que el atacante tenga algo de cabeza y camufle la petición en una acción que pueda llevar a engaño (imagínese un reproductor de música que, una vez descargado, nos pide acceso a iTunes, presumiblemente para poder reproducir nuestra biblioteca), resultaría relativamente sencillo que las potenciales víctimas cayeran en la trampa.
- La estandarización del ecosistema: Este es el punto que más me interesa, y que por ende, me ha motivado a escribir sobre todo esto.
Un ataque como este en Android tiene bastantes menos posibilidades de funcionar por la sencilla razón de que Android es un sistema modular y adaptativo. Un SO que requiere ser lo más flexible posible para que dependiendo de cada fabricante, la experiencia sea la más adecuada sin perder por ello el sello que cada fabricante desea ofrecer a sus usuarios.
El corolario de este entorno es que no existe una estandarización en la manera en la que el sistema pide acceso a X permiso o cuenta al usuario, y por ende, los atacantes tendrían algo más de problemas para tener que adaptar sus ganchos a las diferentes tipologías de diseño que hay en cada una de las ROMs en el mercado.
En iOS esto no pasa, y puesto que el ecosistema de Apple solo tiene una misma línea de diseño, lo que para unas cosas es positivo (dependemos únicamente de Apple, ergo la compañía puede parchear de una manera mucho más inmediata y útil cualquier potencial vector de ataque), para otra se vuelve peligroso (al depender únicamente de los designios de una sola compañía, resulta mucho más sencillo aprovecharse de estructuras y tipologías de uso estandarizadas).
¿Qué se podría hacer para solventarlo?
Se me ocurre que lo más adecuado sería que Apple estableciera un patrón de diseño específico para todas aquellas alertas que piden contraseña, y que éste no estuviera contemplado a nivel de SDK. Creo que no tiene sentido que un tercero pueda realizar alertas idénticas a algo tan crítico como pedir acceso a una cuenta. Si la aplicación así lo precisa, bien podría pedirlo en base a los permisos habituales, y si aun así hay casuísticas donde interesa ofrecer dicha funcionalidad, en vez de utilizar un método abierto a outputs controlados por el desarrollador seguro que el framework de iOS ya ofrece métodos supeditados al control del sistema, donde el desarrollador solo recibe el acceso (y no el logging propiamente dicho).
Que vale que aun así un desarrollador podría emular el diseño de dicha alerta y realizar el ataque igualmente, pero al menos tendría que trabajar un poco más :).
De cara al usuario, sinceramente, hay poco que podamos hacer. Lo fácil sería decir que tenemos que estar siempre en alerta, intentando ser conscientes de si tiene sentido que en X momento nos estén pidiendo X información.
Pero vaya, que sé que es pedir peras al olmo. El trabajo del usuario debería ser disfrutar de la tecnología, no andar preocupado por los malos usos que pudieran desprenderse de la misma.
Eso sí, un segundo factor de autenticación sigue siendo el método de protección más efectivo que existe. No me cansaré de repetirlo. Añada un segundo factor de autenticación a sus cuentas, que la mayoría de estos ataques, gracias a ello, no tendrían consecuencias.
________
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.
