0

I am currently trying to learn HTTP Request Smuggling vulnerability to further enhance my pen testing skills. I have watched a couple of videos on Youtube and read articles online regarding it but still have a couple of questions in mind:

  • What are the attack vectors of HTTP Req Smuggling (Where should I look)?
  • What is the main way to provide PoC to companies with high traffic? I know that HTTP Smuggling could possibly steal people's cookie, can this be used for the PoC or is this illegal?
  • Can this or other vulnerability be chained together? (e.g. self-xss & csrf)
  • I am also a bit confused regarding the CL & TE headers. From my observation, an app is vulnerable to request smuggling if both front-end and back-end interpret the CL & TE headers differently. I know how it works when its CL.TE attack, the front-end would include the body of the request based on the Content-Length and the backend would prioritize the Transfer-Encoding: Chunked header and therefore smuggling our 'additional' request body. But, how does it work on a TE.CL attack?
schroeder
  • 123,438
  • 55
  • 284
  • 319
Emanuel Beni
  • 133
  • 8

2 Answers2

1

HTTP Request Smuggling is the attack used to steal cookies and other traffic-based credentials over a vulnerable configured server.

Attack vectors of HTTP Request Smuggling: (Use the Burp Suite for the following)

  • Parameters in the request. 2 parameters, Content-Length and Transfer-Encoding matter as the surface of this attack. If they both are present in the same request, it's likely that the request is dealing with the front-end and back-end server for parsing.

  • Also, the Transfer-Encoding parameter should be in a chunked state, this means that more than 1 servers are present on the other side. If another user is requesting the server at the same time, the request will randomly choose either front or back end server for processing on either of the parameters.

HTTP Request Smuggling is rated 7~8.9 in the criticality rate and can be considered a severe vulnerability. It should be included in a POC and is legal, unless the company does not provide the consent to you for testing their systems. POCs should either be provided on platforms like HackerOne or BugCrowd, or should be mailed to the security team with a private YouTube video describing it.

HTTP Request Smuggling can be chained with other tier-1 CDN-related attacks like cookie hijacking or sometimes a SSRF in case of a misconfigured server, token entropy or vulnerable headers.

For the CL;TE headers being, when you use an additional body in the request, the front-end and back-end server parse the body accordingly to the headers passed.

For example, if the following request is passed:

Content-Length: 13
Transfer-Encoding: chunked 

0
EXPLOITS

The front-end server is accepting the Content-Length header, thus it will parse out the EXPLOITS string and send the request to the back-end server. The back-end server will parse out 0 first and since it indicates 0 bytes, it will not process the request body beneath it as the parsing will stop. So, the EXPLOITS string will be unprocessed till a new request arrives and will process it including the new request and will give out the response to the new request.

The headers can be obfuscated in a number of ways, like

Transfer-Encoding: xchunked

Transfer-Encoding
: chunked

Any obfuscation you can play with until you get the response in the repeater tab of Burp Suite resulting either a time delay or unexpected content. You can also send 2 quick succession queries to the server for confirming the vulnerability.

Hope this helps!

Ujas Dhami
  • 46
  • 5
  • Hi, thank you for your reply. For my first question, I was just wondering if there a specific endpoint where I should test this vulnerability or every endpoint is a potential for HTTP Req Smuggling? I listened to Albinowax presentation on DEFCON 27 (https://www.youtube.com/watch?v=w-eJM2Pc0KI), he mentioned that every endpoint should be tested. Is this true? And I added an additional question, would you mind taking a look at it? Thank you Ujas Dhami, much appreciated! – Emanuel Beni Sep 16 '20 at 06:05
  • Yes, endpoints should be tested accordingly like the one about TE I mentioned above. You can try any other obfuscation technique you want with those endpoints and test for the vulnerable one. :) – Ujas Dhami Sep 16 '20 at 06:38
  • Noted! I know that the severity of this vulnerability is high - critical, but testing all endpoints seems to be a lot of work. Do you have a recommendation of tools to collect endpoints in order to feed into HTTP Smuggler tools (e.g. Smuggler by defparam)? – Emanuel Beni Sep 16 '20 at 07:29
  • I'm sorry, I don't have the knowledge of associated tools for this vulnerability. If talking of me, I manually test every endpoint for the reproduction so I could figure out the response of every obfuscated header passed. – Ujas Dhami Sep 16 '20 at 07:38
  • No problem! I have another speculation needed to be confirmed. Is it true that most HTTP Smuggling attack happened on POST request? Or others are likely to be vulnerable too? And do you have public write ups or reports that I could see? Maybe HackerOne or blogging account ? – Emanuel Beni Sep 16 '20 at 07:45
  • Yes, it's true. GET requests are likely less vulnerable to Request Smuggling attacks. Also, check out this report on H1 about the attack. https://hackerone.com/reports/867952 – Ujas Dhami Sep 17 '20 at 08:21
1

Adding to the answer above, a TE;CL vuln occurs when the front-end parses TE and the backend CL. The request would have 2 complete requests parsed in TE format:

POST / HTTP/1.1
Host: vuln.website.com
Content-length: 4
Transfer-Encoding: chunked

60
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

The front-end will parse the whole request as one following chunked formatting but the backend will process it as 2 different requests:

  • 1st stopping after length 4
  • 2nd will be proceseds when a new request is received and stoppng at length 15.

Keep in mind chunked needs \r\n\r\n after the 0 so don't forget to add them into the Content-Length -> Transfer-Encoding Reference

l0bc
  • 11
  • 1