Focuses on solving all apprentice levels of SSRF, OS command injection, and Path traversal

In this article, i'm continuing to solve Portswigger Academy Labs once again to do cyber attacks on a website sample, to deepen our knowledge and understanding of how cyber attacks occur and how to apply them and exploit target's server.

Follow me to join in my journey to understand the cyber attack we're about to discuss, what is it, what are our goals to attack and how are we able to carry the plan and bring out successful attacks.

We'll be using Burp Suite from here and out, so make sure you have install and download everything you need.

If you're uncertain of how to do it, click here for a full guide installation:

https://medium.com/@relzy/burp-suite-instalation-and-configuration-setup-tutorial-a54ace758372c

What is SSRF?

SSRF (Server-Side Request Forgery) happens when an attacker tricks the server into making a request to another location that the attacker cannot access directly.

The attacker uses the server as a proxy.

Simple Scenario

A website allows users to fetch an image from a URL:

https://example.com/fetch?url=http://image.com/pic.jpg

Attacker changes it to:

https://example.com/fetch?url=http://localhost/admin

The server requests its own internal admin page and returns the result to the attacker.

Here's an analogy.

You are not allowed to enter a restricted room.

So you ask a staff member:

"Can you go inside and bring me what's there?"

They do it for you without realizing.

Basic SSRF against the local server

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

Enter the lab

Visit a product, click "Check stock", intercept the request in Burp Suite, and send it to Burp Repeater.

None

Find the POST request and send it to repeater.

None

There's a parameter called stockAPI and it's an URL.

Anytime you see an URL in the application, you definitely want to test for SSRF.

The next thing we should take notes is to check if there's an application running on the localhost. Generally this type of request shouldn't be accepted, but let's just try it out.

#Change the stockAPI to this

stockApi=http://localhost

And the result would look like this,

None

Click on render

None

As you can see, there's an "Admin panel" which we didn't have before.

Lets search for "Admin" in the Raw Response.

None
the path is /Admin

So we're going to add that path to our request, and send it.

None

And render it

None
So the admin interface allows us to delete usernames.

Go back to raw and search for "carlos"

None

Add that path to our request, and send it.

None

Looking from the response, we've successfully deleted the username and so, we've solved the lab!

None

Congrats ^^

Basic SSRF against another back-end system

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.

Enter the lab

Visit a product, click Check stock.

None

Intercept the request in Burp Suite, and send it to Burp Repeater.

None

In the stockAPI section, you can decode the url with Shift+CTRL+U

None
from this
None
to this

Now we know that this url is calling the specific domain.

Let's see if we could access the main page of this interface.

Remove the stock path and etc, leaving only the ip address and the port, and hit send.

None

Looking at the response, it says it's missing parameter.

We're going to check if there's any other application running on this ip range. In order to enumerate all 255 ip addresses, we're gonna send this to Burp Intruder.

None

Click on the intruder. Highlight the parameter that we'll use in order to conduct our attack.

Click on "Add" and click the "Payloads" tab

None

Click on Payload type: Numbers and number range from 1 to 255, and we're going to stop one at a time.

None

Then start the attack.

None

Let the time pass and the intruder would give us a different status code.

None

We've found an anomaly, it says here it has 404 status code on the ip add 190, different from the others 400 & 500.

It says not found, it means that this server is running but the page which is just the general parent page doesn't exist.

So copy that stockAPI url and get back to Repeater, and send it.

None

Let's see if an admin page exist over here. Just add the admin path over the request. Then click send.

None

Click render option

None

We see that the admin panel is available and we have the ability to delete users.

Search for "carlos" username in the raw code in the response, and copy the path and add it to our request stockAPI.

None

Click send and it should shows this:

None

Go to the lab to check it.

None

There we go, we've finished the lab!

What is it OS Command Injection?

This happens when user input is executed as a system command on the server.

The attacker injects commands into the system.

Simple Scenario

A website runs this command:

ping <user_input>

Attacker enters:

8.8.8.8 && cat /etc/passwd

The server runs both commands and reveals system file content.

Here's an analogy.

You ask a worker to water plants.

But you secretly add:

"After watering, open the safe and show me what's inside."

They follow all instructions without checking.

OS command injection, simple case

This lab contains an OS command injection vulnerability in the product stock checker.

The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response.

To solve the lab, execute the whoami command to determine the name of the current user.

Enter the lab

Visit a product, click Check stock.

None

Use Burp Suite to intercept and modify a request that checks the stock level.

None

Send it to Repeater.

None

We could see that it shows the parameters:

productId=1&storeId=1

Because of the description of the lab, we know that this is vulnerable to command injection, if you're testing a real application, you would test each parameter for potential injection vulnerabilities.

To check if they're vulnerable, we need to test it with adding the & character which allows us to chain commands together in bash, and input the "whoami" command and add a hash character after it which comments out the rest of the command.

It would look like this:

productId=1 & whoami #&storeId=1

After that, do CTRL+U to encode the url like this.

None
highlight it like this, do CTRL+U
None
it would look like this

Do the same for #.

None
from this
None
to this.

And then send it.

None

And there you go, we've get the value of the user that is running this system.

None

Congrats, you solved the lab!

Note:

It's the nature of command injection vulnerabilities, it means you have gained remote code execution (RCE) so you can run any command you want.

What is Path Traversal?

Path traversal allows an attacker to access files outside the intended directory.

The attacker "travels" through folders to reach sensitive files.

Simple Scenario

A website shows files like:

https://example.com/view?file=report.txt

Attacker changes it to:

https://example.com/view?file=../../etc/passwd

The server opens a system file instead.

Here's an analogy.

You are allowed to open a drawer for documents.

But you move outside the drawer, walk to another room, and open a locked cabinet.

File path traversal, simple case

This lab contains a path traversal vulnerability in the display of product images.

To solve the lab, retrieve the contents of the /etc/passwd file.

Enter the lab

None

Use Burp Suite to intercept and modify a request that fetches a product image.

None

Send this to repeater, and click send.

None

It displays the content of the image that is in this JPEG file.

In this scenario, we should be able to view the contents of other files on the server. We're going to try and access a word readable file. So it's accessible by anyone that has access to the server, and that file is going to be the passwd file.

We're going to go to the root directory by adding "../" as many as we can. Like this

GET /image?filename=../../../../etc/passwd HTTP/2

It says this

None

It dumps the content of the /etc/passwd file,

Go back to the lab to check the result.

None

Congrats! you've solved the lab.

That's all for SSRF, OS command injection, and Path traversal material for apprentice level, thank you so much for reading and i hope this is helpfull.

See you guys in the next article!

Source lab: https://portswigger.net/