Self Notes: Web Security Academy File upload vulnerabilities Lab 5

-

(In the name of Allah, the most gracious, the most merciful)    بِسْمِ اللَّهِ الرَّحْمَنِ الرَّحِيم

In this post, we continue with exploiting the labs on file upload vulnerabilities from PortSwigger. Lab 5 is also a practitioner-level difficulty.

Task: This lab contains a vulnerable image upload function. Certain file extensions are blacklisted, but this defense can be bypassed using a classic obfuscation technique.

To solve the lab, upload a basic PHP web shell, then use it to exfiltrate the contents of the file /home/carlos/secret. Submit this secret using the button provided in the lab banner.

You can log in to your own account using the following credentials: wiener:peter

Just like the previous post, we need to upload a web shell and exfiltrate Carlos' secret, but in this case, we are dealing with a filter bypass. Let's play around with the upload request and find out:


Above we upload a normal jpeg and we got the following response:


The file was uploaded successfully, I also tested the functionality for PNG and it worked fine. Considering the experience from my previous post, let's start simple. Let's attempt to upload a PHP web shell as if there were no defenses in place.


We obtain the following response:


Only PNG and JPG are allowed, we've seen that already but let's see if that's true. First, let's see if the filter is case sensitive:



mixed case extension doesn't cause any problem and we can confirm that the filter is not normalizing our extension. Next, I systematically test the filter with various bypass methods, at each step observing the response from the server and making inferences. The following behaviors were observed:

  • We can upload normal jpg and png
  • It accepts both uppercase and lowercase without changing the case for both jpg and png.
  • It does not differentiate between jpg and png.
  • It accepts double extensions e.g pain.sql.png.
  • Normally it rejects .pngs or .spng, so most likely it's checking the whole extension.
  • It rejects double extension when the extension doesn't end with png or jpg e.g pain2.png.sql.
  • It does not seem to be black listing keywords e.g .php
  • It does not check the file contents, just the extension, it seems to be accepting a PHP script as long as it ends with JPG or PNG.
  • Single URL encoding does not raise an error, basically, URL encoded values are decoded.

It seems the extension is being validated correctly, so let's try a null-byte bypass:


And we got the following response:


It seems our null-byte was processed and it has terminated the remaining part of the extension, so we've successfully uploaded a shell. So all that is left is to exfiltrate Carlos' secret.


Response:


We obtain the token and submit it. Lab solved.


That will be all, see you in the next post.



Comments

Post a Comment

Popular posts from this blog

Before You Dive In...

-
I have always wanted to write, partly to improve my writing skills but also to document my research in reverse code engineering, software exploitation and computer programming in general, my current goal is to have at least a post a week, but since am just starting out I do not know how feasible that will be considering school and my need for quality over quantity. In the coming weeks, I will post on varying topics from software reverse engineering to exploitation and basically anything that interest me. My primary aim is just to cement my knowledge in my fields of interest by giving back to the community as I learn and hopefully along the way help someone trying to learn. A quick disclaimer though is that I am no professional at either writing or the subject on which I will be writing (at least for now),  am just trying to navigate through the vast ocean of knowledge hoping to pick one or two things along the way, so corrections, constructive criticism, and even unconstructive ones
Read more

OverTheWire: Bandit Lab

-
Image
Bismillahirrahmanirrahim (In the name of Allah the most gracious, the most merciful) So recently I and @electro decided to solve wargames and CTFs in the spirit of honing the skills and because we are preparing for something really important (another post for another day). We decided to start with the labs at overthewire  and the first on the list was Bandit Lab. Bandit Lab was a fun experience, mostly easy, except for one or two tricky levels, level 26 and level 33 in particular. This Labs weren't so difficult but required a bit of thinking outside the box, hence why am documenting them. NB : this writeup doesn't include our thought process while solving the levels Level 26 Level Description When we attempt to login to this level using the private key obtained from the previous level we get automatically logged out and since the level goal already informed us that we are dealing with a different shell, we need to figure out what it is and how to break out of it. Above is the
Read more

SSRF Notes: PortSwigger Labs Continued

-
Image
  Lab 3: SSRF with blacklist-based input filter Task :  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.  The developer has deployed two weak anti-SSRF defenses that you will need to bypass. This Lab is just like the previous ones except that we need to bypass blacklist filters. This is what a normal request to the stock check feature looks like: Passing http://localhost/admin to the stockApi parameter does not work this time. we get this response: That's the filter blocking us. It turned out 127.0.0.1, localhost, admin are all blacklisted so cannot be used. So after trying a couple things the following was able to bypass the filter: We get the following response: So to complete the Lab we just proceed to delete carlos. And that's it Lab solved.
Read more