Headline

CVE-2022-41413: GitHub - renmizo/CVE-2022-41413

perfSONAR v4.x <= v4.4.5 was discovered to contain a Cross-Site Request Forgery (CSRF) which is triggered when an attacker injects crafted input into the Search function.

2 years ago

CVE

Open in Source

#csrf #vulnerability #web #mac #google #js #git #auth

Vendor: perfSONAR
Link: https://github.com/perfsonar/
Affected Versions: v4.x <= v4.4.5
Vulnerability Type: Partial Blind CSRF
Discovered by: Ryan Moore
CVE: CVE-2022-41413

Summary

A partial blind CSRF vulnerability exists in perfSONAR v4.x <= v4.4.5 within the /perfsonar-graphs/ test results page. Parameters and values can be injected/passed via the URL parameter, forcing the client to connect unknowingly in the background to other sites via transparent XMLHTTPRequests. This partial blind CSRF bypasses the built-in whitelisting function in perfSONAR.

This vulnerability was patched in perfSONAR v4.4.6.

Proof of Concept****Examples

Here are two examples of this vulnerability. For further details, review the Technical Overview section below.

Example 1:

Client browser connects to www.google.com in the background.
http://192.168.68.145/perfsonar-graphs/?source=1&dest=2&url=https://www.google.com

Example 2:

Client browser connects to arbitrary IP and port in the background, passing delete parameter to /api endpoint.
http://192.168.68.145/perfsonar-graphs/?source=8.8.8.8&dest=%26action%3Ddelete&url=http://192.168.68.113:4444/api

Technical Overview

In these examples, the graphs.json whitelist was enabled by uncommenting url_whitelist. By uncommenting these, it enables whitelisting and perfSONAR should no longer be allowed to connect to sites not found in the whitelist. But unfortunately that was not the case.

Example 1:

With the whitelist enabled and navigating to the following URL, the site returns “URL is not whitelisted” output to the screen as intended. This is to prevent you from connecting to unwanted sites.

http://192.168.68.145/perfsonar-graphs/?source=1&dest=2&url=https://www.google.com

But, if you observe via the browser developer console (or via a web proxy), there is a Jquery module that forces the client to make transparent requests in the background to whatever URL was specified.

Open your web browser, right click, Inspect, and go to Network. Now with Inspect open, navigate to the same URL and observe. In the background, you will see requests from the client to the URL that was specified, in this case www.google.com.

http://192.168.68.145/perfsonar-graphs/?source=1&dest=2&url=https://www.google.com

To compound this issue, it was discovered that URL encoded parameters could be injected into the dest parameter value and passed to the XMLHTTPRequests. This allows us to inject parameters into the GET request URI and send those as a CSRF attack to the URL of our choosing (transparently in the background).

For example purposes, here we will use the https://www.google.com/search URL and inject the q=csrf parameter and value, which tells Google what to search for. We open the following URL from our browser with Inspect open, to observe the transparent connection and search to Google.

http://192.168.68.145/perfsonar-graphs/?source=1&dest=s%3Dcsrf2&url=https://www.google.com

Fortunately Google and CORS prevents the query from working, but the site still connects to Google (or any site specified) without the user knowing, transparently in the background. Many sites have CSRF protections, but some do not. Now I will start a web server on another host and demonstrate how the CSRF attack might be used to attack other sites.

Example 2:

Here we are using another internal web server for testing. We simulate an API with a delete function. While the web server is listening on another internal machine, we open the following URL in the victim’s browser.

http://192.168.68.145/perfsonar-graphs/?source=8.8.8.8&dest=%26action%3Ddelete&url=http://192.168.68.113:4444/api

Here we observe the web server output, you can see the requests coming from the client. Notice the third line down, you can see the parameter injection worked correctly, we have sent the action=delete parameter to the /api endpoint on the designated server. (In this case fictitious for demonstration purposes).

This CSRF attack is unauthenticated by default, unrestricted, and the existing whitelist mechanism does not protect against it.

Remediation

Update perfSONAR to v4.4.6 or newer.

References