Introduction
During a recent engagement, Daniel Nemeth found multiple security vulnerabilities in perfSONAR (up to v4.4.5), such as a Server-Side Request Forgery (SSRF) and a file read vulnerability, which could be used for user enumeration. This post outlines the technical details of these vulnerabilities.
What is perfSONAR?
perfSONAR is a network measurement toolkit designed to provide federated coverage of paths and help to establish end-to-end usage expectations. There are thousands of perfSONAR instances deployed worldwide, many of which are available for open testing of key measures of network performance. https://www.perfsonar.net/gtk_whatis.html#perfsonar
perfSONAR uses pScheduler to manage the execution of network measurement tasks. To create a new task, you need to contact the pScheduler server either through the command-line interface or the pScheduler API.
Arbitrary File Read Vulnerability - CVE-2022-45213
The http test type
pScheduler supports several type of tests, including http, which could be used to measure HTTP response time.
By default, one could send the following JSON to the pScheduler API to create an http task:
{"schema":1,
"test":{
"type" : "http",
"spec":{
"url":"https://zxsecurity.co.nz",
}
},
"schedule":{}
}
This task would query https://zxsecurity.co.nz and display all kinds of details about the connection, but not the actual HTTP response, sadly.
Enumerating local users for fun
After some trials, it was discovered that the url parameter also accepted the file: scheme, and not just the standard http://. Okay, so potentially we can instruct pScheduler to read files, that is good. But what can we do with it, if the response was not displayed?
As the documentation states, the http task accepts a –parse parameter, which should contain the “string to parse for” in the HTTP response. This means that a local file could be queried and parsed its’ content!
By modifying the JSON above, it was possible to query the content of a file on the server and parse for a string in it. The following was the PoC can be used to query /etc/passwd and see if it contains root:
{"schema":1,
"test":{
"type" : "http",
"spec":{
"url":"file:/etc/passwd",
"parse":"root"
}
},
"schedule":{}
}
After the test finished, the following results came back, showing that the string root was found in /etc/passwd:
Server-Side Request Forgery (SSRF) Vulnerability - CVE-2022-45027
What is an SSRF?
A Server-Side Request Forgery vulnerability allows an attacker to force the back-end server to issue a request to an arbitrary server. Most of the time the arbitrary server would be something inside the internal network, which would be otherwise unreachable to the attacker.
Discovery of the SSRF
It was found that by modifying the Host header when creating a task, the pScheduler server reached out to our ZX Burp Collaborator server:
POST /pscheduler/tasks HTTP/1.1
Host: b1dlb7ki5ikc6dqpga66d9r0lrrif96xv.burpoutloud.zxsecurity.co.nz
...
{"schema":1,
"test":{
"type" : "rtt",
"spec":{"dest":"zxsecurity.co.nz","count":3}
},
"schedule": {}
}
The received response:
HTTP/1.1 500 INTERNAL SERVER ERROR
...
Internal problem; see system logs.
Checking our Burp Collaborator server’s access log revealed that the server accessed it:
Port-scanning the internal network for fun
After discovering the vulnerability, it was possible to port-scan the internal network of the pScheduler server based on the server’s response.
When trying to connect to a closed port, the connection refused error message was returned:
An opened port however returned a different error message, such as gnutls_handshake() failed: an unexpected TLS packet was received.
Vulnerability Disclosure Timeline:
- 04/11/2022 - Vulnerability reported to perfSONAR. They confirmed that the vulnerabilities are being addressed in the next release, 4.4.6.
- 09/11/2022 - Version 4.4.6 Released.
- 09/12/2022 - CVE-2022-45213 and CVE-2022-45027 Reserved.
- 31/01/2023 - Blog published.