Esta entrada de blog fue escrita en el marco de la “Digital Forensics Fellowship” por uno de los becarios 2022-2023.
Acerca de mí: Mi nombre es Paul Aguilar, mexicano de nacimiento, Ingeniero en Computación de profesión y apasionado de la tecnología y la cultura libre por decisión. Actualmente soy Coordinador del área de Seguridad Digital en SocialTIC, una ONG mexicana enfocada en el uso estratégico y seguro de la tecnología. En SocialTIC trabajo con periodistas, activistas y personas defensoras de derechos en México y América Latina, habilitando procesos de formación y acompañamiento en seguridad digital, así como apoyando en la respuesta rápida a incidentes y en el proceso de desarrollo de políticas y protocolos. También mantengo (junto con mi equipo) el sitio de Protege.LA y los contenidos y recursos de seguridad digital en SocialTIC.
Contexto regional
En 2016 y 2022, desde SocialTIC junto a otras organizaciones y medios locales e internacionales hicimos pública las campañas de #GobiernoEspía y #EjercitoEspía respectivamente, en donde documentamos los ataques a periodistas, activistas y personas defensoras con el spyware Pegasus.
Con la publicación de #GobiernoEspía México se convirtió en el primer país de América Latina en documentar el uso de este tipo de tecnologías, mientras que con #EjercitoEspía se documentó el uso de Pegasus en dos gobiernos distintos en el mismo país. Esto pese a las declaraciones del gobierno actual respecto al espionaje.
Existe evidencia de que en 2021 se utilizó Pegasus en El Salvador contra distintos periodistas y medios locales, al igual que existe evidencia de que entre 2020 y 2021 se utilizó Pegasus en República Dominicana contra la periodista Nuria Piera. Con esto se observa un crecimiento en el uso de spyware en la región, sin mencionar otro tipo de tecnologías de vigilancia y espionaje.
Es así que desde SocialTIC he podido observar de primera mano la evolución del espionaje en el contexto mexicano y latinoamericano. Evaluando este contexto y viendo la necesidad de más profesionales en el tema de forense digital para la defensa de derechos humanos es que decidí aplicar a la Digital Forensic Fellowship de Amnistía Internacional.
Estado actual de forense digital para la defensa de derechos humanos
Los primeros ataques con Pegasus requerían que las víctimas hicieran clic en un enlace malicioso (ataque 1-click) para comenzar la cadena de explotación e infección. Gracias a la existencia de estos enlaces es que se logró la detección y documentación de los primeros casos en México.
En la actualidad los ataques se realizan a través de la explotación de vulnerabilidades de día cero (0-day vulnerabilities) los cuales no requieren ninguna interacción por parte de las personas usuarias (zero-click attack) y pueden ser completamente silenciosas.
Esta evolución ha implicado que la detección de los ataques sea más compleja y ha requerido que el nivel de profundización en el ámbito forense para la defensa de los derechos humanos sea mayor, lo cual ha llevado al desarrollo de distintas herramientas como la Mobile Verification Toolkit (MVT) por parte del equipo de Amnesty Tech así como una metodología para su uso.
Del lado de las compañías, la situación es variada. En el caso de Apple, la compañía ha tomado la iniciativa (como resultado del trabajo realizado conjunto a sociedad civil) de enviar notificaciones sobre “Ataques patrocinados por un estado” (State sponsored attacks), lo cual ha permitido identificar potenciales casos de ataques o infecciones con spyware a dispositivos y cuentas de Apple. Esto a su vez está vinculado a la homogeneidad del ecosistema de productos y servicios de Apple, el cual permite tener un mayor control y estandarización de la información que se recopila y analiza en un proceso forense.
En el caso de Android, no existe el mismo nivel de homogeneidad o estandarización en la estructura interna de los sistemas o de los dispositivos. Por ejemplo, existe una variedad de versiones del sistema operativo con diferencias entre sí, o una amplia cantidad de fabricantes que añaden una capa de personalización extra sobre Android, o que incorporan herramientas adicionales a las que tiene en sí mismo el sistema de manera nativa. Todo esto implica que el análisis forense de dispositivos Android sea más complejo.
Si bien Google también ha tomado la iniciativa de enviar notificaciones sobre “Alertas de ataques respaldados por gobiernos” (Government-backed attack alerts), estos están vinculados directamente a los servicios de Google y no necesariamente a los dispositivos móviles, y menos aún a aquellos que son mantenidos por terceros como Samsung, Motorola, Huawei, Xiaomi, etc.
Otra consideración importante relacionada a lo anterior es la cuota de uso de dispositivos Android contra la cuota de uso de dispositivos iPhone. En el contexto mexicano la información reciente indica que esta cuota es de 75% para Android y 23% para iPhone, mientras que en la región de América del sur es de 85% para Android y 14% para iPhone, ambos datos a fecha de Agosto de 2023.
Es evidente que Android es el sistema operativo móvil mayormente utilizado en la región, y que al no existir la misma facilidad o estandarización para los análisis forenses como en el caso de iPhone se podría estar perdiendo una visión más amplia del uso de spyware contra las personas usuarias de Android.
Para el problema anterior en Android, existen dos herramientas que se pueden considerar para el proceso forense, la ya mencionada MVT y androidqf, ambas desarrolladas por el equipo de Amnesty Tech.
En términos generales, androidqf permite extraer de manera estandarizada información de dispositivos Android como son los logs del sistema, información relacionada a las aplicaciones instaladas o las configuraciones del sistema. En el caso de MVT, la herramienta permite analizar directamente un dispositivo o la información extraída mediante androidqf.
Si bien estas herramientas permiten estandarizar la extracción y análisis de información y dispositivos Android, estas requieren un conocimiento técnico básico de computadora y celular, y en el caso de MVT de la terminal y la línea de comandos. Además de que se asume que existe un equipo de cómputo a disposición de la persona que va a realizar la extracción o el análisis. Y en algunos casos en donde se brinda atención remota también se requiere una conexión de Internet estable y robusta para la comunicación y la transferencia de la información extraída para el análisis.
Lo anterior en algunos casos se vuelve complicado, por ejemplo, cuando la persona que requiere apoyo se encuentra físicamente en otro lugar y requiere atención remota. En situaciones así cabe la posibilidad de que la persona no cuente con un equipo de cómputo para realizar la extracción mediante androidqf, o que no cuente con una conexión estable para enviar la información por Internet, o que no tenga las habilidades en el manejo de un equipo de cómputo para realizar todo el proceso incluso con el apoyo remoto o en videollamada cuando se requiera su intervención.
Propuesta de solución
Contemplando todo lo mencionado hasta el momento, es que surge la idea de experimentar con el desarrollo de una herramienta que haga lo mismo que androidqf o MVT para extracción de información pero sin la dependencia de un equipo de cómputo y con mayor facilidad para compartir la información.
Este experimento tiene el nombre de apkqf o “APK Quick Forensics” en honor a androidqf.
El objetivo es desarrollar una aplicación para dispositivos Android que pueda extraer la misma información que androidqf y en el mismo formato, de tal modo que se pueda analizar mediante MVT como si fuera una extracción realizada con androidqf. Con esto se evita la necesidad de utilizar un equipo de cómputo y todo se realiza desde el dispositivo móvil de la persona.
También se propone que la información extraída sea empaquetada en un archivo comprimido y que este se pueda compartir mediante aplicaciones de mensajería instantánea como WhatsApp o mediante aplicaciones de nube como Google Drive, de tal modo que el compartir la información sea relativamente sencillo.
Desarrollo
Las funciones con las que cuenta la versión de androidqf sobre la que se basó el experimento son:
- Obtener un respaldo de mensajes SMS y MMS
- Obtener las propiedades del dispositivo
- Obtener las configuraciones del dispositivo (system, global, secure)
- Obtener los proceso en ejecución
- Obtener los servicios en ejecución
- Obtener la información de logcat
- Obtener los logs del dispositivo
- Obtener la información de dumpsys
- Descargar una copia de las aplicaciones instaladas
- Almacenar de manera segura la extracción de información
Todas estas funciones son implementadas a través del uso de adb en el lenguaje de programación Go.
En el caso de apkqf el objetivo era implementar la mayor cantidad de funciones a través de las APIs que provee Android y añadir las funciones adicionales de empaquetar y compartir mediante un tercero, todo esto respetando el formato de la información extraída por androidqf.
Para el desarrollo se decidió utilizar el lenguaje de programación Kotlin considerando que su sintaxis es más sencilla que la de Java y que tiene retrocompatibilidad con la máquina virtual de Android.
También se decidió que la versión mínima de Android a soportar fuera Android 4.1 Jelly Bean (API 16), la cual es la más antigua disponible al momento para desarrollo y que permitiría tener un mayor alcance de dispositivos que podrían utilizar apkqf.
Resultados
Durante el desarrollo de la aplicación surgieron detalles que no permitieron cumplir el objetivo inicial. Es así que no todas las funciones se implementaron de manera exitosa, y aquellas que se lograron implementar no siempre lograban extraer la misma información que androidqf.
Las funciones que no se lograron implementar mediante las APIs de Android se tuvieron que implementar mediante la ejecución de comandos a través de invocar una shell mediante un proceso hijo en la aplicación, simulando así el comportamiento de un comando de adb.
Las funciones que se lograron implementar mediante las APIs de Android fueron:
- Obtener un respaldo de mensajes SMS y MMS. Se logró extraer toda la información deseada.
- Obtener las configuraciones del dispositivo (system, global, secure). Se logró extraer toda la información deseada aunque con ligeros cambios en el orden de los datos.
- Obtener los procesos en ejecución. La información obtenida sólo correspondía a la aplicación en sí misma y no a elementos del sistema o de otras aplicaciones, además de que era menor a la obtenida por androidqf y no se podía mantener el mismo formato.
Las funciones que se lograron implementar mediante la simulación de comandos adb fueron:
- Obtener las propiedades del dispositivo. La información obtenida se encontraba incompleta, ya que algunas propiedades se encontraban ausentes o no se podían obtener sus valores.
- Obtener los procesos en ejecución. La información obtenida sólo correspondía a la aplicación en sí misma y no a elementos del sistema o de otras aplicaciones, además de que era menor a la obtenida por androidqf y no se podía mantener el mismo formato.
- Obtener los servicios en ejecución. La información obtenida se encontraba incompleta, ya que algunos servicios se encontraban ausentes o no se podían obtener sus datos.
- Obtener la información de logcat. La información obtenida sólo correspondía a la aplicación en sí misma y no a elementos del sistema o de otras aplicaciones.
- Obtener la información de dumpsys. La información obtenida sólo correspondía a la aplicación en sí misma y no a elementos del sistema o de otras aplicaciones.
Las funciones que no se lograron implementar:
- Obtener los logs del dispositivo. Debido a que no era posible acceder a las carpetas o archivos necesarios por falta de permisos.
- Descargar una copia de las aplicaciones instaladas. Se decidió no implementarse ya que en la teoría (gracias a la documentación de Android) es sabido que se puede obtener información de las aplicaciones pero no las copias de los archivos, y al observar que el resto de la información no estaba completa se decidió no proceder con esta función.
- Almacenar de manera segura la extracción de información. No se pretendía implementar de la misma manera que androidqf.
Debido a los resultados que se iban obteniendo, se decidió no implementar completamente las funciones de empaquetado de archivos y de envío mediante aplicaciones terceras, ya que los resultados no eran completamente positivos de la extracción de información. Además de que estas funciones sí se pueden implementar, se decidió no hacerlo ya que la extracción no fue exitosa al nivel esperado.
Reflexiones
Los resultados obtenidos se deben a los siguientes motivos:
- El modelo de seguridad de Android para la ejecución de aplicaciones. Todas las aplicaciones son ejecutadas en su propio contenedor, por lo cual solo pueden acceder a sus recursos (o recursos compartidos mediante la misma firma de desarrollo) y no a los recursos del sistema o de otras aplicaciones.
- La evolución de permisos en las distintas versiones de Android. Algunos de los permisos útiles para la extracción de información del sistema o del resto de aplicaciones se encuentran obsoletos a partir de Android 6. De igual manera, estos permisos si se encuentran disponibles en versiones superiores son considerados peligrosos y solo se pueden otorgar a aplicaciones del sistema, aplicaciones firmadas por el fabricante o aplicaciones de administración de dispositivos.
- El modelo de seguridad de Android para el acceso a permisos. Desde Android 6 la gestión de permisos cambió, por lo que es necesario realizar distintas verificaciones y solicitudes de permisos en tiempo de ejecución, lo cual combinado con el punto anterior, no asegura que todos los permisos se encuentren disponibles o accesibles.
Lo anterior era esperado, sin embargo, ahora se puede dimensionar mejor el nivel de acceso a información del dispositivo desde una aplicación nativa en Android.
Una posible solución para todo lo anterior sería rootear el dispositivo y darle permisos de superusuario a la aplicación, lo cual no es recomendado y es una mala práctica de seguridad.
Desde la versión de Android 11 es posible ejecutar adb mediante WiFi, por lo que una posible opción es intentar una conexión mediante sockets localmente que permitan simular una conexión a adb por WiFi. Esto podría funcionar para dispositivos recientes, y aunque deja una gran cantidad de dispositivos fuera se puede considerar como un avance en la materia.
Otra alternativa sería intentar desarrollar la aplicación como una aplicación de administración del dispositivo para tener otro tipos de permisos y accesos.
Conclusiones finales
Por el momento queda comprobado que la mejor forma de extraer la información es mediante androidqf y adb.
Algunas recomendaciones para androidqf que serían útiles (como resultado de las reflexiones de este experimento):
- Implementar una opción para empaquetar los datos en un archivo comprimido
- Implementar una opción para compartir la información mediante un servicio de terceros y que se genere un enlace del archivo compartido
- Generar una documentación más accesible para la descarga y uso de la herramienta, tal vez a través de videotutoriales o videos guiados para usuarios no técnicos
Las alternativas y opciones presentadas en la sección anterior se pretenden implementar y probar más adelante, buscando obtener una forma más accesible de extraer datos, principalmente para personas que no cuentan con un equipo de cómputo o con una conexión de Internet adecuada.
Pese a los resultados del experimento, considero que estos fueron exitosos ya que permiten tener una idea clara de lo que es posible y potenciales alternativas.
Por último, considero que es necesario seguir desarrollando herramientas y alternativas para el ámbito forense y la defensa de derechos humanos, contemplando el descontrol en el uso de herramientas de espionaje, los contextos de desigualdad y vulnerabilidad de algunos grupos o regiones, y las características y necesidades de estos (como es el uso masivo de dispositivos Android, la falta de equipos de cómputo o las complejidades de conexión a Internet).
Contacto: [email protected] , @_penserbjorne