Web Application Penetration Testing

An unknown Linux secret that turned SSRF to OS Command injection

A weird approach to escalate the Server-Side Request Forgery

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://<burp-collaborator-link>&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.

SSRF observation secureitmania