Take the next step
Talk to us today
Daniel Nemeth found a Server-Side Request Forgery vulnerability via the host header that could be used to scan the internal network. Moreover, an arbitrary file read vulnerability was identified, which could allow an attacker to grep for any strings in a given file.
Authored by Dan Nemeth
Published on
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.
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.
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.
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:
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.
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:
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.
Talk to us today