Abusing SSRF on Selenium Grid
Basic Server-Side Request Forgery on Selenium Grid Framework
Recently I was reading through bug bounty write-ups as it is becoming my favorite pastime activity in the quarantine. I came across a Selenium Grid article written by Peter Jaric; he explained the lack of authentication and the hardening of security measures on a Selenium Grid framework.
Searching more online, I found out that Selenium Grid, out of the box, offers no built-in authentication and has the functionality of loading scripts that make the server vulnerable to Server-Side Request Forgery attack.
I decided to learn more about the SSRF attacks and apply it to the Selenium Grid testing instances that I built in my lab. As usual, before we get started, we will go over the key concepts before delving into the exploitation part.
💭 $_Key_Concepts:
- Selenium Grid Overview
- Server-Side Request Forgery Attack Overview
- Impact
- Exploitation Demo
- Prevention
$_ What_is_Selenium_Grid?
It is a quality assurance framework used for automating client-related tests across different environments for web applications UI and performance testing. It allows running tests on different browsers and operating systems as if the tests run on separate machines.
Selenium’s main advantage in the world of Testing and Automation is the ability to execute a huge volume of test cases across multiple nodes (machines) in a significant amount of time.
The framework has two main components a hub and nodes. There can be several nodes spun up based on the need.
The hub is the primary server to which all the other machines (nodes) subscribe to. The nodes receive all the configurations needed to run selenium sessions and perform the automated tests.
Source: Selenium Grid — Architecture and Setup by Komal Rajpal
🔥$_Server_Side_Request_Forgery:
SSRF happens when an attacker can initiate requests on behalf of the affected vulnerable server. The attack allows access to internal or external resources that might NOT be exposed or available for any users except the server.
The attack abuses the server’s trust to retrieve sensitive information such as:
- Network related information, i.e., open ports and running services
- Enumerating directories and view their contents
- List of users on the server
- Operating System information
Additionally, the attacked machine can be used as a pivoting point to other machines on the network.
There are several protocols/schemes for executing the SSRF attack depending on the application’s requirements. The most common ones are: http, ftp, and file.
$_Attack_Dynamics:
The attack can be summarized in 3 main steps:
Step #1 The attacker sends a request through the SSRF vulnerability to the affected server.
Step #2 The server gets the request and makes a SECOND call either to itself (internally) or to an external resource to fetch the requested contents.
Step#3 Once the response is back to the server, it relays it back to the attacker.
😈$_Exploitation_Time:
Now we understand the vulnerability and its impact, let’s go back to the Selenium Grid instances and apply what we have learned on the testing nodes.
📝Only nodes are susceptible to SSRF attacks; hubs are not affected.
When inspecting an application for an SSRF either through the Web developer tool or Burp Suite Proxy, you would find that requests are sent to plain URLs. That direct URL exposure is considered the loophole we can take advantage of in executing the SSRF attack.
We can replace the found URL with the localhost(127.0.0.1) address or an external resource to force the server to send a request on behalf of us (the attackers) to gain the data needed.
Let’s do that with the running nodes…
1- Create a new session by clicking on “Create Session”, choose the type of browser you want to spin up and click ok.
As you see below I have 3 Chrome sessions ready for testing.
2. As we mentioned at the beginning of the article, Selenium has built-in functionality of loading scripts from direct URLs — WebDrive JS Script. The framework expects users to load JavaScript code that communicates with the server with no required authentication. (that what makes the server vulnerable to SSRF attack).
To prove that, I clicked on Load Script and typed “http://www.google.com” and hit send. The POST request was processed through and got a 200 OK response.
I clicked on the “Take Screenshot”, and I see the sever processed my request and made an external request to the Google website.
3. Then, I moved to test with other URL schemes to see if I can retrieve internal information. The only one that worked for Selenium other than http:// was file://
📝Note: Use an extra slash to escape the forward double slashes
I was able to list the directories of the C drive on the server and get the content of some files .i.e. hosts file, service, network, and system.ini
As we see above, I was able to abuse the load script functionality to send requests to the server and get them back to me. I see this vulnerability is handy on pentesting engagements for recon purposes and lateral movement.
⚡️ $_Prevention
There should be a security mechanism of filtering or white-listing URL schemes:// on Selenium to protect the server from users making such requests to expose internal/external information.
That’s all for this tutorial. Thanks for stopping by !!!
📝$_Resources
