Self Notes: Web Security Academy HTTP Request Smuggling Lab 3

-
Lab 3 can be found here.

For this Lab, a Front-end and Back-end servers that handle duplicate HTTP Request headers differently are provided, the task is to find a way to obfuscate the Transfer-Encoding Header to achieve HTTP request smuggling. The provided endpoint accepts POST request for posting comments as follows:

comment endpoint

Since both servers accept Transfer-Encoding header the above request chunk encoded becomes:


Sending the request to the server, the response was:


a confirmation redirect is obtained, meaning the server is happy with us, so far so good. Since the essence of the Lab is to play with how the server handles duplicate headers, we attempt this:


the server still isn't complaining:


well, that's because at this point both the Content-Length (CL) and Transfer-Encoding (TE)  Header values are valid, therefore even if one is using the CL and the other is using the TE we don't notice any discrepancy. Let's assume that the Front-end Server processes the first Header and the Back-end processes the second, this will mean that the Front-end uses the Content-Length, since Transfer-Encoding: x isn't valid, while the Back-end uses Transfer-Encoding since the Header is valid and if this hypothesis is correct, then we have successfully induced a CL-TE smuggling vulnerability for a TE-TE Front-end Back-end server pair, to test our hypothesis let borrow a payload from the HTTP Request Smuggling Captain, James Kettle, his blog post contains everything you need to get started with Request Smuggling. Modified Request with payload below:


If our CL-TE hypothesis is correct, then sending the request for the first time will cause the Back-end socket to be poisoned this is because of the 'G' appended to the end of the request body since the Back-end server will stop processing the request when it encounters the '0' character, leaving 'G' for the next request. The server's response was:


which makes sense, since it has completely ignored the 'G' at the end of the request body, but what happens when we send the same request again? this:


well, this proves our hypothesis and solves Lab 3, the 'G' got appended to start of the next request leading to an unrecognized method 'GPOST'. We have successfully desynchronized the Back-end Front-End server pair and smuggled the unauthorized request method. The intended or provided solution for this Lab on Web Security Academy is:



Reference

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 o...
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