Para experimentar con los proveedores de contenido, se puede utilizar el comando `content` en dispositivos Android. No es necesario tener acceso root. Por ejemplo, para ver la lista de archivos gestionados por Media Store, se puede ejecutar el siguiente comando: ```bash $ content query --uri content://media/external/file ``` Para hacer que la salida sea más amigable para el usuario, se puede limitar las columnas mostradas al identificador y la ruta de cada archivo indexado. ```bash $ content query --uri content://media/external/file --projection _id,_data ``` Los proveedores de medios existen en su propio espacio de nombres privado. Como se ilustra en el ejemplo anterior, para acceder a un proveedor de contenido se debe especificar el URI correspondiente `content://`. Generalmente, la información sobre las rutas a través de las cuales se puede acceder a un proveedor se puede recuperar mirando los manifiestos de las aplicaciones (en caso de que el proveedor de contenido sea exportado por una aplicación) o el código fuente del framework de Android. Curiosamente, en dispositivos Android, Chrome admite el acceso a proveedores de contenido a través del esquema `content://`. Esta característica permite al navegador acceder a recursos (por ejemplo, fotos, documentos, etc.) exportados por aplicaciones de terceros. Para verificar esto, se puede insertar una entrada personalizada en la Media Store y luego acceder a ella usando el navegador: ```bash $ cd /sdcard $ echo "Hello, world!" > test.txt $ content insert --uri content://media/external/file \ --bind _data:s:/storage/emulated/0/test.txt \ --bind mime_type:s:text/plain ``` Para descubrir el identificador del archivo recién insertado: ```bash $ content query --uri content://media/external/file \ --projection _id,_data | grep test.txt Row: 283 _id=747, _data=/storage/emulated/0/test.txt ``` Y para ver el archivo en Chrome, se puede utilizar una URL como la que se muestra en la siguiente imagen. Observe el identificador de archivo 747 (descubierto anteriormente) que se utiliza como sufijo en la URL. ![Chrome "Hello, world!"](https://census-labs.com/media/whatsapp-screenshot-hello-world.png) Por ejemplo, se podrían listar todos los archivos relacionados con WhatsApp con: ```bash $ content query --uri content://media/external/file --projection _id,_data | grep -i whatsapp ... Row: 82 _id=58, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache Row: 83 _id=705, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache/157.240.9.53.443 Row: 84 _id=239, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache/crashlogs.whatsapp.net.443 Row: 85 _id=240, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache/pps.whatsapp.net.443 Row: 86 _id=90, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache/static.whatsapp.net.443 Row: 87 _id=706, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache/v.whatsapp.net.443 Row: 88 _id=89, _data=/storage/emulated/0/Android/data/com.whatsapp/cache/SSLSessionCache/www.whatsapp.com.443 ... ``` ## El bypass de la Política de Origen Same-Origin-Policy CVE-2020-6516 de Chrome La _Política de Origen Same-Origin_ (SOP) \[[12](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin\_policy)] en los navegadores dicta que el contenido Javascript de la URL A solo podrá acceder al contenido en la URL B si los siguientes atributos de la URL permanecen iguales para A y B: * El protocolo, por ejemplo, `https` vs. `http` * El dominio, por ejemplo, `www.example1.com` vs. `www.example2.com` * El puerto, por ejemplo, `www.example1.com:8080` vs. `www.example1.com:8443` Por supuesto, hay excepciones a las reglas anteriores, pero en general, un recurso de `https://www.example1.com` (por ejemplo, un fragmento de código Javascript) no puede acceder al DOM de un recurso en `https://www.example2.com`, ya que esto introduciría graves fugas de información. **A menos que una política de Compartición de Recursos de Origen Cruzado (CORS) lo permita explícitamente, no debería ser posible que un recurso web evite las reglas de SOP.** Es esencial tener en cuenta que Chrome considera `content://` como un _esquema local_, al igual que `file://`. En este caso, las reglas de SOP son aún más estrictas, ya que cada URL de esquema local se considera un origen separado. Por ejemplo, el código Javascript en **file:///tmp/test.html** no debería poder acceder al contenido de **file:///tmp/test2.html**, o cualquier otro archivo en el sistema de archivos. **En consecuencia, según las reglas de SOP, un recurso cargado a través de `content://` no debería poder acceder a ningún otro recurso `content://`.** Bueno, la vulnerabilidad CVE-2020-6516 de Chrome creó una "excepción" a esta regla. CVE-2020-6516 \[[03](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6516)] es un bypass de SOP en recursos cargados a través de una URL `content://`. **Por ejemplo, el código Javascript, que se ejecuta desde el contexto de un documento HTML cargado desde `content://com.example.provider/test.html`, puede cargar y acceder a cualquier otro recurso cargado a través de una URL `content://`.** Esta es una vulnerabilidad grave, especialmente en dispositivos que ejecutan Android 9 o versiones anteriores de Android. En estos dispositivos, el almacenamiento con ámbito \[[13](https://developer.android.com/about/versions/10/privacy/changes#scoped-storage)] no está implementado y, en consecuencia, los datos específicos de la aplicación en **/sdcard**, y más interesante aún, en **/sdcard/Android**, se pueden acceder a través del proveedor de contenido de Media Store del sistema. Un ejemplo de prueba de concepto es bastante sencillo. Se carga un documento HTML que utiliza `XMLHttpRequest` para acceder a URL `content://` arbitrarias en **/sdcard**. Luego se agrega en Media Store y se renderiza en Chrome, de manera similar al ejemplo mostrado anteriormente. Para fines de demostración, se puede intentar cargar `content://media/external/file/747`, que es, de hecho, la URL de Media Store del ejemplo "Hola, mundo!". Sorprendentemente, el código Javascript, que se ejecuta dentro del origen del documento HTML, recuperará y mostrará el contenido de **test.txt**. ```markup PoC ``` **Información tomada de este artículo:** [**https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/**](https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 - ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)! - Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) - Obtén la [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com) - **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme en** **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.** - **Comparte tus trucos de hacking enviando PRs al repositorio [hacktricks](https://github.com/carlospolop/hacktricks) y al repositorio [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.