Aprende y practica Hacking en AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprende y practica Hacking en GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos de github.
**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 propia aplicación, ciertos componentes del SO y el usuario root pueden acceder a los datos de la aplicación.
**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 esta razón, este comportamiento es **desaconsejado**.\
El **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 en aislamiento de otras aplicaciones.\
Desde Android 5.0(L), se aplica **SELinux**. Básicamente, SELinux deniega todas las interacciones de procesos y luego crea 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 name**. También tiene el atributo **maxSdkVersion** que detiene la solicitud de permisos en versiones superiores a la especificada.\
Ten en cuenta que las aplicaciones de Android no necesitan pedir todos los permisos al principio, también pueden **solicitar permisos dinámicamente**, pero todos los permisos deben ser **declarados** en el **manifiesto**.
* **Firma**: Solo **las aplicaciones firmadas por el mismo certificado que el que** exporta el componente pueden recibir permiso. Este es el tipo de protección más fuerte.
* **FirmaOSistema**: Solo **las aplicaciones firmadas por el mismo certificado que el 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** (puede que ni siquiera encuentres el archivo `classes.dex`). Estas aplicaciones valen la pena revisar 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 **versión**.\
Una vez que la explotación ha funcionado, generalmente se copia el binario de Linux `su` en una ubicación especificada en la variable de entorno PATH del usuario, como `/system/xbin`.
Una vez que el binario de su está configurado, se utiliza otra aplicación de Android para interactuar con el binario `su` y **procesar solicitudes de acceso root** como **Superuser** y **SuperSU** (disponible en Google Play Store).
Es posible **reemplazar el SO instalando un firmware personalizado**. Haciendo esto, es posible extender la utilidad de un dispositivo antiguo, eludir restricciones de software o acceder al último código 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 bootloaders 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, tendrá acceso a casi todo y podrá dañar el teléfono.
- El formato de las aplicaciones Android se conoce como _formato de archivo APK_. Es esencialmente un **archivo ZIP** (cambiando la extensión del archivo a .zip, se pueden extraer y ver los contenidos).
- Almacena archivos diversos necesarios para la aplicación, que pueden incluir bibliotecas nativas adicionales o archivos DEX, a veces utilizados por autores de malware para ocultar código adicional.
En el desarrollo de Android, se utiliza **Java o Kotlin** para crear aplicaciones. En lugar de usar la JVM como en las aplicaciones de escritorio, Android compila este código en **bytecode ejecutable Dalvik (DEX)**. Anteriormente, la máquina virtual Dalvik manejaba este bytecode, pero ahora, el Android Runtime (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 un 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.
Las intenciones son el medio principal por el cual las aplicaciones Android se comunican entre sus componentes o con otras aplicaciones. Estos objetos de mensaje también pueden transportar datos entre aplicaciones o componentes, similar a cómo se utilizan las solicitudes GET/POST en las comunicaciones HTTP.
Así que una Intención es básicamente un **mensaje que se pasa entre componentes**. Las Intenciones **pueden ser dirigidas** a componentes o aplicaciones específicas, **o pueden enviarse sin un destinatario específico**.\
**Los Filtros de Intención** definen **cómo una actividad, servicio o Receptor de Transmisión puede interactuar con diferentes tipos de Intenciones**. Esencialmente, describen las capacidades de estos componentes, como qué acciones pueden realizar o los tipos de transmisiones que pueden procesar. El lugar principal para declarar estos filtros es dentro del **archivo AndroidManifest.xml**, aunque para los Receptores de Transmisión, también es una opción codificarlos.
Los Filtros de Intención se componen de categorías, acciones y filtros de datos, con la posibilidad de incluir metadatos adicionales. Esta configuración permite que los componentes manejen Intenciones específicas que coincidan con los criterios declarados.
Un aspecto crítico de los componentes de Android (actividades/servicios/proveedores de contenido/receptores de transmisión) es su visibilidad o **estado público**. Un componente se considera público y puede interactuar con otras aplicaciones si está **`exportado`** con un valor de **`true`** o si se declara un Filtro de Intención para él en el manifiesto. Sin embargo, hay una manera para que los desarrolladores mantengan explícitamente estos componentes privados, asegurando que no interactúen con otras aplicaciones de manera no intencionada. Esto se logra configurando el atributo **`exported`** a **`false`** en sus definiciones de manifiesto.
Además, los desarrolladores tienen la opción de asegurar aún más el acceso a estos componentes al requerir permisos específicos. El atributo **`permission`** se puede establecer para hacer cumplir que solo las aplicaciones con el permiso designado puedan acceder al componente, agregando una capa adicional de seguridad y control sobre quién puede interactuar con él.
La **Acción** de la intención declarada previamente es **ACTION\_SEND** y el **Extra** es un mailto **Uri** (el Extra es la información adicional que la intención está esperando).
El proceso de "resolución de Intent" determina qué aplicación debe recibir cada mensaje. Este proceso considera el **atributo de prioridad**, que se puede establecer en la **declaración de intent-filter**, y **el que tenga la mayor prioridad será seleccionado**. 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 "elección" para que el **usuario pueda decidir**.
Estos permiten que otras aplicaciones **realicen acciones en nombre de su aplicación**, utilizando la identidad y los permisos de su app. Al construir un Pending Intent, se debe **especificar un intent y la acción a realizar**. Si el **intent declarado no es explícito** (no declara qué intent puede llamarlo), una **aplicación maliciosa podría realizar la acción declarada** en nombre de la app víctima. Además, **si no se especifica una acción**, la app maliciosa podrá hacer **cualquier acción en nombre de la víctima**.
A diferencia de los intents anteriores, que solo son recibidos por una app, los broadcast intents **pueden ser recibidos por múltiples apps**. Sin embargo, desde la versión de API 14, es **posible especificar la app que debería recibir** el mensaje usando Intent.setPackage.
Hay **dos tipos** de Broadcasts: **Normal** (asíncrono) y **Ordenado** (síncrono). El **orden** se basa en la **prioridad configurada dentro del elemento receptor**. **Cada app puede procesar, retransmitir o descartar el Broadcast.**
Es posible **enviar** un **broadcast** usando la función `sendBroadcast(intent, receiverPermission)` de la clase `Context`.\ También podría usar la función **`sendBroadcast`** de **`LocalBroadCastManager`** que asegura que el **mensaje nunca salga de la app**. Usando esto, ni siquiera necesitará exportar un componente receptor.
Si encuentra funciones que contengan la palabra "sticky" como **`sendStickyBroadcast`** o **`sendStickyBroadcastAsUser`**, **verifique el impacto y trate de eliminarlas**.
En las aplicaciones de Android, **deep links** se utilizan para iniciar una acción (Intent) 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 lanza la actividad especificada dentro de la aplicación.
El **Lenguaje de Definición de Interfaces 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 **comunicación entre procesos** (IPC). Dado que no se permite acceder directamente a la memoria de otro proceso en Android, AIDL simplifica el proceso al marshalling de 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 crítico para iniciar la interacción, marcándolo como un área vital para la revisión de seguridad en busca de vulnerabilidades.
- **Messenger**: Operando como un servicio vinculado, Messenger facilita IPC con un enfoque en el procesamiento de datos a través del método `onBind`. Es esencial inspeccionar este método de cerca en busca de cualquier manejo de datos inseguro o 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 núcleo que facilita la transferencia de datos entre los espacios de memoria de diferentes procesos. Para una comprensión más profunda, 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, mostrando diferentes partes de la interfaz de usuario de la app. Una app puede tener muchas actividades, cada una presentando una pantalla única al usuario.
La **actividad de lanzamiento** es la puerta principal a una app, lanzada cuando tocas el ícono de la app. Se define en el archivo de manifiesto de la app con intenciones específicas MAIN y LAUNCHER:
No todas las aplicaciones necesitan una actividad de lanzamiento, especialmente aquellas sin una interfaz de usuario, como los servicios en segundo plano.
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 de otra aplicación no siempre es un riesgo de seguridad. La preocupación surge si se comparten datos sensibles de manera inapropiada, lo que podría llevar a filtraciones 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 tal subclase, se convierte en la primera clase en ser instanciada 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 comience el resto de la aplicación.
[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 continuar 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 maneras, siendo **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 llama explícitamente al método `stopService`. Alternativamente, si el papel de un servicio depende de una conexión de cliente activa, se utiliza el método `bindService` para vincular al cliente con el servicio, activando 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 **exportación**. Este no es el comportamiento predeterminado y requiere una configuración explícita en el archivo Android Manifest:
**Broadcast receivers** 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 maneras principales**: a través del **Manifest** de la aplicación o **dinámicamente** dentro del código de la aplicación mediante la API **`registerReceiver`**. En el Manifest, las transmisiones 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é transmisiones activan el receptor. Una vez que se envía una transmisió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 transmisiones pueden ser **asíncronas**, alcanzando todos los receptores sin orden, o **sincrónicas**, donde los receptores reciben la transmisión según las 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 transmisión.
Para entender la funcionalidad de un receptor, busque el método **`onReceive`** dentro de su clase. El código de este método puede manipular la Intent recibida, destacando la necesidad de validación de datos por parte de los receptores, especialmente en **Broadcasts Ordenados**, que pueden modificar o eliminar la Intent.
**Content Providers** 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, incluidos 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 configuraciones de **`grantUriPermission`** en el manifest de la aplicación, aprovechando atributos como `path`, `pathPrefix` y `pathPattern` para un control de acceso detallado.
La validación de entrada es primordial para prevenir vulnerabilidades, como la inyección SQL. Los Content Providers admiten operaciones básicas: `insert()`, `update()`, `delete()`, y `query()`, facilitando la manipulación y el intercambio de datos entre aplicaciones.
**FileProvider**, un Content Provider especializado, se centra en compartir archivos de manera segura. Se define en el manifest de la aplicación con atributos específicos para controlar el acceso a carpetas, denotadas por `android:exported` y `android:resource` que apuntan a configuraciones de carpetas. Se aconseja precaución al compartir directorios para evitar exponer datos sensibles inadvertidamente.
WebViews son como **mini navegadores web** dentro de aplicaciones Android, extrayendo contenido ya sea de la web o de archivos locales. Enfrentan riesgos similares a los de los navegadores regulares, sin embargo, hay formas de **reducir estos riesgos** a través de **configuraciones** específicas.
Para cargar contenido, están disponibles métodos como ````loadUrl````, ````loadData````, y ````loadDataWithBaseURL````. Es crucial asegurarse de que estas URLs o archivos sean **seguros para 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 "Bridge" de JavaScript permite que los objetos Java interactúen con JavaScript, requiriendo que los métodos estén marcados con ````@JavascriptInterface```` para seguridad desde Android 4.2 en adelante.
Permitir el acceso al contenido (````setAllowContentAccess(true)````) permite que los WebViews accedan a Content Providers, lo que podría ser un riesgo a menos que las URLs 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 Android, asegurando que sean **auténticamente creadas** 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 momento de la instalación. Las aplicaciones pueden ser **autofirmadas o certificadas por una CA externa**, protegiendo contra accesos no autorizados y asegurando que la aplicación permanezca sin alteraciones 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 MDM** proporcionan **supervisión y seguridad** para dispositivos móviles a través de la **API de Administración de Dispositivos**. Necesitan la instalación de una aplicación Android para gestionar y asegurar dispositivos móviles de manera efectiva. Las funciones clave incluyen **hacer cumplir políticas de contraseñas**, **exigir cifrado de almacenamiento**, y **permitir el borrado remoto de datos**, asegurando un control y seguridad completos sobre los dispositivos móviles.
Aprende y practica Hacking en AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprende y practica Hacking en GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
