Lo comentaba ya hace unos cuantos meses: “La seguridad de los activos digitales es tan débil como débil sea el más débil de los elementos que conforman su ecosistema“.
La frase parece sacada de una cita célebre random de Internet, pero define a la perfección el entorno profundamente dependiente de terceros donde hemos tejido la industria tecnológica. Una dependencia que no tendría por qué ser nociva sino fuera porque en ese afán de democratizar lo máximo posible las barreras de entrada al mundillo del desarrollo (cosa que está bien, ojo), hemos obviado la pata de la seguridad por completo.
Y esto es especialmente doloroso en un escenario que precisamente debería ser ejemplo de buena praxis, como es el caso del ecosistema de aplicaciones móviles. Sencilla y llanamente porque éste ha sido creado en la última década, con las nociones ya aprendidas de todos los errores que hemos cometido en el escritorio.
Riesgos en un entorno móvil
Un móvil es, a efectos prácticos, un ordenador vitaminado. En él podemos hacer todo lo que ya hacíamos en un ordenador personal, pero además, viene de serie con una muy nutrida lista de sensores, y debido a sus limitaciones en cuanto a usabilidad, se han tenido que tomar una serie de licencias que maximizan el riesgo y daño frente a un eventual ataque que comprometa nuestro dispositivo.
Para colmo hablamos de un dispositivo con recursos limitados a la miniaturización del hardware, y por ende, a la disipación de calor/espacio de almacenamiento/duración de la batería, lo que hace que implementar de serie medidas de seguridad avanzadas sea una verdadera lucha bit a bit.
A favor, que los sistemas operativos móviles parten del paradigma del sandboxing. Nada de que todo opere al mismo nivel, sino que para acceder a X recurso debemos pedirlo, y es el usuario (en este caso) quien lo acepta.
Pero como decíamos al principio, basta con comprometer el eslabón más débil de la cadena para comprometer toda la cadena. Por aquí quería poner dos ejemplos que me he encontrado recientemente, y que creo que ejemplifican muy bien esos riesgos de los que hablamos.
Ambigüedad en el copy de la aplicación
¿Cómo puede ser que una aplicación cuya principal funcionalidad es ofrecer una característica que NATIVAMENTE ya ofrece WhatsApp, estuviera durante unas cuantas semanas en el top 10 de aplicaciones de pago (EN) de la App Store? Una aplicación que, por cierto, tiene 1 estrella de media.
Este es el caso de Location for WhatsApp (ES), que ha utilizado una estrategia la mar de sencilla para sacarse unos cuantos miles de euros por la cara: una descripción lo suficientemente ambigua para que los usuarios piensen que ofrece lo que realmente no está ofreciendo.
Funcionando con todos tu contactos que tengas en WhatsApp.
1 – Tocar Botón “Request Location”
2 – Tocar el Botón Verde
3 – Graba automáticamente una foto de la ubicación
como pruebaDe forma fácil y rapida
Disfruta
A la vista de esto, ¿qué piensa que hace la aplicación? No hay que ser muy listo para darse cuenta que parece que está ofreciendo la capacidad de localizar a nuestros contactos, ¿verdad? Y las imágenes con las que la acompaña también ayudan (Seleccionar un contacto > Localizar).
La trampa está en que, por supuesto, no ofrece esto, sino simplemente la opción de enviar tu localización a un amigo. Algo que de base WhatsApp ya permite sin tener que utilizar aplicaciones de terceros.
Pero es un ejemplo más de cómo dándole una vuelta a la descripción de nuestra aplicación podemos lanzar al mercado productos tergiversados que, de sonar la flauta (como ocurrió en este caso) se vuelven durante unos días un negocio redondo.
La tal “Cristina Rodríguez” (ES/viendo cómo escribe, está claro que se trata de un nombre falso que intenta aparentar ser español para atacar al mercado hispanohablante) tiene más de 200 aplicaciones en el market de iOS, la gran mayoría basadas en el mismo principio (ofrecer stickers o contenido chorra, así como minijuegos, con la excusa de cobrar 0,49 euros). Son aplicaciones sencillas de desarrollar (si es que no hace como otras y directamente las copia), y con que una o dos triunfen ya se ha ganado los cuartos.
Puesto que casi todos los sistemas de análisis de los markets de aplicaciones únicamente scrapean las aplicaciones gratuitas, es relativamente fácil que este tipo de apps de pago, que no son estrictamente malware y que se mueven en una tensa línea entre lo que es éticamente reprochable y lo que podemos considerar fraude, pasen desapercibidas hasta que las suficientes denuncias hacen sonar las alarmas en Cupertino o Montain View.
El negocio de las apps con permisos no utilizados
¿Qué pasará con todos esos servicios y aplicaciones que tenemos instalados en nuestros dispositivos y cuentas con permisos de la más variopinta naturaleza el día de mañana?
Es un tema que lleva tiempo preocupándome, y del que ya he hablado en más de una ocasión.
La cuestión es que aunque hemos mejorado mucho estos últimos años respecto a la gestión proactiva de permisos, todavía hay algunos, principalmente enfocados a temas de accesibilidad, que no es necesario aceptarlos, y que unidos a diversas funcionalidades del sistema operativo pueden llegar a ser un vector de ataque más que preocupante.
En el otro lado tenemos aplicaciones que a la hora de desarrollarse hacen uso de SDKs cuyo negocio no tiene porqué seguir estable en el tiempo, y que de hecho, podrían estar comprometiendo nuestros dispositivos hoy en día.
Respecto a esto último, Chema nos hablaba recientemente de cómo habían decidido incluir en su herramienta de vigilancia persistente de aplicaciones mASAPP (ES) la declaración de permisos no utilizados como una señal de riesgo a futuro. Es decir, permisos que por defecto el usuario ya ha aceptado en su día, aunque realmente no se estén utilizando en la aplicación monitorizada.
Un escenario altamente interesante para compradores de aplicaciones de terceros, ya que una vez pasan a controlar esta aplicación, podrían actualizarla haciendo uso de estos permisos con el fin que ellos quisieran y ninguno de todos sus usuarios (potenciales víctimas que ya tienen instalada la aplicación en sus dispositivos) iban a recibir alerta alguna.
Se monta entonces un círculo vicioso, ya que algunos SDKs y complementos de desarrollo por defecto agregan la petición de permisos aunque al final el desarrollador no haga uso de ellos. Y con plataformas como SellTheApps (EN) se democratiza la compraventa de aplicaciones ya en circulación, que cuentan con un gran número de usuarios, sin pedir más garantías (continuar con el negocio, no usos tergiversados..) que el dinero acordado.
Que ya no hablamos que en el futuro al desarrollador se le vaya la pinza y se dedique a hacer el mal. O que en un principio hubiese diseñado la aplicación como una herramienta de fraude. Sino simplemente un buen día decida abandonarla, y ya de paso, sacarse unos cuántos $$$ revendiéndola a un tercero cuyos objetivos sí pueden ser maliciosos.
Son dos ejemplos más de cómo la ambigüedad del entorno móvil favorece el surgimiento de tácticas que podríamos considerar ilegales, dando además un empujón considerable al mercado del cibercrimen.
________
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.
