An unknown Linux secret that turned SSRF to OS Command injection.

A weird approach to escalate the Server-Side Request Forgery

Web Application Penetration Testing

Thanks for huge response to my previous write-ups. Recently I have participated in a private program and I found an OS command injection. In this write-up, want share my experience, approach and the challenge I faced during the exploitation.

What is SSRF:

SSRF stands for Server-Side Request Forgery. SSRF is a kind of web application vulnerability. Using this an attacker can do HTTP requests at server-side.In general an attacker might cause the server to make a connection back to itself. Also can interact with web based services within the organization’s infra.

What is Command Injection:

OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data.

Let’s discuss how I found the issue:

During the testing, I have observed an API endpoint generating a pdf file based on the “url” parameter value of it. Whenever I find a parameter that takes URL as the value then I directly look for the SSRF vulnerability.

https://www.example.com/api/v03/create_pdf?url=http://testsite.com&cookies=a&server=web

Look for the collaborator interaction:

I just replace the “url” parameter value with burp collaborator link to check whether the parameter validation is done at server-side. After a minute I have observed a few DNS, HTTP interactions on the Burp Collaborator.

https://www.example.com/api/v03/create_pdf?**url=http://**&cookies=a&server=web

Try inline command execution:

If the HTTP interaction is occurs on the Burp Collaborator then I go with inline OS command injection. Please observe the below image carefully.

I append the `whoami` payload to the Burp Collaborator link then request the endpoint. I have observed that the “whoami” command was executed which can be obtained at the burp collaborator dashboard.

Yahooo! I got command injection.

As the security tradition, to prove the impact of the issue I have to show the “/etc/passwd” content.

For this, I tried to execute the `cat /etc/passwd`. But at the server-side, the space character is validating and the request was rejected.

The secret trick to bypass ‘space’

Based on my past CTF experience I know some payloads to bypass the space character on the Linux environment.

cat</etc/passwd
{cat,/etc/passwd}
cat$IFS/etc/passwd

But none of the above payloads worked for my problem.

After a few trials and errors, I was able to execute the command using the below payload.

cat${IFS}/etc/passwd

References:

https://speakerdeck.com/aditya45/hunting-headers-for-ssrf

https://docs.google.com/presentation/d/1JdIjHHPsFSgLbaJcHmMkE904jmwPM4xdhEuwhy2ebvo/htmlpresent

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection

Thanks for reading. If you like this write-up please do follow me and stay tune for more hacking techniques. and view my profile to read interesting BugBounty write-ups.