Lab: HTTP request smuggling, basic TE.CL vulnerability

[@netletic]

Hey everyone! Check out this playlist for all my solutions to the HTTP Request Smuggling labs from PortSwigger - 👀 kzbin.info/aero/PLGb2cDlBWRUX1_7RAIjRkZDYgAB3VbUSw Here are the timestamps for this video - ⏱ 00:00 - Intro 00:42 - How you can set up Burp Repeater correctly for Request Smuggling 02:44 - Detect TE.CL vulnerability with timing techniques 03:10 - Detect what the frontend is using 04:10 - Detect what the backend is using 05:29 - Confirm the TE.CL vulnerability 08:24 - Smuggle a GPOST request 11:15 - Why Content-Length of smuggled request has to be larger than its actual Content-Length 13:29 - Official lab solution with x=1

[@N1ckdgr8]

Wow this is the most simplest explanation I have heard about request smuggling. Thank you and keep up the good work 💯

[@netletic]

thank you @NickBot09!

[@bloodmann264]

Thanks man, that was a very good explaination, thanks for the effort that you put in and be patient! Much appreciated and hope you get many subscribers!

[@netletic]

thanks @bloodmann264! that's very nice to hear ☺️ I'll patiently keep going, thanks for the kind words! 😁

[@bloodmann264]

@@netletic The patience you have to explain stuff and go slow- brick by brick to explain, is amazing, It helps people understand. Thanks for that as well. That quality is unique and I hope it takes you forward☺

[@maximtimmermans7057]

Such a crystal clear explanation, great stuff. I was here before you hit 100k subscribers!!!!!

[@netletic]

😂 thank you sir!

[@JonDoe-uy9kn]

hey man, I can't stress enough how clear this was. thank you

[@jackchan2689]

You teach very well, please keep it up

[@alexandreromao7978]

Great explanation. Totally deserve a sub, keep up the good work.

[@netletic]

Cheers @alexandreromao7978!

[@Preambyla]

Thank youuu!! Very good explanation!

[@losky666]

Great Job! Can you explain why the GPOST request don't need the Host header? Thank you!

[@netletic]

thanks @loskyli5633! You can add the Host header to the GPOST request as well, it's optional in this lab since the main purpose of the Host header is for the frontend to route it to the correct backend. Since the GPOST request was smuggled in, it was already routed to the correct backend by the frontend since it piggybacked on the POST / request above.

[@anonymousvevo8697]

Can someone explain why we always add 1 to Content-length, otherwise it won't be appended ? Thank you

[@trustedsecurity6039]

This labs doesnt work even if i follow the solution 😢

[@lazarep1]

Please do more advanced topics, great explanation :)

[@netletic]

thanks @lazarep1! yep I'm finishing up the HTTP request smuggling labs in November, and then I'll be picking another advanced topic ☺️

[@lazarep1]

I feel like web cache poisioning and deserialization are the 3 hardest, so my wish would be either one of those. Thanks for the content@@netletic

[@musawerkhan9817]

Sir the request you Smuggled, In real World scenarios do we have to do similar like that and Does the content-type, and content length in the Smuggled request is important when smuggling a request in real web app and can we Smuggled any request using TE.CL, please clarify this I am confused a little

[@gelzki]

Dude you made me burst into laughter at 0:47. LOL

[@DudeItsHim]

Hey I am facing a problem right now I am trying but I cant seem to get around it ....when I try to send those attack request as you have I am getting communication timed out error .....but normal request is getting 200 response any thing that I might be doing wrong ? Please help me

[@arjun-m3u3j]

Thanks buddy.. its realy very useful.. and can i know where it you get from that detect and check things.. i need like this for all technques..

[@depzai7781]

Can you explain why the lab solution with x=1 have Content-Length value = 15, is the number 1 count as 4 byte because it is an integer?

[@pengyang4438]

Your video explanation is so clear, thank you very much. I'd like to ask, what drawing software do you use? Can you share?

[@dominhtuan7787]

There is something i don't understand, how is the hex 0x56 processed? When I change it to other values, it reponses to "error":"Invalid request"?

[@Andrehere7]

Thanks for the explanation🔥

[@trustedsecurity6039]

i didnt commented on the first video because i forgot but in the lab i made today if i had a after the X it didnt time out and i had a response "Invalid request" but if i removed them it works. Why?

[@doya8130]

your work is excellent

[@netletic]

Thanks for the kind words @doya8130!

[@jondo-vh8tx]

indeed very nice explained. and such an amazing and scary attack to discover ha

[@tarekradwan8661]

Also can you please explain this? why was the response fine when the content-length was 5 ? The way I am thinking about it is that in case the Content-length is 5, what Is being sent Is only the prefix (the poisoned part) which Starts with GPOST and ends with 0 but in this case shouldn't the response be an error because there is nothing as a GPOST request?

[@netletic]

Hey Tarek, thanks for your question! The way I understand it is: - we send our Attack Request with a Smuggled Content-Length of 5 - which is our actual Smuggled Content-Length - the backend first responds to our request up to and including 56 with a 200 OK - in addition the backend is poisoned with our prefix from GPOST up until and including 0 - but our prefix is a complete request, with a clear and valid start and end to our request - in the case of this lab, the backend server will simply process - and execute - our GPOST request - but we don't get to see the Response to that GPOST request - and when we send our Normal Request, since the GPOST request was already processed, our Normal Request is processed normally - and gets back a 200 OK For this lab I confirmed that the backend server simply executes our Smuggled Request when we set the Smuggled Request Content-Length to the actual Content-Length by changing the GPOST into a POST request that posts a comment on one of the blog posts. When I sent that Attack Request I immediately saw that a comment "y 0" was posted, proving that the backend server executed our Smuggled Request. See an example here if you'd like to test this yourself: pastebin.com/GwAduwSb If we set our Smuggled Content-Length to a minimum of our Actual Smuggled Content-Length + 1, the backend server expects at least 1 more byte to come in, and will only process our Smuggled Request once the next request - our Normal Request - comes in. In a real scenario you want to increase the Smuggled Content-Length quite a bit so you can see as much as possible of a potential victim's request posted as a comment. E.g. that way you can steal the victim's session cookie.

[@tarekradwan8661]

@@netletic Thank you so much that's literally what I was looking for!! :D

[@tarekradwan8661]

why is It that at least 1 byte of the normal request is needed? thanks in advance

[@netletic]

Hey Tarek, I hope I answered this question in my reply to your previous comment! 😊

[@jaywandery9269]

great stuff. How common is the http request smuggling in real world apps?

[@netletic]

hey @jaywandery9269, it's definitely more niche but http request smuggling vulnerabilities are still being found today - and likely will be for as long as http/2 isn't used end-to-end. Most recently I've seen this talk at ShmooCon 2024 - kzbin.info/www/bejne/l3yzcotmZcuna9U - where these guys found new vulnerabilities and parsing inconsistencies by leveraging the HTTP Garden project (github.com/narfindustries/http-garden). We also saw the F5 RCE late last year. (www.praetorian.com/blog/refresh-compromising-f5-big-ip-with-request-smuggling-cve-2023-46747/) For general http request smuggling vulnerabilities within an application I think I'd focus on testing URI paths that I suspect might be a separate service with its own backend, where the backend might be using a backend that's more niche. In these PortSwigger labs we usually start with the homepage and go from there, but I think it's important to remember that large applications consist of different services managed by different teams that each might be using different backend systems - that's where I'd focus on today if I were trying to find request smuggling vulnerabilities.

[@jaywandery9269]

thank you@@netletic I will definetly have a look at the talk. Cheers!

[@_CryptoCat]

Very nice!

[@chuongcaoang6160]

Can u share me the slide you used in the video? thank u

[@netletic]

I'll see if I can export the slides next week and share it with you as pdf 👍

[@chuongcaoang6160]

thank u so much

[@workwithakshat-g8p]

thanks for explaination

[@pranjalruhela1103]

This lab is respectable😂

[@netletic]

Haha, thanks @pranjalruhela1103, glad you found it respectable 😂

[@shutingyang7623]

very good!

[@netletic]

thank you @shutingyang7623! ❤️

[@imperim]

thnaks

[@aaa.362]

♥

[@_ILunar]

GPOST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 15 x=1 0 why Content-Length: 15, i try CT: 11 its okey but 10 it not good, although its 10 byte

[@netletic]

hey @_ILunar - Indeed, the Content-Length of that attack request, counting CRLFs as well, is 10 bytes. But in order to ensure that at least 1 byte of our normal request, or a victim's request, is appended to the GPOST prefix that we poisoned the backend with using this attack request, we need to set the Content-Length of our Smuggled GPOST Request to "actual_content_length + 1". The lab solution uses Content-Length 15, which works fine as well. It's greater than "actual_content_length + 1", and it's less than "actual_content_length + length of content of our own normal request or a victim's normal request".

[@_ILunar]

thanks sir, i understanded