Appsmith Patches Full-Read SSRF Vulnerabilities Reported by CloudSEK

Appsmith Patches Full-Read SSRF Vulnerabilities

Authors : Sparsh Kulshrestha and Shashank Bharthwal
Editor : Deepanjli Paulraj

Executive Summary

THREAT IMPACT MITIGATION

CloudSEK ASM discovered post-authentication full read SSRF (Server-side request forgery) vulnerabilities in Appsmith’s REST Client (CVE-2022-38298) and Elasticsearch (CVE-2022-38299).

The SSRF vulnerability can be exploited to access AWS/GCP metadata services and obtain temporary security credentials of the Appsmith cloud environment.

Introduction

In August 2022 CloudSEK ASM, which monitors our customers’ attack surfaces, discovered several internet exposed instances of Appsmith. Given that the instances were externally exposed, CloudSEK security researchers explored them for possible pre and post authentication vulnerabilities.

Since Appsmith does not have signup restrictions in the default installation, we focused on its post-auth functionalities, where we discovered Server Side Request Forgery (SSRF) vulnerabilities in its REST API plugin (CVE-2022-38298) and Elasticsearch (CVE-2022-38299), respectively.

SSRF vulnerabilities can be exploited to access the internal metadata of AWS/GCP. Since Appsmith offers a cloud version of their software hosted on AWS, SSRF vulnerabilities can have a high impact.

What is Appsmith

Appsmith is an open-source low-code tool that helps developers build dashboards and admin panels very quickly. It’s a platform that helps businesses build any custom internal application within hours.

How does Appsmith work?

Appsmith dashboards and panels can be set up in 4 steps:

  • Connect Datasource: Integrate with a data source such as a database or an API. Appsmith has plug-and-play support for many databases and RESTful API interface to connect with most tools.
  • Build UI: Use customizable built-in widgets to build an app layout.
  • Access Data: Connect UI to the data source by writing queries and binding the data to widgets.
  • Collaborate, Deploy, and Share: It supports version control with Git, to track changes, create rollbacks, and to collaborate using git branches. Deploy the app and share it with other users.

SSRF Vulnerability in Appsmith’s REST Client (CVSS:3.0 Score: 8.8)

One of Appsmith’s post-authentication functionalities allows users to connect to data sources using REST APIs. Appsmith’s REST Client can be used to invoke a REST Service API to create and execute queries. It can handle HTTP requests ranging from GET, POST, PUT, and PATCH, and users can also specify headers, if required, for authentication.

Appsmith REST API
Appsmith REST API

 

On replacing the API URL with a Burp Collaborator’s payload, we received an HTTP pingback immediately. However, when we tried to access the internal AWS metadata, we received a “Host not allowed” error.

Error while accessing AWS metadata
Error while accessing AWS metadata

 

Since Appsmith is an open-source tool, we reviewed the code for this functionality and found that there is blacklist-based prevention that restricts users from accessing AWS metadata.

private static final Set<String> DISALLOWED_HOSTS = Set.of(
"169.254.169.254",
"metadata.google.internal"
);

List of Disallowed Domains

final String host = uri.getHost();
if (StringUtils.isEmpty(host)
|| DISALLOWED_HOSTS.contains(host)
|| DISALLOWED_HOSTS.contains(InetAddress.getByName(host).getHostAddress())) {
errorResult.setBody(AppsmithPluginError.PLUGIN_EXECUTE_ARGUMENT_ERROR.getMessage("Host not allowed."));
errorResult.setRequest(actionExecutionRequest);
return Mono.just(errorResult);
}

Condition to validate hostname

In an attempt to bypass the SSRF blacklist protection, we implemented a redirection server that redirects the decoy request to the blacklisted server.

So, we set up a PHP redirect server, on our VPS, that redirects incoming requests to the AWS internal metadata endpoint. In this way, we were able to exploit this SSRF vulnerability. The following redirect.php file was hosted on our VPS:

<?php
$server = $_GET["server"];
if($server == "gcp") {
header("Location: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/");
}
elseif($server == "aws") {
header("Location: http://169.254.169.254/latest/meta-data/");
}
?>

Redirect.php file content

Then we made a request to the above file from the Appsmith REST API and in response, we received the metadata from the AWS/GCP cloud.

AWS security credentials of self-hosted Appsmith Cloud
AWS security credentials of self-hosted Appsmith Cloud

 

GCP metadata were fetched from the GCP compute engine
GCP metadata were fetched from the GCP compute engine

 

SSRF Vulnerability in Appsmith’s Elasticsearch (CVSS:3.0 Score: 8.2)

One of Appsmith’s post-authentication functionalities allows users to connect to Elasticsearch databases as data sources.

Adding an Elasticsearch database as a data source
Adding an Elasticsearch database as a data source

 

Once the Elasticsearch database has been connected, select the query method and enter the path. We added the following path: /latest/meta-data/iam/security-credentials/. Leave the Body blank.

Adding the path
Adding the path

 

When this query is run, it returns the temporary security credentials for your AWS role.

AWS security credentials
AWS security credentials

Impact

While a post-authentication SSRF is not new, it can have significant impact since Appsmith offers a cloud version of their software hosted on AWS. 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 that has this SSRF vulnerability.

In this case, the SSRF vulnerabilities can be exploited to the AWS metadata IP address and obtain temporary security credentials to the cloud environment of self-hosted Appsmith.

This can have large-scale impact, given that over a 1000 Appsmith instances are exposed on the internet:

Mitigation

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.

Timeline

Timeline for this disclosure process can be found below:

  • 05 Aug 2022: Disclosure of first SSRF to Appsmith
  • 05 Aug 2022: Initial response from Appsmith with acknowledgement for the vulnerability
  • 06 Aug 2022: Disclosure of second SSRF to Appsmith
  • 08 Aug 2022: Response from Appsmith with acknowledgement for the second vulnerability
  • 09 Aug 2022: Appsmith releases patch for both the vulnerabilities.
  • 10 Aug 2022: We filed for the CVE
  • 13 Sep 2022: CVE ID assigned by cve.org

References

Sparsh Kulshrestha
Sparsh is a Cyber Security Analyst at CloudSEK. This security professional hunts for points of vulnerability in client domains. He is OSCP certified and a bug bounty hunter who plays CTF for Team UnderDawg.
This is Alt
Lead Cyberintelligence Editor, CloudSEK
Total Posts: 3
Deepanjli is CloudSEK’s Lead Technical Content Writer and Editor. She is a pen wielding pedant with an insatiable appetite for books, Sudoku, and epistemology. She works on any and all content at CloudSEK, which includes blogs, reports, product documentation, and everything in between.
This is Alt
Total Posts: 1
Shashank is a Cyber Security Analyst at CloudSEK, who is also a security and automation enthusiast. He is especially passionate about coding and bug hunting.
×
Sparsh Kulshrestha
Sparsh is a Cyber Security Analyst at CloudSEK. This security professional hunts for points of vulnerability in client domains. He is OSCP certified and a bug bounty hunter who plays CTF for Team UnderDawg.
Latest Posts
  • Appsmith Patches Full-Read SSRF Vulnerabilities
  • How Threat Actors are Exploiting Android Webview