You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Havoc Research discovered an authenticated Server-Side Request Forgery (SSRF) via the "JSON" data source of Redash open-source version. Possibly, other connectors are affected however the JSON data source provides a lot of flexibility in terms of being able to craft HTTP requests eg., by adding headers, selecting any HTTP verb, etc., making it a very handy tool for pivoting or persistence within internal networks. The final impact depends on the specifics of backend systems in use. To read more about this vulnerability class and its impact, please refer to https://portswigger.net/web-security/ssrf
Steps to reproduce the issue
Log in to your Redash instance. Our version under test was 8.0.0+b32245 (a16f551) (by way of pulling the redash/redash Docker image).
Add a new data source of "JSON" type. Skip other fields.
Create a new query backed by this data source you have just added.
The httpbin.org service simply sends the Location header with the contents of the url parameter. 172.17.0.1 is the Docker container our Redash instance is running on and port 22 is assigned to the OpenSSH daemon on that box. Naturally, the address and port will vary depending on attackers' needs. For example, to retrieve the AWS meta-data, the payload could look like:
This check can easily be bypassed by using HTTP redirects. To fix the issue, Redash can prevent its HTTP client from following redirects. This would not mitigate DNS-rebinding when using plain text connections, however. Other known approaches to fix the issue: a) to forward network calls via an outbound proxy, or b) allow connections only to specific addresses (or address ranges) through an ACL.
This SSRF can be very potent because this particular data source also allows setting custom headers, body and query parameters, method, etc.
Other data sources present the same vulnerability however the actual impact may vary depending on the amount of information returned back to the user. Some data sources are more verbose than others.
Mark Art
🌪️ Havoc Research team
The text was updated successfully, but these errors were encountered:
The vendor requested to postpone the disclosure until June 11, 2020.
0xBADCA7
changed the title
Vulnerability report: details TBA
CVE-2020-12725 - Authenticated Server-Side Request Forgery (SSRF) in the JSON data source / internal addresses restriction bypass
Jun 11, 2020
Summary
Havoc Research discovered an authenticated Server-Side Request Forgery (SSRF) via the "JSON" data source of Redash open-source version. Possibly, other connectors are affected however the JSON data source provides a lot of flexibility in terms of being able to craft HTTP requests eg., by adding headers, selecting any HTTP verb, etc., making it a very handy tool for pivoting or persistence within internal networks. The final impact depends on the specifics of backend systems in use. To read more about this vulnerability class and its impact, please refer to https://portswigger.net/web-security/ssrf
Steps to reproduce the issue
Log in to your Redash instance. Our version under test was 8.0.0+b32245 (a16f551) (by way of pulling the redash/redash Docker image).
Add a new data source of "JSON" type. Skip other fields.
Create a new query backed by this data source you have just added.
In the query editor use this:
Then execute the statement. Depending on how you deployed Redash you could see something like:
The httpbin.org service simply sends the
Location
header with the contents of theurl
parameter. 172.17.0.1 is the Docker container our Redash instance is running on and port 22 is assigned to the OpenSSH daemon on that box. Naturally, the address and port will vary depending on attackers' needs. For example, to retrieve the AWS meta-data, the payload could look like:Remediation and root causes
It appears that there is a check that attempts to determine whether the address passed in, is a private address and then fails if so:
redash/redash/query_runner/json_ds.py
Line 38 in 9790b07
This check can easily be bypassed by using HTTP redirects. To fix the issue, Redash can prevent its HTTP client from following redirects. This would not mitigate DNS-rebinding when using plain text connections, however. Other known approaches to fix the issue: a) to forward network calls via an outbound proxy, or b) allow connections only to specific addresses (or address ranges) through an ACL.
Notes
The proposed CVSSv3 score is 9.1 (Critical) worst-case scenario (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H&version=3.1) however the actual impact will depend on the environment the application is used in, typical to this vulnerability class. Exploitation requires a) authentication b) available “JSON” data source.
This SSRF can be very potent because this particular data source also allows setting custom headers, body and query parameters, method, etc.
Other data sources present the same vulnerability however the actual impact may vary depending on the amount of information returned back to the user. Some data sources are more verbose than others.
Mark Art
🌪️ Havoc Research team
The text was updated successfully, but these errors were encountered: