Análisis de la APP Alerta Guate
Hallazgos de tres expertos que la evaluaron y analizaron desde sus especialidades
Desde el 24 de marzo de 2020 que el presidente Alejandro Giammattei anunció que estaba disponible una APP para proveer información oficial sobre las acciones relacionadas al COVID-19 circularon, de inmediato, una serie de críticas.
Como lo explicó Giammattei en una publicación del 25 de marzo la APP tiene tres objetivos:
- Recibir notificaciones de alerta
- Realizar llamadas (sin costo) al 1517
- Enviar información
Evaluación rápida de programador guatemalteco
El mismo 24 de marzo el programador Víctor Orozco hizo una publicación con una evaluación rápida sobre la APP. Esto luego de ver las críticas que varios usuarios de redes sociales hicieron.
Dentro de sus conclusiones destaco:
- El usuario debe estar consciente de los permisos que acepta luego de descargar cualquier aplicación.
- Este tipo de sistemas de alerta son necesarios.
- No puede recomendar que se descarte el uso de la APP si se usa con permisos mínimos y estar conscientes que los datos se compartirán con una API de terceros.
- No encontró que fuera una APP israelí (que fue alguna de la información que circuló luego de las declaraciones de Giammattei)
Evaluación de especialista en privacidad de datos
Desde el 21 de marzo Christopher Schmidtun , especialista en Privacidad de Datos, estuvo publicando resultados de evaluaciones breves sobre el tema a varias aplicaciones gubernamentales que han surgido sobre el COVID19 alrededor del mundo. Aquí pueden ver su hilo con información de 16 aplicaciones: → HILO
Así que el 24 de marzo le pedí a él y otros especialistas que menciono más adelante, que revisaran la APP que Giammattei acababa de anunciar. El 25 de marzo Schmidt publicó los siguientes resultados:
En resumen la aplicación Alerta Guate puede:
- Hacer llamadas.
- Grabar audio.
- Acceder a geolocalización de forma permanente.
- Comparte datos con Facebook para desplegarlos en Facebook Analytics.
- El acceso se realiza con Google (Firebase).
Están activas la funciones Broadcast receivers exported, Cleartext traffic, storage of sensitive information (CWE-312), temp files (CWE-276), logging (CWE-532).
La implementación de WebView es insegura (CWE-749).
Y usa Java Hash (CWE-327).
Evaluación de Ingeniero en Seguridad Móvil
El 26 de marzo Iván Rodríguez, Ingeniero en Seguridad Móvil e Ingeniería Inversa, publicó un análisis más profundo sobre la aplicación y sus características que nos revela algunos detalles más específicos.
Con respecto a los permisos que pide, dice que son bastante comunes. Esto descarta muchas de las críticas que salieron de inmediato.
Aspectos que vale la pena señalar del análisis de Rodríguez.
Es una APP white label que es similar a otras que la misma empresa desarrolladora distribuye en otros países. En otras palabras es una aplicación genérica.
En el registro el usuario puede o no incluír un correo o número de celular. De no hacerlo el sistema genera un usuario. Una vez activo el usuario se conecta con la API de la empresa comercial.
En cuanto a la contraseña hay una segunda contraseña parte de la red de conexión que para sorpresa de Rodríguez es una Hardcoded Password (CWE-259).
Significa que hay credenciales embebidas o contraseñas de texto dentro del código. Y lo más notorio, que todos tienen la misma contraseña, que ademas termina siendo parte del código. El problema de seguridad que está enumerado en la página de CWE:
La aplicación tiene la capacidad de activar el Bluetooth para la función de Indoor Positioning System (IPS), similar al GPS pero para interiores.
También tiene la capacidad de activar el acelerómetro del dispositivo. Este se usa normalmente para registrar movimiento del usuario.
Las llamadas del sistema incluyen una que puede ser preocupante.
Cada 15 segundos hace una llamada (se conecta a la API de la empresa comercial) para entregar los datos de de geolocalización al servidor. Esto aún en segundo plano.
La causa probable la explica ampliamente en el análisis y todo apunta a entregar datos a Factual, una empresa que comercializa ubicación más precisa de potenciales consumidores.
Las conclusiones de este análisis de ingeniería inversa:
- La aplicación funciona aún al desactivar la función de localización.
- Si se van a usar aplicaciones genéricas es importante hacer implementaciones de seguridad.
- Es comprensible que una aplicación de esta naturaleza pueda requerir la ubicación del usuario, pero vale la pena reflexionar si quieren entregar esos datos a terceros.
- No queda claro cuál es la relación entre la aplicación y la empresa que comercializa datos.
--> Queda pendiente de agregar un cuarto análisis que está realizando un experto investigador de seguridad. Cuando me entregue la información la agregaré en esta misma publicación.
Recomendaciones finales
En general y después de haber leído las evaluaciones y análisis, considero que esta APP puede significar un avance en la comunicación gubernamental y se comprende que ante la emergencia habrá cosas que llegan de forma rápida.
Dicho lo anterior también considero relevante que se considere lo siguiente:
- Corregir de inmediato la seguridad en el proceso de autenticación (lo señalado con respecto a las contraseñas compartidas).
- Modificar el proceso y hacer opcional desde el registro sobre cuales permisos desea otorgar el usuario. O al menos incluir información sobre cómo puede hacerlo cada persona.
- Considerar y analizar si estamos en condiciones para que datos de geolocalización y otros pasen por entidades comerciales cuando son enviados al servidor.
También creo que lo antes posible debe generarse una discusión y propuestas de Protección de Datos Digitales que incluyan casos como el de la APP.
Aprovecho para recordar este tema: El sistema de alertas móviles SMS en caso de desastre (y que no es sustituible con una APP). Aquí hay un texto de hace algunos años:
