- Hello and welcome to "HTTP two,
The Sequel is Always Worse".
Have you ever seen something that was so complex,
it just had to be hackable,
if only you had time to understand it.
HTTP/2 is a beautiful beast,
but it is complex and where there's complexity
people take shortcuts and things go wrong.
In this session,
I will show you how you can use new features in H two
for a range of high-impact attacks.
And also how those shed light on a type of request modeling
that has always existed, but never been noticed.
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.
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.
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.
And then, they proceeded to explain to me exactly
how you can use request modeling to exploit HTTP two.
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.
So the prospect of immediately diving into more request
smuggling work didn't exactly fill me with joy.
And instead I just put that idea on the shelf and went off
and spent a year researching web cache poisoning instead.
One year later,
I came back, tried the idea out and it really worked.
I could hack loads of interesting servers with it.
There was only one fly in the ointment
and that was Bitbucket.
Every holistic I used said that Bitbucket
should be vulnerable,
but every exploit that I tried reliably failed.
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.
And I was determined not to let it escape me a second time.
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.
I found proper evidence
that there was definitely a vulnerability.
However, what this didn't do
was actually give me something exploitable.
So once again, I had to put it on the shelf and move on.
But other than that, things went really well
until about March.
When Emil published the research that
he had been doing on the same topic as me at the same time.
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.
So I really needed something new.
And therefore, naturally I went back to Bitbucket again.
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.
An entire class of issue that was previously useless,
becoming practically exploitable.
Atlassian having to log everybody out of Jira worldwide
and contacting the computer emergency response team,
leading to further findings.
And that last scene awarding triple their maximum bounty.
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.
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.
Instead, first of all,
I am going to show you how to use HP two
for the quest modeling.
Just like what I was told in the party in Vegas.
After that,
I'll focus on the quest tunneling
and show you how to confirm and exploit
this largely overlooked type of vulnerability.
Then I will share four or five new HP to exploit primitives.
And finally, I'll cover some practical considerations,
such as common pitfalls and share some tooling
and talk about how to prevent these attacks.
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.
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.
Here, we can see an identical request
represented in H one and H two.
The first key difference is the request line.
H one has the request line
containing the method in the path.
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.
And these are used to transmit more or less
the information that you would expect in the request line.
The second difference,
is that H one is a plain text protocol.
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.
H two, meanwhile is a binary protocol
and the head are represented using key value pairs.
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.
It's not the actual bytes being sent on the wire
because they're binary and not readable.
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.
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.
H two, meanwhile has requests being composed out of frames,
and every frame has its own built in length measurement.
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.
And there's also no real potential for ambiguity
about the length of a H two message.
And that's why I thought the request smuggling against H two
was impossible.
The final key difference is to do with the way
that the postcodes handles sending multiple requests
over a single connection.
HP two does support this,
but it's not very well understood.
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.
So you're relying on the responses coming back
in the order that you sent the requests in.
H two, meanwhile decides they don't like this
because it is pretty sketchy.
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.
A stream is simply a request response pair.
So that means that the server can send the responses
back out of order.
But thanks to the stream ID,
the client can associate the responses
with the appropriate requests.
Like so.
Now that we understand HTP two,
let's see what damage we can do.
As usual, all the case studies,
presented in this section are based on real targets
that have bug bounty programs.
All these vulnerabilities were found using
an open source tool
that I am releasing as part of this presentation.
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.
This section we will be traveling quite fast.
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.
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.
And then they rewrite their requests as HTP one
in order to talk to the backend server.
This behavior,
which I have dubbed HTP two downgrading
is ridiculously common.
For example, Amazon's application load balance.
It does it by default and you cannot disable it.
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.
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.
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.
So it has to use the content length
or the transfer encoding header.
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.
We're going to start with an extremely simple case study.
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.
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.
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.
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.
I crafted that prefix,
so it would redirect them to my server.
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.
That was traced back to the Netty library
and Netflix awarded me a $20,000 bounty for it.
After that motivating start,
let's move on to something slightly more complex.
The H two OFC also says any message
containing connection specific header fields
must be treated as malformed.
But, it's a bit vague about what happens
if you fail to obey this line.
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.
For our first case study,
we will take a look at
Verizon's law enforcement portal thing.
So here, I'm sending a HP two request
containing the connection specific header field transfer
in coding chucked.
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.
And once again,
I can cause a desynchronization and append arbitrary content
to other people's requests.
And once again, I'm using this to trigger a redirect.
When I reported this, the triage has said, well,
you haven't really proven that this is dangerous.
So I decided to try and redirect some live users
and I've found very, very quickly.
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.
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.
That led to a $7,000 bounty from Verizon.
Notably This didn't get me any bounty from Amazon
or from Incapsula.
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.
On another server with the same vulnerability, I found
I could, once again, we'd have an arbitrary users.
And I was, once again told,
you need to prove that this is really dangerous.
So I, once again, started redirecting real users.
However, this time something really quite cool happened.
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.
So I hastily made some tweets to my server to make it say,
yeah, absolutely, go ahead.
Send me your password. And sure enough, they did.
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.
But unfortunately it was near impossible to redact.
So I can't share it.
This led to a $10,000 bounty from Verizon.
Right, that was the basic stuff.
Now things are going to get a bit more interesting.
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.
Firefox's start page,
at start dot Mozilla dot org was powered by the Netlify CDN.
And they forget to say,
you shouldn't put new lines in header values.
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.
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.
And basically, persistently gives me full control
over every page, on every site using Netlify.
I reported that to Mozilla and Netlify
and got two K off each,
taking the total earned so far to 41 K.
When I tried the same technique on Atlassian Jira,
something quite unexpected happened.
I expected to see two responses coming back to me,
the normal response and the poison response.
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.
How did this happen? Well, I wasn't sure initially,
but I think I eventually figured it out.
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.
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.
So my smuggled requests looked like this,
and I thought I was sending 1.5 requests.
But when he got downgraded, thanks to the front end,
sticking the new lines on the end,
I was actually sending exactly two requests.
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.
And basically the front end completely lost track
of which responses should be going to who.
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.
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.
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.
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.
Thanks to the work of the computer emergency response team.
There are more advisories from other vendors vulnerable
to the same technique on their way.
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.
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.
The first issue was they were filtering header values
but they weren't filtering header names.
Exploiting that directly is not super easy
because it results in an invalid request,
hitting the backend and the requests being rejected.
But HP two, on some servers,
lets you put colons in header names,
making exploitation actually quite straightforward.
Another issue was that even after they patch that,
they forgot to filter pseudo headers.
So we could get injection inside the request line.
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.
The final issue was that in the path, pseudo header only,
they were only rejecting the slash R slash end sequence.
So if you could send slash end by itself,
you could once again, exploit.
In summary, we've seen a range of techniques that
you can use to exploit H two downgrades
and achieve request smuggling.
Now, I'm going to take a look at something less flashy,
less obvious, but still really quite dangerous.
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.
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.
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.
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.
So it's not that bad.
The most extreme scenario is what I'm going to focus on.
This happens when the front end refuses
to ever reuse a connection to the backend server.
Some servers are just set up like this.
And also Amazon's application load balancer
has a feature called HP desync (guardian).
It doesn't work against HP two,
so it didn't prevent any of the attacks shown earlier.
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.
So I'm going to show you how to
establish that this vulnerability really exists,
how to confirm that you found it.
And also some new exploit paths that will let you
turn it into something
really quite high severity in the right conditions.
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.
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.
So the victim, the follow-up is completely unaffected.
This. As I mentioned,
is going to cause us numerous practical problems.
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.
So it's easy to mistake this for a false positive.
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.
Or maybe smuggled 2.1 requests,
if you don't want to cause a disaster that we saw on Jira.
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.
When you're looking at this response,
you can't answer the question.
Does the front end think it is sending us one response
or two and thereby, you don't know if it's vulnerable.
HP two fixes this problem for us with absolutely no effort,
on our part.
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.
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.
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.
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.
This makes life extremely difficult.
And this is the behavior that was present on Bitbucket
that drove me completely insane.
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.
It was making the whole UI lag inside Burp Repeater.
And I thought, you know what?
I actually don't particularly care about the response body.
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.
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.
And that meant that the front end read
into the next response coming from the backend.
And it proved that this target was really vulnerable
to request smuggling.
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.
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.
So, let's say,
you've just confirmed you're tunneling vulnerability
and hopefully made it non blind.
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.
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.
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.
However, if you can inject new lines and headers,
you can actually cause a different type of desynchronization
that lets you disclose these headers.
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.
So that means even if this
is a blind request smuggling vulnerability,
I am still going to see the response coming back.
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.
Instead they're desynchronized about where the headers end
and the body starts.
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.
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.
Finally, if the stars have aligned,
you might be able to use tunneling for cash poisoning.
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.
So here I have chosen a set of response headers that
just have content type, text, HTML.
And then I have chosen a different response that reflects
my user input without encoding it in the location header.
By itself, that's completely safe.
You don't need to encode user input
that is going in the location header.
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.
Now, I'm going to take you on a tour
of some HP two exploit primitives.
Each of these use a H two feature to
give you some kind of hold on the target.
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.
In H one, duplicate headers cause all kinds of problems.
But due to the way the request line is designed,
you cannot send a request with a duplicate path.
However, because H two supports pseudo headers,
you can now send a request that has two parts.
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.
Even better, H two introduces this authority pseudo header,
which basically replaces the host,
but it actually says the host is allowed as well.
And then it says that they're both optional.
This means you'll find plenty of servers
that do support both.
And if they treat them inconsistently,
it may let you perform host header attacks.
Another cool thing about H two is the scheme.
I haven't really mentioned this so far,
but it's basically just meant to be HTTP
or HTPS, just that ASCII strict.
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.
So that means it's new attack surface
and people thereby forget to sanitize it.
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.
Although there was no clear security impact with this.
It's potentially going to be more usable than other systems.
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.
So I got a server-side request forgery
using the scheme pseudo header.
Some H two servers do not let you put new lines
in H two header names.
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.
However often the backend will be fussy
and they will not like that.
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.
I did find one server that was vulnerable
to request smuggling using this technique.
And I got halfway through exploitation, had to take a break,
got distracted for a couple of weeks.
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.
So I went looking to see if
Apache had any security advisories related to this issue.
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.
I installed Apache in the correct vulnerable version
and I couldn't replicate the vulnerability.
So maybe it's there. Maybe it isn't.
But what I did find was something else.
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.
When a vulnerable version of Apache
and this works on the latest version of Apache.
It's a zero day at the time of presenting.
Hopefully,
it's been patched by the time you're watching this.
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.
Finally, a few practicalities.
Firstly, because HTTP one and two share the same port.
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.
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.
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.
And you'll miss out on loads of awesome attack surface.
Fortunately, this behavior is extremely easy to detect.
So HB request smuggler,
the open source extension I'm releasing a major update
to for this research will detect and report this.
Burp Scanner will also detect and report it
and you can test for it,
simply using curl with the following command line flags.
I found a real server that was vulnerable
to HP two powered requests smuggling
and had this hidden HP two configuration.
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.
Hopefully you'll have more success than me.
On other sites,
you'll find that although HP two
promises amazing encapsulation between your requests.
Sometimes, you'll find that one request sent down,
a connection will break.
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.
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.
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.
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.
The tooling situation in H two
is a bit of a mess because H two is a binary protocol.
You can't simply use something like Netcat or open SSL
to speak. You need to code your own client.
But coding your own client is a huge amount of work
because it's so complex.
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.
To get started with this research myself,
I coded an open-source HP two stack from scratch
and integrated that into Turbo Intruder.
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.
And it may be worth checking out HP two smuggle,
which was released by Emil as part of his research.
And I believe works by patching Golang HP two stack.
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.
Which you can use to detect
and also aid exploitation of these vulnerabilities.
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.
I highly recommend HP Request Smuggler.
That's what provided
all of the case studies in this presentation.
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.
Rewriting something from one protocol to another protocol
is not a good idea.
And I am sure plenty of other things go wrong
that I did not spot and put in this presentation.
So don't think just because you have defended against
this stuff means it's safe.
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.
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.
Do not assume that the scheme is at all trustworthy.
Why don't you just look at the actual scheme
the request is using,
if possible or use a white list, if not.
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.
Also, we're releasing a bunch of online interactive labs.
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.
Also,
it's probably worth checking out Emi Lerner's
presentation on HP two
for a different perspective on the same topic.
And I highly recommend also watching
Response Smuggling: Pwning HP 1.1 connections,
which is another Def Con presentation.
And it introduces
some new request smuggling exploitation techniques,
which should be completely compatible with HP two downgrade
based desynchronization.
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.
The three key things to take away
are that HP two breaks
critical assumptions at multiple layers of the stack.
HP two downgrades are extremely hazardous
and should be avoided
and request tunneling is a real threat.
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.
Thank you for listening.