DEF CON 29 - James Kettle - HTTP2: The Sequel is Always Worse

00:05 - Have you ever seen something that was so complex, it just had to be hackable, if only you had time to understand it.

00:14 - HTTP/2 is a beautiful beast, but it is complex and where there’s complexity people take shortcuts and things go wrong.

00:23 - In this session, I will show you how you can use new features in H two for a range of high-impact attacks.

00:29 - And also how those shed light on a type of request modeling that has always existed, but never been noticed.

00:36 - Complexity causes trouble for me too. I first looked at the H two spec back in 2019 when I was doing research for HPD syntax, I loaded up the spec, looked at the size of the browser scroll bar and then proceeded to skim read it so fast that I didn’t even bother reading the security considerations.

00:58 - My second encounter with H two was after I presented this research at Blackout USA, an audience member asked me, did those Desync attacks work against H two? And my answer was nope, it’s completely secure.

01:13 - My third encounter was the same day. I was at a party after a few drinks and someone else asked me the same question and I gave them the same answer.

01:24 - And then, they proceeded to explain to me exactly how you can use request modeling to exploit HTTP two.

01:33 - And it is tricky to explain this next bit without coming off slightly badly but at this point in time, I just spent nine months exploiting request smuggling.

01:44 - So the prospect of immediately diving into more request smuggling work didn’t exactly fill me with joy.

01:50 - And instead I just put that idea on the shelf and went off and spent a year researching web cache poisoning instead.

01:58 - One year later, I came back, tried the idea out and it really worked.

02:02 - I could hack loads of interesting servers with it.

02:05 - There was only one fly in the ointment and that was Bitbucket.

02:11 - Every holistic I used said that Bitbucket should be vulnerable, but every exploit that I tried reliably failed.

02:21 - And, normally when I encounter something like this during research, I spend a bit of time on it and then I just abandon it and move on, or I get stuck forever, but I had previously seen this type of behavior when I was doing the original desync attack research.

02:36 - And I was determined not to let it escape me a second time.

02:42 - So, month after month, in between exploiting other systems successfully, I kept coming back to Bitbucket and eventually, I had a breakthrough thanks to something that was a complete fluke.

02:54 - I found proper evidence that there was definitely a vulnerability.

03:00 - However, what this didn’t do was actually give me something exploitable.

03:04 - So once again, I had to put it on the shelf and move on.

03:09 - But other than that, things went really well until about March.

03:14 - When Emil published the research that he had been doing on the same topic as me at the same time.

03:21 - This left me in a bit of a tricky situation because when I present some research, it has to contain some novel content, but all the novel content that I was planning on presenting had just been presented publicly by Emil instead.

03:35 - So I really needed something new. And therefore, naturally I went back to Bitbucket again.

03:41 - And this time I finally cracked it. And this led to a cascade of findings, including a new, more powerful type of desynchronization core type.

03:54 - An entire class of issue that was previously useless, becoming practically exploitable.

04:00 - Atlassian having to log everybody out of Jira worldwide and contacting the computer emergency response team, leading to further findings.

04:09 - And that last scene awarding triple their maximum bounty.

04:14 - Out of that mess, I’ve managed to extract some information that I hope you’ll find really quite useful, regardless of whether you’ve seen Emil’s presentation already or not.

04:25 - I am not going to be approaching these topics in chronological order because looking back at it, it doesn’t make sense even to me.

04:32 - Instead, first of all, I am going to show you how to use HP two for the quest modeling.

04:38 - Just like what I was told in the party in Vegas.

04:42 - After that, I’ll focus on the quest tunneling and show you how to confirm and exploit this largely overlooked type of vulnerability.

04:50 - Then I will share four or five new HP to exploit primitives.

04:54 - And finally, I’ll cover some practical considerations, such as common pitfalls and share some tooling and talk about how to prevent these attacks.

05:04 - If you’re watching this live at Def Con, then feel free to hit me up with questions on Discord or on Twitter, as you prefer.

05:13 - Although H two is complex, there’s only actually four key things that you need to understand in order to wield it, as a weapon.

05:21 - Here, we can see an identical request represented in H one and H two.

05:27 - The first key difference is the request line.

05:30 - H one has the request line containing the method in the path.

05:33 - Whereas, H two has removed this concept and replaced it with pseudo headers, which look just like normal headers but they begin with a colon.

05:43 - And these are used to transmit more or less the information that you would expect in the request line.

05:49 - The second difference, is that H one is a plain text protocol.

05:53 - So when a server pauses a request, it has to do things like look for a new line in order to know when one header ends and the next header or the body starts.

06:05 - H two, meanwhile is a binary protocol and the head are represented using key value pairs.

06:11 - So what that means is when I show you a H two request in this presentation, on a slide, what you’re seeing is an abstraction.

06:20 - It’s not the actual bytes being sent on the wire because they’re binary and not readable.

06:25 - For example, if a pseudo headers are not actually represented as header names, starting with a colon on the wire, they are just mapped to fix bytes, which are predefined in the RFC.

06:40 - The third key difference is that with H one, the length of the message has to be communicated via either the content length header or the transferring coding chunked header.

06:50 - H two, meanwhile has requests being composed out of frames, and every frame has its own built in length measurement.

07:00 - It can be thought of sort of like TCP. And what that means is that in H two, you don’t need to specify the length of the message in a header.

07:10 - And there’s also no real potential for ambiguity about the length of a H two message.

07:16 - And that’s why I thought the request smuggling against H two was impossible.

07:22 - The final key difference is to do with the way that the postcodes handles sending multiple requests over a single connection.

07:30 - HP two does support this, but it’s not very well understood.

07:35 - All you do is you open your socket, you send your requests down it, you read the response back down the socket and you send the next request straight down the same socket just concatenate it on the end and read the response back like so.

07:48 - So you’re relying on the responses coming back in the order that you sent the requests in.

07:55 - H two, meanwhile decides they don’t like this because it is pretty sketchy.

08:00 - And instead they introduce this concept of streams, every frame, therefore, every request and response has a label, which tells you it’s stream ID.

08:11 - A stream is simply a request response pair.

08:15 - So that means that the server can send the responses back out of order.

08:19 - But thanks to the stream ID, the client can associate the responses with the appropriate requests.

08:28 - Like so. Now that we understand HTP two, let’s see what damage we can do.

08:35 - As usual, all the case studies, presented in this section are based on real targets that have bug bounty programs.

08:42 - All these vulnerabilities were found using an open source tool that I am releasing as part of this presentation.

08:48 - And of any bounties earned, over half have been donated to local charities and the other half will be spent on beer, when that is, once again, permitted.

08:59 - This section we will be traveling quite fast.

09:01 - So if you’re not already familiar with request smuggling and you struggle to keep track, I suggest pausing it and checking out my prior presentation, HTP Desync attacks.

09:12 - So, why is the quest mugging possible against servers running HP two? It is because the vast majority of servers that speak H two actually only speak H two with the client.

09:26 - And then they rewrite their requests as HTP one in order to talk to the backend server.

09:33 - This behavior, which I have dubbed HTP two downgrading is ridiculously common.

09:39 - For example, Amazon’s application load balance.

09:42 - It does it by default and you cannot disable it.

09:44 - You cannot tell it to talk H two into it. What this approach does is it basically dodges all the security benefits that should be brought by using H two.

09:57 - In fact, it arguably makes things worse. When you get a classic request smuggling vulnerability, it is typically because the front end and the back end disagree about whether they should use the content length or the transfer and coding header.

10:12 - However, if the front end server is speaking H two, then there’s basically no possibility for the front end and the backend to directly agree because the front end is going to use the HP two message length, and then the back end does not have access to that data.

10:27 - So it has to use the content length or the transfer encoding header.

10:32 - If that sounds like a mess that’s because it is, if you take a server that supports HTP one, and you turn on HTP two support, you’ve just doubled the number of ways that it may be vulnerable to request smuggling.

10:45 - We’re going to start with an extremely simple case study.

10:50 - The RFC for H2 says that even though the content length headache is not required, you are still allowed to send it provided that it’s correct.

11:00 - What could possibly go wrong with that? Well, the front end used by Netflix on their main website where you watch videos and stuff forgot to verify that the content length was correct.

11:13 - So if I sent the HP two request, you can see here, then it would get translated and downgraded into an H one request that you can see on the right.

11:22 - And that thanks to the incorrect content length, will get treated as 1. 5 requests on the backend and the malicious prefixed shown in orange would get stuck on the start of the next users request.

11:35 - I crafted that prefix, so it would redirect them to my server.

11:39 - And by running that in a loop, I could hijack other people’s JavaScript imports in real time, compromise their account, steal plain text passwords and credit card details and so on.

11:50 - That was traced back to the Netty library and Netflix awarded me a $20,000 bounty for it.

11:59 - After that motivating start, let’s move on to something slightly more complex.

12:04 - The H two OFC also says any message containing connection specific header fields must be treated as malformed.

12:12 - But, it’s a bit vague about what happens if you fail to obey this line.

12:17 - So I’m going to fill in the blanks. One server that failed to obey this was Amazon’s application load balancer, and it meant I could exploit pretty much every single website using application load balancer.

12:31 - For our first case study, we will take a look at Verizon’s law enforcement portal thing.

12:37 - So here, I’m sending a HP two request containing the connection specific header field transfer in coding chucked.

12:46 - And because the server has failed to eject this, it’s been forwarded onto the backend and the backend has prioritized the transfer and coding header over the content length, which is the one that’s actually correct.

12:58 - And once again, I can cause a desynchronization and append arbitrary content to other people’s requests.

13:05 - And once again, I’m using this to trigger a redirect.

13:09 - When I reported this, the triage has said, well, you haven’t really proven that this is dangerous.

13:14 - So I decided to try and redirect some live users and I’ve found very, very quickly.

13:20 - I ended up redirecting people who were in the middle of an OAuth login float, and thereby, they ended up leaking their Oauth secret codes to me via the referer header.

13:30 - That worked on application load balance, as I mentioned, and also on everything using encapsulates web application firewall, which is supposed to make your website more secure.

13:42 - That led to a $7,000 bounty from Verizon. Notably This didn’t get me any bounty from Amazon or from Incapsula.

13:51 - There’s a bit of a disconnect between the vendors that write the vulnerable software and the end users that end up paying for it.

14:00 - On another server with the same vulnerability, I found I could, once again, we’d have an arbitrary users.

14:07 - And I was, once again told, you need to prove that this is really dangerous.

14:11 - So I, once again, started redirecting real users.

14:15 - However, this time something really quite cool happened.

14:18 - I started getting requests that landed on my server that said something along the lines of, Hey there, I’d like to have permission to send you my credentials.

14:28 - So I hastily made some tweets to my server to make it say, yeah, absolutely, go ahead.

14:33 - Send me your password. And sure enough, they did.

14:37 - I’ve got a brilliant video taken with TCP dump showing a stream of creds landing on my server in real time from their live traffic.

14:46 - But unfortunately it was near impossible to redact.

14:49 - So I can’t share it. This led to a $10,000 bounty from Verizon.

14:57 - Right, that was the basic stuff. Now things are going to get a bit more interesting.

15:02 - One cool thing about H two is that being a binary protocol, It lets you put, arbitary characters wherever you’d like, and then it relies on an extra layer of server logic to say, actually, no, you should not be putting that character in that position.

15:18 - Firefox’s start page, at start dot Mozilla dot org was powered by the Netlify CDN.

15:24 - And they forget to say, you shouldn’t put new lines in header values.

15:31 - This led to the request header injection, for mobility that I’m using here to smuggle the transfer in coding, chunked header, and cause a desynchronization.

15:41 - Here, I’ve crafted the malicious prefix to fetch data from my own site on Netlify and thanks Netlify’s cache, that harmful data would then get saved.

15:52 - And basically, persistently gives me full control over every page, on every site using Netlify.

16:00 - I reported that to Mozilla and Netlify and got two K off each, taking the total earned so far to 41 K.

16:09 - When I tried the same technique on Atlassian Jira, something quite unexpected happened.

16:15 - I expected to see two responses coming back to me, the normal response and the poison response.

16:21 - But what I actually saw and you can see here is a huge range of different responses clearly coming from different Jira deployments, intended for different people and containing a huge amount of sensitive information.

16:38 - How did this happen? Well, I wasn’t sure initially, but I think I eventually figured it out.

16:44 - The problem was I had realized that by putting new lines in headers, I could actually place my entire malicious prefix inside a header instead of putting it in the body, which meant I didn’t need to use a body and therefore didn’t need to use the post method.

17:00 - And so it might work on more targets. That was fantastic reasoning on my part, but the thing I forgot to figure out is I didn’t account for the front end needing to terminate my request by adding on a couple of new lines.

17:16 - So my smuggled requests looked like this, and I thought I was sending 1. 5 requests.

17:20 - But when he got downgraded, thanks to the front end, sticking the new lines on the end, I was actually sending exactly two requests.

17:30 - So, what happened then? Well, the first response went to me as usual and the second response went to the next user, but because it was exactly two requests, their response then went to the next user and so on.

17:44 - And basically the front end completely lost track of which responses should be going to who.

17:49 - So random responses to everybody. And thanks to the set, cookie header ended up persistently logging random users into random accounts, leading to Atlassian having to expire all sessions and log everybody out.

18:04 - So, if you find a request smuggling, vulnerability, and someone demands to see the impact of it, smuggling exactly two requests should get them the evidence that they’re looking for.

18:17 - The root cause of this was Atlassian was using the post secure virtual traffic manager front end, which shouldn’t be confused with post secure’s notorious VPN.

18:28 - We also saw that this worked on Netlify and as usual with most of my techniques, it also worked on the Imperva cloud WAF thing.

18:38 - Thanks to the work of the computer emergency response team.

18:41 - There are more advisories from other vendors vulnerable to the same technique on their way.

18:46 - If you check out the white paper on our blog, you should find that they are referenced there, by the time you are watching this.

18:54 - While Atlassian was waiting for post secure to release a proper patch to fix this vulnerability, they tried deploying a few hotfixes themselves and these issues, some of the other potential bypasses that you might find.

19:07 - The first issue was they were filtering header values but they weren’t filtering header names.

19:12 - Exploiting that directly is not super easy because it results in an invalid request, hitting the backend and the requests being rejected.

19:20 - But HP two, on some servers, lets you put colons in header names, making exploitation actually quite straightforward.

19:29 - Another issue was that even after they patch that, they forgot to filter pseudo headers.

19:35 - So we could get injection inside the request line.

19:39 - And exploiting pseudo headers is pretty much just the same as exploiting other headers, but you just need to think about what the resulting downgraded request will look like and make sure that it has a valid request line so that your request doesn’t get rejected.

19:55 - The final issue was that in the path, pseudo header only, they were only rejecting the slash R slash end sequence.

20:02 - So if you could send slash end by itself, you could once again, exploit.

20:08 - In summary, we’ve seen a range of techniques that you can use to exploit H two downgrades and achieve request smuggling.

20:15 - Now, I’m going to take a look at something less flashy, less obvious, but still really quite dangerous.

20:24 - When you find a request smuggling vulnerability, the possible attacks are heavily affected by the approach that the front end server use to decide whether to reuse an existing connection to the backend or to create a new one.

20:41 - Normally, you can exploit everybody fine because there’s no particular restrictions on this, but sometimes you’ll that when you’re trying to exploit other people, you can only poison the response to requests coming from your own IP.

20:54 - And the reason that that happens is because the front end has decided it is going to establish one connection to the backend per client IP.

21:03 - However, this is still exploitable via cash poisoning and you can still use the regular old techniques to leak internal headers and thereby use that for request tunneling.

21:11 - So it’s not that bad. The most extreme scenario is what I’m going to focus on.

21:17 - This happens when the front end refuses to ever reuse a connection to the backend server.

21:24 - Some servers are just set up like this. And also Amazon’s application load balancer has a feature called HP desync (guardian).

21:33 - It doesn’t work against HP two, so it didn’t prevent any of the attacks shown earlier.

21:38 - But against H one, if they see a suspicious request, they will try to mitigate the damage it might do by putting that on its own connection.

21:49 - So I’m going to show you how to establish that this vulnerability really exists, how to confirm that you found it.

21:55 - And also some new exploit paths that will let you turn it into something really quite high severity in the right conditions.

22:04 - Let’s visualize what’s happening here. Here, we’ve successfully smuggled 1. 5 requests to the backend and then sent a follow up request.

22:15 - But because the front end is only sending one request down each socket, the follow-up is being sent down a different socket and the poisoned socket is effectively being discarded.

22:25 - So the victim, the follow-up is completely unaffected.

22:31 - This. As I mentioned, is going to cause us numerous practical problems.

22:37 - The first key problem is that although the server will flag up up as being vulnerable, using the regular, timeout-based, request smuggling detection technique The usual confirmation technique of sending followups will, as we have just seen, fail spectacularly.

22:54 - So it’s easy to mistake this for a false positive.

22:59 - We need a different way of confirming it. Now you might think it’s quite easy just to smuggle exactly two requests and see if you get two responses.

23:09 - Or maybe smuggled 2. 1 requests, if you don’t want to cause a disaster that we saw on Jira.

23:16 - But unfortunately, this response that you can see here containing two responses, doesn’t actually show us that this target is vulnerable because this is just how HTB 1. 1 works.

23:30 - When you’re looking at this response, you can’t answer the question.

23:34 - Does the front end think it is sending us one response or two and thereby, you don’t know if it’s vulnerable.

23:41 - HP two fixes this problem for us with absolutely no effort, on our part.

23:46 - If you see HP 1. 1 headers showing up in the body of HP two response, and I promise you, if you try these techniques out, you will, then you know that this server is really vulnerable to request tunneling.

24:01 - The second problem, is that request tunneling is often blind because the front end looks the content of the header, coming from the backend in order to know how many bytes it should read off the socket and pass on to the user.

24:15 - So we can smuggle two or three requests to the backend and the backend will generate responses and it will try and send them to us.

24:24 - But the front end will only show us the first one, which is the one that we don’t have much control over and isn’t particularly interesting.

24:32 - This makes life extremely difficult. And this is the behavior that was present on Bitbucket that drove me completely insane.

24:42 - Eventually, as I was testing this end point on Bitbucket, I started to get frustrated for another reason, which was that the file being returned was so large.

24:53 - It was making the whole UI lag inside Burp Repeater.

24:58 - And I thought, you know what? I actually don’t particularly care about the response body.

25:03 - I’m only looking at the headers. So to stop the repeater from lagging, why don’t I just change the request method from post to head thereby only asking the server for the response headers.

25:15 - And that worked, the server only served up the response headers, but it included the content length header, even though there was actually no content.

25:23 - And that meant that the front end read into the next response coming from the backend.

25:29 - And it proved that this target was really vulnerable to request smuggling.

25:34 - So if you find blind request smuggling, you may be able to use the head method or potentially the options method to make it non blind.

25:43 - I think that’s a brilliant lesson on how sometimes you might not have any particular spark or insight, but actually if you just spend long enough trying to hack something, you’re basically find the answer if it exists just through brute force.

25:59 - So, let’s say, you’ve just confirmed you’re tunneling vulnerability and hopefully made it non blind.

26:05 - How can you exploit it? Well, as we’ve seen you can’t attack other users, but what you can do is you can tunnel internal headers.

26:14 - Front ends often append secret headers to incoming requests that are trusted by the backend for critical functions, such as knowing who you are logged in as.

26:25 - But to exploit these, you need to know what they’re called and the normal header leaking techniques that you can do with regular request smuggling don’t work.

26:34 - However, if you can inject new lines and headers, you can actually cause a different type of desynchronization that lets you disclose these headers.

26:44 - Take a look at what I’ve done here. I’ve crafted the HP two requests, such that both, the front end and the backend think I’m sending one request.

26:55 - So that means even if this is a blind request smuggling vulnerability, I am still going to see the response coming back.

27:02 - Where the two systems are desynchronized, is they’re not desynchronized about the length of the body, which is the normal thing they get confused about.

27:12 - Instead they’re desynchronized about where the headers end and the body starts.

27:18 - So that is meant that when the front end appended its internal headers, it actually, from the backends perspective, appended them into this S parameter, which is part of the body being used to do a search on the word quest backend on BitBucket, thereby leading to it reflecting a whole bunch of internal headers back to me.

27:38 - I also found that by hitting different parts, I could get the request routed to different backends with different internal headers, including certain secret keys.

27:49 - Finally, if the stars have aligned, you might be able to use tunneling for cash poisoning.

27:55 - Cash poisoning is one of the highest severity attacks that you can do with request smuggling and the head technique, when combined with the ability to put new lines in headers, enables a unique and extra powerful variety of it, whereby you can mix and match response, headers and bodies.

28:11 - So here I have chosen a set of response headers that just have content type, text, HTML.

28:18 - And then I have chosen a different response that reflects my user input without encoding it in the location header.

28:26 - By itself, that’s completely safe. You don’t need to encode user input that is going in the location header.

28:30 - But by combining these two things, I can poison the cash and get full control over every page on Bitbucket and triple their maximum bounty for this plus the issue mentioned earlier, taking the total earned in this research to 56 K.

28:48 - Now, I’m going to take you on a tour of some HP two exploit primitives.

28:53 - Each of these use a H two feature to give you some kind of hold on the target.

28:57 - And although, it’s a bit light on full case studies and bounties, these are all based on real behaviors that I’ve seen on real life systems.

29:07 - In H one, duplicate headers cause all kinds of problems.

29:10 - But due to the way the request line is designed, you cannot send a request with a duplicate path.

29:17 - However, because H two supports pseudo headers, you can now send a request that has two parts.

29:24 - Admittedly, the server should reject it, but plenty of them don’t and plenty of them differ about which path they give priority to, which is sure to lead to some unpleasant exploits in the future.

29:36 - Even better, H two introduces this authority pseudo header, which basically replaces the host, but it actually says the host is allowed as well.

29:45 - And then it says that they’re both optional.

29:48 - This means you’ll find plenty of servers that do support both.

29:52 - And if they treat them inconsistently, it may let you perform host header attacks.

29:58 - Another cool thing about H two is the scheme.

30:00 - I haven’t really mentioned this so far, but it’s basically just meant to be HTTP or HTPS, just that ASCII strict.

30:09 - But, the cool thing is because this is H two, we can put arbitrary binary data in there and it doesn’t have a direct equivalent in H one.

30:18 - So that means it’s new attack surface and people thereby forget to sanitize it.

30:24 - I found that on Netlify, we could put an entire URL inside the scheme and that was used to construct a URL on the backend and thereby led to them getting extremely confused.

30:35 - Although there was no clear security impact with this.

30:39 - It’s potentially going to be more usable than other systems.

30:43 - And on another target, they once again use the scheme to build a URL, but they then try to route the request to that URL.

30:49 - So I got a server-side request forgery using the scheme pseudo header.

30:58 - Some H two servers do not let you put new lines in H two header names.

31:03 - But they do let you put colons in there. So on some servers you can use this to get full requests smuggling on the backend, provided that the backend tolerates this irritating colon, which ends up getting stuck on the end of the header value.

31:20 - However often the backend will be fussy and they will not like that.

31:24 - So a better option if you find the front end has this gadget is to smuggle the host header, because the host header is expected to contain a colon and often servers just ignore everything that occurs, after the colon.

31:39 - I did find one server that was vulnerable to request smuggling using this technique.

31:45 - And I got halfway through exploitation, had to take a break, got distracted for a couple of weeks.

31:52 - And then, I found when I came back that the vulnerability had disappeared and looking at my logs, the server banner was reporting that they had patched their Apache front-end.

32:04 - So I went looking to see if Apache had any security advisories related to this issue.

32:09 - And I could not find one. So I thought, you know what? I will install a vulnerable version of Apache locally and use it for my demo.

32:17 - I installed Apache in the correct vulnerable version and I couldn’t replicate the vulnerability.

32:23 - So maybe it’s there. Maybe it isn’t. But what I did find was something else.

32:29 - I found that Apache is a mod proxy. When it’s doing HTP two downgrading, lets you put spaces in the method, pseudo header, leading to a request line injection vulnerability.

32:43 - When a vulnerable version of Apache and this works on the latest version of Apache.

32:49 - It’s a zero day at the time of presenting. Hopefully, it’s been patched by the time you’re watching this.

32:54 - When this is paired with a backend server that ignores trailing junk in the request line, you can use this to bypass block walls implemented on the front end and also to escape any folders that they might try to trap you in.

33:10 - Finally, a few practicalities. Firstly, because HTTP one and two share the same port.

33:19 - When they’re spoken over TLS, then the client is relying on the server advertising HP two support via the ALPN field in TLS handshake, in order to know that it’s allowed to speak H two, otherwise it will just default to H one.

33:36 - And there’s a whole bunch of servers out there that actually support HP two, but they forget to advertise this fact in the handshake.

33:44 - So if you use a regular route, a client like a browsable curl it won’t speak HP two to them and you’ll think they don’t support it.

33:52 - And you’ll miss out on loads of awesome attack surface.

33:56 - Fortunately, this behavior is extremely easy to detect.

34:00 - So HB request smuggler, the open source extension I’m releasing a major update to for this research will detect and report this.

34:09 - Burp Scanner will also detect and report it and you can test for it, simply using curl with the following command line flags.

34:17 - I found a real server that was vulnerable to HP two powered requests smuggling and had this hidden HP two configuration.

34:27 - The only catch there was that I could only exploit other users that were using HP two, which was nobody because they weren’t advertising.

34:35 - Hopefully you’ll have more success than me.

34:39 - On other sites, you’ll find that although HP two promises amazing encapsulation between your requests.

34:48 - Sometimes, you’ll find that one request sent down, a connection will break.

34:53 - All subsequent requests sent down that connection, even though it doesn’t actually lead to the server telling you that it’s got corrupted or closing the connection.

35:02 - So that’s something to watch out for. And another thing to be wary of is some servers treat first request out any given connection differently.

35:12 - You can manage these two bits of annoying behavior using the requests per connection configuration setting in Turbo Intruder, which I’ve updated with a full open source HP two stack that I coded myself.

35:27 - And you can also deal with it in a Repeater and I’m going to be doing more research on this because I think there’s some cool stuff even behind the scenes there.

35:36 - The tooling situation in H two is a bit of a mess because H two is a binary protocol.

35:43 - You can’t simply use something like Netcat or open SSL to speak. You need to code your own client.

35:51 - But coding your own client is a huge amount of work because it’s so complex.

35:54 - So really, you need to use a library, but actually libraries will refuse to send the kinds of malformed requests that we need to send in order to trigger these vulnerabilities.

36:05 - To get started with this research myself, I coded an open-source HP two stack from scratch and integrated that into Turbo Intruder.

36:13 - So you can use that library. Also, there is HP two stack built into Burp Suite, which is more battle tested and can also be accessed via the extended API and via turbo intruder.

36:26 - And it may be worth checking out HP two smuggle, which was released by Emil as part of his research.

36:33 - And I believe works by patching Golang HP two stack.

36:38 - As far as detection and exploitation goes. As of today, I am releasing a massive update to the HTTP request smuggler open source, both extension.

36:48 - Which you can use to detect and also aid exploitation of these vulnerabilities.

36:55 - In addition to supporting the normal timeout based technique that we have used in H one and H two, it also supports using the HEAD method that I showed you earlier in order to find request tunneling in a reliable manner that basically doesn’t have false positives, which is pretty cool.

37:14 - I highly recommend HP Request Smuggler. That’s what provided all of the case studies in this presentation.

37:22 - Defence. Well, it is tricky. If you are a network architect, then please, if possible, just use speak HP two end to end, don’t do HP downgrading.

37:33 - Rewriting something from one protocol to another protocol is not a good idea.

37:38 - And I am sure plenty of other things go wrong that I did not spot and put in this presentation.

37:43 - So don’t think just because you have defended against this stuff means it’s safe.

37:49 - If you are a server vendor, please respect the RFC and enforce the HP 1. 1 limitations about what characters you can put in what positions.

37:58 - And as a developer, I think probably you just need to drop assumptions that used to be safe to make in HP 1. 1, like don’t assume that the request method doesn’t have spaces in it.

38:11 - Do not assume that the scheme is at all trustworthy.

38:15 - Why don’t you just look at the actual scheme the request is using, if possible or use a white list, if not.

38:23 - There’s loads of further reading available, I recommend checking out the white paper I’ve published, which accompanies this research and will contain slightly more up to date information on certain topics.

38:34 - Also, we’re releasing a bunch of online interactive labs.

38:37 - So as part of our web security academy, which is completely free, you can try applying these techniques to real systems that we spit up for you on demand, just so that you can hack them and gain some practical experience before targeting real world systems.

38:54 - Also, it’s probably worth checking out Emi Lerner’s presentation on HP two for a different perspective on the same topic.

39:03 - And I highly recommend also watching Response Smuggling: Pwning HP 1. 1 connections, which is another Def Con presentation.

39:11 - And it introduces some new request smuggling exploitation techniques, which should be completely compatible with HP two downgrade based desynchronization.

39:24 - As far as primary sources go, this is mostly based on my prior work, HP Desync attacks, but if you want a significantly better explanation of response queue poisoning, check out Defparam’s presentation on YouTube.

39:38 - The three key things to take away are that HP two breaks critical assumptions at multiple layers of the stack.

39:45 - HP two downgrades are extremely hazardous and should be avoided and request tunneling is a real threat.

39:53 - If you have any questions, hit me up on discord or Twitter, or chuck me an email. Don’t forget to follow me on Twitter.

40:00 - Thank you for listening. .