Estructura de aplicaciones Android

Una aplicación de Android se distribuye como un APK (Android Package). En realidad, es un archivo ZIP que contiene el código compilado, los recursos y los metadatos.

Como es un ZIP, basta con descomprimirlo para inspeccionar su contenido, que es el primer paso en un pentest móvil.

Un APK extraído contiene:

• AndroidManifest.xml: configuración de la aplicación.
• classes.dex: bytecode compilado.
• res/ y resources.arsc: recursos.
• lib/: bibliotecas nativas.
• META-INF/: información de firma.

El AndroidManifest.xml declara los componentes, los permisos y la configuración de la aplicación. En el APK se encuentra en formato XML binario, que las herramientas pueden decodificar.

Es el archivo más importante para comprender la superficie de ataque de una aplicación.

El código fuente de Java/Kotlin se compila en bytecode DEX (Dalvik Executable) dentro de classes.dex. Las versiones modernas de Android lo ejecutan mediante ART (Android Runtime).

El DEX puede convertirse de nuevo en código legible, que es lo que aprovecha el análisis estático de los APK.

Las aplicaciones de Android se construyen a partir de cuatro tipos de componentes:

• Activities: pantallas o interfaz de usuario.
• Services: tareas en segundo plano.
• Broadcast Receivers: responden a eventos del sistema.
• Content Providers: comparten datos entre aplicaciones.

Un componente marcado como android:exported="true" puede ser invocado por otras aplicaciones. Si dicho componente realiza acciones sensibles sin comprobaciones, constituye una superficie de ataque.

Los pentesters buscan activities, services y providers exportados que filtren datos o realicen acciones con privilegios.

Las aplicaciones solicitan permisos en el manifiesto (por ejemplo, INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

Los permisos demasiado amplios pueden indicar un comportamiento arriesgado o un acceso excesivo a los datos. Los permisos personalizados también pueden estar mal configurados y permitir accesos no autorizados.

Android aísla cada aplicación en su propio sandbox, con un UID de Linux único. De forma predeterminada, las aplicaciones no pueden leer los datos de las demás.

Las vulnerabilidades aparecen cuando las aplicaciones debilitan este límite, por ejemplo, mediante archivos legibles por cualquiera o providers expuestos.

Una aplicación instalada almacena sus datos privados en /data/data/<package>/: bases de datos, preferencias compartidas y archivos.

En un dispositivo rooteado o mediante copias de seguridad, un pentester inspecciona este directorio en busca de secretos almacenados de forma insegura, un tema que se tratará en una lección posterior.

Cada APK está firmado digitalmente; la firma se encuentra en META-INF/. Android la verifica durante la instalación y las actualizaciones.

Si modifica y vuelve a empaquetar una aplicación, debe firmarla de nuevo, por lo que los desarrolladores dependen de la firma para detectar manipulaciones.

La lógica crítica para el rendimiento o la lógica ofuscada puede encontrarse en bibliotecas nativas (archivos .so) dentro de lib/, compiladas a partir de C/C++.

Estas bibliotecas no están en DEX, por lo que requieren un análisis independiente con desensambladores nativos. A veces los desarrolladores ocultan secretos aquí, creyendo erróneamente que el código nativo es más difícil de inspeccionar.

Recuerde qué atributo del manifiesto expone un componente a otras aplicaciones.

Ahora comprende la estructura de las aplicaciones de Android:

• Un APK es un ZIP que contiene AndroidManifest.xml, classes.dex, recursos y datos de firma.
• Las aplicaciones utilizan cuatro componentes; los componentes exportados forman parte de la superficie de ataque.
• Los permisos y el sandbox de cada aplicación regulan el acceso; los datos privados se encuentran en /data/data/.
• Los APK están firmados para detectar manipulaciones.

A continuación, descompilará un APK mediante análisis estático.