<summary><strong>Aprende a hackear AWS desde cero hasta convertirte en un experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
Encuentra vulnerabilidades que importan más para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, ejecuta escaneos proactivos de amenazas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. [**¡Pruébalo gratis**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoy.
**A cada aplicación se le asigna un ID de usuario específico**. Esto se hace durante la instalación de la aplicación para que **la aplicación solo pueda interactuar con archivos propiedad de su ID de usuario o archivos compartidos**. Por lo tanto, solo la aplicación en sí, ciertos componentes del SO y el usuario root pueden acceder a los datos de las aplicaciones.
**Dos aplicaciones pueden configurarse para usar el mismo UID**. Esto puede ser útil para compartir información, pero si una de ellas se ve comprometida, los datos de ambas aplicaciones se verán comprometidos. Por eso este comportamiento es **desaconsejado**.\
La **Sandbox de Aplicaciones Android** permite ejecutar **cada aplicación** como un **proceso separado bajo un ID de usuario separado**. Cada proceso tiene su propia máquina virtual, por lo que el código de una aplicación se ejecuta de forma aislada de otras aplicaciones.\
A partir de Android 5.0(L) **SELinux** está implementado. Básicamente, SELinux denegó todas las interacciones de procesos y luego creó políticas para **permitir solo las interacciones esperadas entre ellos**.
Cuando instalas una **aplicación y solicita permisos**, la aplicación está pidiendo los permisos configurados en los elementos **`uses-permission`** en el archivo **AndroidManifest.xml**. El elemento **uses-permission** indica el nombre del permiso solicitado dentro del **atributo de nombre**. También tiene el atributo **maxSdkVersion** que deja de solicitar permisos en versiones superiores a la especificada.\
Ten en cuenta que las aplicaciones de Android no necesitan solicitar todos los permisos al principio, también pueden **solicitar permisos dinámicamente** pero todos los permisos deben estar **declarados** en el **manifiesto**.
* **Firma**: Solo **las aplicaciones firmadas por el mismo certificado que la que** exporta el componente pueden recibir permiso. Este es el tipo de protección más fuerte.
* **FirmaOSystema**: Solo **las aplicaciones firmadas por el mismo certificado que la que** exporta el componente o **las aplicaciones que se ejecutan con acceso a nivel de sistema** pueden recibir permisos.
Estas aplicaciones generalmente se encuentran en los directorios **`/system/app`** o **`/system/priv-app`** y algunas de ellas están **optimizadas** (es posible que ni siquiera encuentres el archivo `classes.dex`). Vale la pena verificar estas aplicaciones porque a veces están **ejecutándose con demasiados permisos** (como root).
Para obtener acceso root en un dispositivo Android físico generalmente necesitas **explotar** 1 o 2 **vulnerabilidades** que suelen ser **específicas** para el **dispositivo** y la **versión**.\
Una vez que la explotación ha funcionado, generalmente se copia el binario `su` de Linux en una ubicación especificada en la variable de entorno PATH del usuario como `/system/xbin`.
Una vez configurado el binario su, se utiliza otra aplicación de Android para interactuar con el binario `su` y **procesar solicitudes de acceso root** como **Superuser** y **SuperSU** (disponibles en Google Play Store).
Es posible **reemplazar el SO instalando un firmware personalizado**. Haciendo esto es posible extender la utilidad de un dispositivo antiguo, evadir restricciones de software o acceder al código más reciente de Android.\
Ten en cuenta que **no siempre es necesario rootear el dispositivo** para instalar un firmware personalizado. **Algunos fabricantes permiten** el desbloqueo de sus cargadores de arranque de manera bien documentada y segura.
Una vez que un dispositivo está rooteado, cualquier aplicación podría solicitar acceso como root. Si una aplicación maliciosa lo obtiene, podrá acceder a casi todo y podrá dañar el teléfono.
## Fundamentos de Aplicaciones Android <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
- El formato de las aplicaciones de Android se conoce como _formato de archivo APK_. Esencialmente es un **archivo ZIP** (al cambiar la extensión del archivo a .zip, se pueden extraer y ver los contenidos).
- resources.arsc: contiene recursos precompilados, como XML binario.
- res/xml/files\_paths.xml
- META-INF/
- ¡Aquí se encuentra el Certificado!
- **classes.dex**
- Contiene bytecode Dalvik, que representa el código Java (o Kotlin) compilado que la aplicación ejecuta de forma predeterminada.
- lib/
- Contiene bibliotecas nativas, segregadas por arquitectura de CPU en subdirectorios.
-`armeabi`: código para procesadores basados en ARM
-`armeabi-v7a`: código para procesadores basados en ARMv7 y superiores
-`x86`: código para procesadores X86
-`mips`: código solo para procesadores MIPS
- assets/
- Almacena archivos diversos necesarios para la aplicación, potencialmente incluyendo bibliotecas nativas adicionales o archivos DEX, a veces utilizados por autores de malware para ocultar código adicional.
- res/
- Contiene recursos que no se compilan en resources.arsc
En el desarrollo de Android, se utiliza **Java o Kotlin** para crear aplicaciones. En lugar de utilizar la JVM como en las aplicaciones de escritorio, Android compila este código en **código de bytes Dalvik ejecutable (DEX)**. Anteriormente, la máquina virtual Dalvik manejaba este bytecode, pero ahora, el Tiempo de Ejecución de Android (ART) se encarga en las versiones más nuevas de Android.
Para la ingeniería inversa, **Smali** se vuelve crucial. Es la versión legible por humanos del bytecode DEX, actuando como lenguaje ensamblador al traducir el código fuente en instrucciones de bytecode. Smali y baksmali se refieren a las herramientas de ensamblaje y desensamblaje en este contexto.
La **Acción** del intent previamente declarado es **ACTION\_SEND** y el **Extra** es un **Uri** de mailto (el Extra es la información adicional que el intent espera).
El proceso de "resolución de intenciones" determina qué aplicación debe recibir cada mensaje. Este proceso considera el atributo de **prioridad**, que se puede establecer en la **declaración del intent-filter**, y **se seleccionará el que tenga la prioridad más alta**. Esta prioridad se puede establecer entre -1000 y 1000 y las aplicaciones pueden usar el valor `SYSTEM_HIGH_PRIORITY`. Si surge un **conflicto**, aparece una ventana de "selector" para que el **usuario pueda decidir**.
Estas permiten que otras aplicaciones **realicen acciones en nombre de tu aplicación**, utilizando la identidad y permisos de tu aplicación. Al construir una Intención Pendiente, se debe **especificar una intención y la acción a realizar**. Si la **intención declarada no es explícita** (no declara qué intención puede llamarla), una **aplicación maliciosa podría realizar la acción declarada** en nombre de la aplicación víctima. Además, **si no se especifica una acción**, la aplicación maliciosa podrá realizar **cualquier acción en nombre de la víctima**.
A diferencia de las intenciones anteriores, que solo son recibidas por una aplicación, las intenciones de difusión **pueden ser recibidas por múltiples aplicaciones**. Sin embargo, a partir de la versión 14 de la API, es **posible especificar la aplicación que debe recibir** el mensaje utilizando Intent.setPackage.
Existen **dos tipos** de Difusiones: **Normales** (asincrónicas) y **Ordenadas** (sincrónicas). El **orden** se basa en la **prioridad configurada dentro del receptor**. **Cada aplicación puede procesar, retransmitir o descartar la Difusión**.
También se puede utilizar la función **`sendBroadcast`** del **`LocalBroadCastManager`** para asegurar que el **mensaje nunca abandone la aplicación**. Al hacer esto, ni siquiera necesitarás exportar un componente receptor.
Si encuentras funciones que contienen la palabra "pegajoso" como **`sendStickyBroadcast`** o **`sendStickyBroadcastAsUser`**, **verifica el impacto e intenta eliminarlas**.
En las aplicaciones de Android, los **enlaces profundos** se utilizan para iniciar una acción (Intención) directamente a través de una URL. Esto se hace declarando un **esquema de URL específico** dentro de una actividad. Cuando un dispositivo Android intenta **acceder a una URL con este esquema**, se inicia la actividad especificada dentro de la aplicación.
El **Lenguaje de Definición de Interfaz de Android (AIDL)** está diseñado para facilitar la comunicación entre el cliente y el servicio en aplicaciones de Android a través de la **comunicación entre procesos** (IPC). Dado que en Android no está permitido acceder directamente a la memoria de otro proceso, AIDL simplifica el proceso al convertir objetos en un formato entendido por el sistema operativo, facilitando así la comunicación entre diferentes procesos.
- **Servicios Vinculados**: Estos servicios utilizan AIDL para IPC, permitiendo que actividades o componentes se vinculen a un servicio, realicen solicitudes y reciban respuestas. El método `onBind` en la clase del servicio es crucial para iniciar la interacción, convirtiéndolo en un área vital para la revisión de seguridad en busca de vulnerabilidades.
- **Messenger**: Funcionando como un servicio vinculado, Messenger facilita el IPC con un enfoque en el procesamiento de datos a través del método `onBind`. Es esencial inspeccionar este método detenidamente en busca de un manejo inseguro de datos o la ejecución de funciones sensibles.
- **Binder**: Aunque el uso directo de la clase Binder es menos común debido a la abstracción de AIDL, es beneficioso entender que Binder actúa como un controlador a nivel de kernel que facilita la transferencia de datos entre los espacios de memoria de diferentes procesos. Para una mayor comprensión, hay un recurso disponible en [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8).
En las aplicaciones de Android, las **actividades** son como pantallas que muestran diferentes partes de la interfaz de usuario de la aplicación. Una aplicación puede tener muchas actividades, cada una presentando una pantalla única al usuario.
La **actividad de inicio** es la puerta de entrada principal a una aplicación, se inicia cuando se toca el icono de la aplicación. Se define en el archivo de manifiesto de la aplicación con intenciones MAIN y LAUNCHER específicas:
Las actividades pueden estar disponibles para otras aplicaciones o procesos marcándolas como "exportadas" en el manifiesto. Esta configuración permite que otras aplicaciones inicien esta actividad:
Sin embargo, acceder a una actividad desde otra aplicación no siempre es un riesgo de seguridad. La preocupación surge si se comparten datos sensibles de manera inadecuada, lo que podría llevar a fugas de información.
El ciclo de vida de una actividad **comienza con el método onCreate**, configurando la interfaz de usuario y preparando la actividad para la interacción con el usuario.
En el desarrollo de Android, una aplicación tiene la opción de crear una **subclase** de la clase [Application](https://developer.android.com/reference/android/app/Application), aunque no es obligatorio. Cuando se define dicha subclase, se convierte en la primera clase que se instancia dentro de la aplicación. El método **`attachBaseContext`**, si se implementa en esta subclase, se ejecuta antes del método **`onCreate`**. Esta configuración permite una inicialización temprana antes de que el resto de la aplicación comience.
[Los servicios](https://developer.android.com/guide/components/services) son **operativos en segundo plano** capaces de ejecutar tareas sin una interfaz de usuario. Estas tareas pueden seguir ejecutándose incluso cuando los usuarios cambian a diferentes aplicaciones, lo que hace que los servicios sean cruciales para **operaciones de larga duración**.
Los servicios son versátiles; pueden iniciarse de varias formas, siendo los **Intents** el método principal para lanzarlos como punto de entrada de una aplicación. Una vez que un servicio se inicia utilizando el método `startService`, su método `onStart` entra en acción y sigue ejecutándose hasta que se llame explícitamente al método `stopService`. Alternativamente, si el rol de un servicio depende de una conexión activa con el cliente, se utiliza el método `bindService` para vincular el cliente al servicio, involucrando el método `onBind` para el paso de datos.
Una aplicación interesante de los servicios incluye la reproducción de música en segundo plano o la obtención de datos de red sin obstaculizar la interacción del usuario con una aplicación. Además, los servicios pueden hacerse accesibles a otros procesos en el mismo dispositivo a través de la **exportación**. Este no es el comportamiento predeterminado y requiere una configuración explícita en el archivo Android Manifest:
Los **receptores de difusión** actúan como oyentes en un sistema de mensajería, permitiendo que múltiples aplicaciones respondan a los mismos mensajes del sistema. Una aplicación puede **registrar un receptor** de **dos formas principales**: a través del **Manifiesto** de la aplicación o **dinámicamente** dentro del código de la aplicación mediante la API **`registerReceiver`**. En el Manifiesto, las difusiones se filtran con permisos, mientras que los receptores registrados dinámicamente también pueden especificar permisos al registrarse.
Los **filtros de intención** son cruciales en ambos métodos de registro, determinando qué difusiones activan el receptor. Una vez que se envía una difusión coincidente, se invoca el método **`onReceive`** del receptor, lo que permite que la aplicación reaccione en consecuencia, como ajustar el comportamiento en respuesta a una alerta de batería baja.
Las difusiones pueden ser **asincrónicas**, llegando a todos los receptores sin orden, o **sincrónicas**, donde los receptores reciben la difusión según prioridades establecidas. Sin embargo, es importante tener en cuenta el riesgo de seguridad potencial, ya que cualquier aplicación puede priorizarse a sí misma para interceptar una difusión.
Para comprender la funcionalidad de un receptor, busque el método **`onReceive`** dentro de su clase. El código de este método puede manipular la Intención recibida, resaltando la necesidad de validación de datos por parte de los receptores, especialmente en **Difusiones Ordenadas**, que pueden modificar o eliminar la Intención.
Los **proveedores de contenido** son esenciales para **compartir datos estructurados** entre aplicaciones, enfatizando la importancia de implementar **permisos** para garantizar la seguridad de los datos. Permiten que las aplicaciones accedan a datos de diversas fuentes, incluidas bases de datos, sistemas de archivos o la web. Permisos específicos, como **`readPermission`** y **`writePermission`**, son cruciales para controlar el acceso. Además, se puede otorgar acceso temporal a través de la configuración **`grantUriPermission`** en el manifiesto de la aplicación, aprovechando atributos como `path`, `pathPrefix` y `pathPattern` para un control de acceso detallado.
La validación de entrada es fundamental para prevenir vulnerabilidades, como la inyección SQL. Los proveedores de contenido admiten operaciones básicas: `insert()`, `update()`, `delete()` y `query()`, facilitando la manipulación y el intercambio de datos entre aplicaciones.
**FileProvider**, un Proveedor de Contenido especializado, se centra en compartir archivos de forma segura. Se define en el manifiesto de la aplicación con atributos específicos para controlar el acceso a carpetas, indicadas por `android:exported` y `android:resource` que apuntan a configuraciones de carpetas. Se recomienda precaución al compartir directorios para evitar exponer datos sensibles inadvertidamente.
Los WebViews son como **mini navegadores web** dentro de las aplicaciones de Android, que muestran contenido ya sea desde la web o desde archivos locales. Enfrentan riesgos similares a los navegadores regulares, pero existen formas de **reducir estos riesgos** a través de **configuraciones específicas**.
- **WebViewClient** es ideal para HTML básico pero no admite la función de alerta JavaScript, lo que afecta la forma en que se pueden probar los ataques XSS.
- **WebChromeClient** se comporta más como la experiencia completa del navegador Chrome.
Para cargar contenido, se pueden utilizar métodos como ````loadUrl````, ````loadData````, y ````loadDataWithBaseURL````. Es crucial asegurarse de que estas URL o archivos sean **seguros de usar**. Las configuraciones de seguridad se pueden gestionar a través de la clase ````WebSettings````. Por ejemplo, deshabilitar JavaScript con ````setJavaScriptEnabled(false)```` puede prevenir ataques XSS.
El "Puente" JavaScript permite que los objetos Java interactúen con JavaScript, requiriendo que los métodos estén marcados con ````@JavascriptInterface```` para seguridad a partir de Android 4.2.
Permitir acceso al contenido (````setAllowContentAccess(true)````) permite que los WebViews accedan a los Proveedores de contenido, lo cual podría ser un riesgo a menos que las URL de contenido se verifiquen como seguras.
- Deshabilitar el acceso a archivos (````setAllowFileAccess(false)````) limita el acceso al sistema de archivos, con excepciones para ciertos activos, asegurando que solo se utilicen para contenido no sensible.
- La **firma digital** es imprescindible para las aplicaciones de Android, asegurando que estén **autenticadas correctamente** antes de la instalación. Este proceso utiliza un certificado para la identificación de la aplicación y debe ser verificado por el administrador de paquetes del dispositivo al instalarla. Las aplicaciones pueden ser **auto-firmadas o certificadas por una CA externa**, protegiéndolas contra accesos no autorizados y garantizando que la aplicación permanezca intacta durante su entrega al dispositivo.
- A partir de **Android 4.2**, una función llamada **Verificar aplicaciones** permite a los usuarios verificar la seguridad de las aplicaciones antes de la instalación. Este **proceso de verificación** puede advertir a los usuarios sobre aplicaciones potencialmente dañinas, o incluso prevenir la instalación de aquellas particularmente maliciosas, mejorando la seguridad del usuario.
- Las **soluciones de MDM** proporcionan **supervisión y seguridad** para dispositivos móviles a través de la **API de Administración de Dispositivos**. Requieren la instalación de una aplicación de Android para gestionar y asegurar dispositivos móviles de manera efectiva. Las funciones clave incluyen **imponer políticas de contraseñas**, **exigir cifrado de almacenamiento**, y **permitir el borrado remoto de datos**, garantizando un control y seguridad completos sobre los dispositivos móviles.
Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, ejecuta escaneos proactivos de amenazas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. [**Pruébalo gratis**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoy.
<summary><strong>Aprende a hackear AWS desde cero hasta convertirte en un héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
