BSidesMCR 2019: HTTP Desync Attacks: Smashing Into The Cell Next Door - James Kettle

good morning thanks for coming out so early I welcome to httpd simcha tax smashing into the cell next door have you ever seen a system that was so complex it just had to be vulnerable these days we will on layer upon layer of abstraction to have the faintest understanding of how a website really works a way to tell people things like HTTP is stateless and you send one request you get one of the spots but what if both of those with just kind of one in this session I'm going to share with you new tools and techniques to be syncronised complex systems smash through the barriers around HTTP requests and make websites rain exploits on their visitors during some research

last year I came up with a theory which was if you're trying to select a topic to research then the best topic is the one that makes you the most nervous and this year I thought ok I'm gonna try this theory out so I asked myself what topic am I personally really scared of trying out and the answer was hate to pee requests like I saw a presentation on this called hiding wiki's in HTTP 3 years ago at difficult and it was a thrilling presentation but it also left me kind of too nervous to tackle this topic myself one reason is that this technique was first documented way back in 2005 and yeah I never seen it

successfully used on a real web site another is that my technical understanding just wasn't there so some of the diagrams made absolutely no sense to me and also there was some kind of worrying statements on some of the slides one of them said you'll not earn bounties using this technique and another said you will certainly not be considered like a white hat if you even try and find out if a live web site is vulnerable because this technique is so dangerous another time I thought okay I'm just gonna leave this well alone but this year to test my theory out I decided to try this and see what happened and well quite a few things out I did

manage to earn some bounties and nobody's called me a black hat for it so far although one go on Twitter did call me a terrorist but I thought quite a few interesting reactions off people a few people were surprised one guy that I submitted a vulnerability to and was so amazed by this he concluded that I was faking the entire report in order to trick him into paying me a bounty and the other end of the spectrum and another guy likes the unique technique that I used on his website so much he thought he'd take that technique for himself and use it to make himself some bug bounty money in his spare time behind my back of course I had no idea

it was doing this he didn't tell me until he ran into some technical problems with the technique because there's not the easiest thing in the world and decided that the best solution to these was to pretend to be someone else and then email me asking for help with it which didn't work out very well for him but out of all of this chaos I've been able to bring you safe detection methods that will let you find this vulnerability without being called a blackhat all new methods to trigger the synchronization and exploit the results and methodology and talling to bring clarity to a topic that's been overlooked for far too long so first I'm going to talk about what makes this

attack possible how to assess if a given target is vulnerable one what to do next after that I'll take a look at how we can exploit it demonstrated using case studies on real websites starting out simple within building in complexity and ending with a live demo in which I'll also show how to use the free open source tool that I'm releasing as part of this research for that I'll talk about defense a bit and then wrap up and on some questions at the back so if you picture a website as an end user it probably looks something like this because as an end user that's all that we can directly see but behind the scenes most modern websites are routing

requests through a chain of web servers speaking to each other over HTTP over a stream based transport layer protocol like TCP or TLS and for the sake of performance these streams are heavily reused following the HTTP 1.1 to keep like protocol which simply means the HTTP requests are placed back-to-back on the street with no delimiters in between them and every server in the chain is expected to pause the hasty headers to work out where each message stops and the next one starts so we have requests from users all around the world being funneled through these tiny pools of back-end streams to the application server sitting in the back it's pretty obvious what's going to go wrong here

right what happens if as an attacker we send an ambiguous message one that gets paused differently by the front end of the back end leading to the front end in the back end thinking that this message is a different length take this blob of blue knowledge data here the front-end views this is one request so it's pulling the whole thing immediately onto the back end but when the backend reassembles it and pauses those headers for some reason if thinks this message is shorter and it thinks it ends with a final blue square so a things to orange square is the start of the next message and it's gonna wait for that phantom second message to be completed until

someone else sends a request to that website at which point there's will get concatenated onto the end of it and that is the essence of a request smuggling we can effectively apply an are between prefix to the second request to hit the server now because we can't directly see what's happening behind the front end it's quite easy to get bogged down in the technical details here I certainly did myself but throughout the presentation please remember it's really just that simple now let's zoom in and see what the data looks like on the wire so this attack is ambiguous because we're using an absolutely classic D synchronization technique which is that we've simply specified the content let's header twice

so in this example the front end server just looked at the first content antenna it's so it's forwarded all the blue data and the whole energy onto the back end the back end has looked at the second content length header it's only red in the blue data if things the G is the start of the next message so when an actual second message turns up however that user is it's going to get on a response saying something like unload method G post that's it we've successfully done a request smuggling attack the only catch is this technique is so classic that it doesn't really work on anything that's actually worth hacking these days what does work on

plenty of interesting systems is using chunked encoding chunked encoding is an alternative to using content length whereby instead of specifying the length of the message upfront the server that receives it is expected to parse the body of the message until it reaches a zero followed by an empty line so this is pretty much exactly the same as the previous technique the front end here is looking at the content length and forwarding the blue and orange data and the back end is thinks this message is chunked it's reading in the blue data and when it sees the zero followed by a new line it stops pausing that message and it once again the victim gets a message

saying something like unknown method G post now the key difference with this technique is that it actually works on plenty of real systems but what if the D synchronization happens the other way around what if it's the front end there looks at the transfer encoding header and the back end that looks at the content well we can still exploit that we just have to reformat requests slightly and we have this minor limitation which is that the malicious prefix which is shown in orange has to end with a zero followed by a a blank line but in general that's not going to cause us any problems now if you're looking at the content length in the request you might be

wondering why it's three when there's only one of this byte of data in real quest that's because every line in pretty much every message here and Twitter such are slashing that's just the normal line living and it's not showing on slides to keep them amazingly clear so why does that chunk technique work on so many systems well I think we've got to give some credit to the specification RFC 261 6 says you should if you get a message that uses transfer encoding chunked and the continent you should give priority to the chunked header and that kind of is taken to implicitly say these messages are acceptable and you shouldn't just be rejecting them outlined with the bad

with a bad request message or something like that and so all you need in the chain of web servers is one server that doesn't support chocolate encoding and that will fall back to using the content length and you'll be able to desync revise them so that take me by yourself let's do D synchronize and do proof requests smugly mom tons of systems including at the time I felt that pretty much every single website using the content delivery network I can buy back and I have no patch this last week so it in now it doesn't work on all I can buy systems but it does still work on some of them now what if you want a decent

revised a website and all the servers and the chain do support Charlotte encoding well the chances are you still can but you're just gonna have to work slightly harder what you need to do is find a way to hide the transfer encoding chunked header from one server in the chain and there's tons of ways of doing that for example some servers trim trailing whitespace in in head amazed whereas others though so some will think a message with that head of is chunked and others will think it's not chunked and fall back to using the content other systems simply grip the transfer encoding header for the word child rather than tokenizing year so they will think that that message is chance and

others won't and there's loads of techniques that you can use to D synchronize systems this is just a tiny sampling of them but every technique shown on this slide is one that I've successfully used on a real system during this research and the ones highlighted in orange are those that I came up with myself that I don't think have been documented anywhere else so at this point we understand the fundamentals of how to decent kunai service and that is a really powerful building block but if we just try and whack a server with this building block I can tell you with confidence that you wanted to hazards and complications and end up wasting loads of time so to avoid

that I've developed this methodology to guide us in a controlled manner step by step towards a successful exploit first off we need to detect Wendy synchronization is possible the obvious approach to doing this is to send the payload designed to poison the backend system right with the malicious prefix as shown in orange earlier and then send a second request and see if the response to that message looks like it's been poisoned but there's a massive flaw with this technique which is that if anyone else's request hits the server in in between your two they will get the poison response they'll have a bad day and you will find the vulnerability you'll get a false negative so we need a

better way that's actually reliable and after quite a lot of effort I've got one here so how will this how this request gets process depends heavily on the configuration or the phone end in the back end if the funnin in the back end both look at the content length the whole thing will get afforded on to the back end and responded to immediately everything's fine if the front end looks at the transfer encoding chunked header then here we'll pause the first chunk size which is three it will be in the ABC and then it will try to cause the next chunk size which is Q and the chunk slice is meant to be hexadecimal so that Q is not valid

and this message will just get rejected immediately by the front end and it will never even reach back in server but if the front-end server looks at the content length it will forward the blue data but north average queue and that means that if the backend receives that and treat this message is being chomped it will timeout while waiting for the best of the best for the next chunk size to turn up so if you send this request and you get a chomp and you get a timeout that's a strong indication that this server is probably volleyball 2d synchronization I'm just going to move this mics like [Music] what hopefully that's gonna be less noisy

can they office can everyone still hear me come right so yeah what if the server is vulnerable the other way around well we can still detect that using a similar technique but there is a minor catch which is that if the server is vulnerable the first way round then we end up accidentally poisoning it's a back-end socket with this X and we're potentially going to screw up some real user as browsers on the site so with this strategy it's important to always try the technique on the Left first to make sure that you don't do any harm but as long as you stick to that trying out these techniques on live websites it's more or less completely safe and should

definitely if they really have no repercussions or no users now this technique should be tried on every single URL other on the target website because websites often requests two different URLs two different back-end servers and you can't always visibly tell when that's happening and to help you out without obviously that will be pretty tedious I have released an open-source tool which is a burp suite extension which works with a free version proper and more animal or automatically try out that technique for you and it won't heal which route with all the try it out with all the different decent ization techniques I showed you on the previous slide as hosting later now because this technique

is reliant on a kind of inference to find their vulnerability it does get a small number of false positives but it doesn't get many and the real strength is that you'll get vastly less false negatives for example on one particular target so I found this technique found the vulnerability every single time where's with the classic technique where you send to two requests I had 800 failed attempts before it works and that's probably 800 real users that got junk responses so in an ideal world it you can probably stop there and report that but in reality most clients probably heard take that before seriously they'll want more evidence for their server it's really on the boss so

now we're gonna have to switch back to using this this technique where you send a pair a pair of requests so the first one should try poison the back end socket so that the subsequent so the second request shown ingly should get a different response code if the system is really fun please remember you'll need to try this multiple times if the website is getting traffic from me if some anybody else even if it isn't many websites don't use a pool of connections to the backend so you're spilt the soap so you're still you need to try it multiple times and yes sometimes you all need to try it a hundred times now it's really important the the blue and orange

attack and the green follow-up and not send over the same connection because if you do that you'll get false positives and the other key thing is that the end point that you sent the blue and orange requests to is really important because if the backend server doesn't light your message maybe because it's not expecting to get a post request then it may reject it and when it rejects it it will typically close the connection which will lead to the homage data being flown out and the attack failing so you ideally want to target ie to target an end point the expects to get a post request and try and preserve any see surf tokens and such like that it might

be expecting as well ok now we're finally done with a theory we can take a look our damage we can do with this so every every case study that I'm looking at here are going to look at now there's a real system that I exploited during this research they all have bug bounty programs please don't exploit magnet websites I've been forced to adapt quite a few company names unfortunately but I'd like to give a shout out to every company that actually let me name them please remember these are the guys that are actually securing up during this section I'm also going to keep a running total of the bounties earth during this research of these

bounties as usual we spend 15% on beer as a company I donate the other 50% to local charities right it'll be the easiest attack that you can do with requests smuggling is bypassing security rules that have been implemented on the front end system from sample 1 1 will no software vendor though I sadly can me they had their fun any to set up to block access to the euro / admin but by using the quest smuggling you can hide that euro from the front end system so when all I said ii sequester the server so that the back end thinks i'm accessing the route the server but i actually get access to the admin page so

far so easy now lots of front ends like to rewrite requests by adding headers into them and one head over practically every single website users some variation off is exported for which just specifies the remote users IP on a well configured system if you specify that i paint yourself directly and a normal request the front end will rewrite that header or remove entirely so you can't just use it to spoof your IP but using request smuggling we can bypass that mean writing because the front end doesn't see it as being part as being a header and thereby spoof our IP are using that technique just for itself i got an incredible $300 bounty so i'm not

suggesting you're gonna get rich quick using this particular this strategy but it is worth knowing because it does work on pretty much every single target and it also has a slightly less obvious use which is imagine you have a target where for this where the timing based technique suggests it's vulnerable but this target gets loads of traffic so you've effectively got zero chance of getting half a poison for sponsor yourself how do you prove that's really vulnerable you basically got a blind request smuggling vulnerability there well one thing you can do is send a request something like this but specify a unique hostname in the exported for heather if you get a DNS lookup for that

first header for the exporter for know then that proofs for that server is that the back end is pausing that as a separate message of their bite first so that target is really vulnerable to request smuggling okay now IP spoofing is okay but a bit boy but really interesting behavior there's going to come from application specific edits but how can you exploit an application if you don't know what the value of these headers well on most sites you can basically ask the application so here I'm targeting new New Relic you make analytical software stuff and I've smuggled a login request and I've made sure that the email address that I'm trying to login with is

the last parameter so that means when I send the next request that effect if it gets concatenated on to the email address that I'm trying to log in with and then the server comes back and says that's not a valid email address in and it reflects the email address I've supplied and that includes the whole of them as of the second request after it yet being written by the front end system so that effectively leaks all the head is that the front end system is putting on to the request and some of those headers are going to come in useful surely so on the new la the back end system was actually a reverse proxy

server ID changing the host header I could get access to different internal systems but initially they all just came back with this booming redirected to HTTPS but by looking at the previous slide we can see that they using the exported proto header and by sticking now on this moment as the quest I can tell the server yeah I'm using HTTP you can trust this and then we can actually access whatever that internal silence so I went hunting for some interesting content and found on a particular URL we get this really daunting error message it says not authorized with header and then there's a colon but then it doesn't tell me what the name of the headed I'm the author

vice with its so I thought okay maybe I could just flick back and try and leak the header and I thought okay maybe it's this xni external service header that we saw but that actually just makes the problem worse and at this point I could have used that a technique that I just showed you on loads of different new and endpoints until I found the name of this authorization header but I was getting kind of bored by this point so instead I cheated and I consulted my votes from last time I compromised develop that movie with the service gateway account ID and service gateway is New Relic admin headers so using those by accessing a specific internal API I

could access that API as every account on their system as an admin and basically take full control over everything so I got decent three thousand dollar bounty for that and they patch that with a whole fix but they said that the root cause was their f5 load balancer and I don't think that's been fixed so if you see a system running Fi definitely try this technique out now what we've seen here is with requests bugging if you're willing to put a bunch of time in you can often break directly into n into internal systems and have a good time but there's often much easier techniques focused on attacking other users for start if the application has any way of persistently

storing text later exploitation is really easy so here I'm targeting Trello which is a notetaking application and I've smuggled out a requester saying please update my public profile I'm innocent and not send a follow-up so if someone else's the quest is going to get stuck on the end of it and then that was and then that effectively could get saved on my profile so I can just browse to my profile and see the whole of this users request including their session cookies regardless of whether they're secure and HTTP only and just really easy easily a hot pie jack their account so every time I send that payload I hide out someone's account with no use of

interaction whatsoever I got a couple of bounties before that on a different site I found there was a low obvious way of storing text later but they had a support ticket system so by making the victims request land in a support ticket I couldn't log in and view that but it got emailed to me later on and I could hijack never count the only limitation with this technique is is that you can only steal data up to the first ampersand in the victims request because everything after that is interpreted as being a separate parameter so that means you sadly generally can't still log in requests and get people with usernames and passwords in in plain text the only

exception to that is if the site is doing their login using a JSON request then you can unless the victim has an ampersand in their password okay so what if you can't store data well there's a whole nother launch of attacks based on causing victims to get harmful responses so here's a he's the most conceptually simple example on this site I found some reflected exercise reflected exercises okay by itself but it's not great for mass exploitation because it requires some kind of user interaction the victim has to click a link I send them or something like that but by smuggling the request to trigger the XSS then some random other person browsing the site is

is gonna get it's the harmful response and get it footage the main advantage of this are other than in working other than it not requiring user interaction is that this technique works with traditionally on exploitable XSS vulnerability slight XSS in the user agent header and reflected XSS on posts requests to have CSF tokens and so on now while testing one target I happen to load their homepage in a web browser with the developer tools open and this message popped up which made me nervous because I recognized the IP in that message and I got this message regardless of what browser is don't load their homepage and what device in one network I connected from and I turned

out yep that was my fault what I've been doing was I was trying to trigger a redirect from the server and I'd successfully found a prefix that caused the video image but someone else's requested snuck in there and they were trying to load this image so if they received mr. Nino X myself you know that's not ideal but we've only annoyed one person by unfortunately a cache saw this happening so the cache saw someone try and get this image which is on the websites home page and then they see the redirect to my server coming as a response and then they save it and then for several days anyone that goes to the home page of that site ends

up trying to fetch this image from my server how do I get how do I get quite stressed out so if we just hijacked a javascript file there we would have taken full control over over that website we could hijack the account of anyone that went to that home page with no use it when though user interactions so on the one hand here I've shown how easy it is to do cache poisoning with with request smuggling it's so easy that you can do it by accident but on the other hand it's not really something you want to happen by accident so we need to think about how we're gonna stop this from happening or at least reduce the

chance for happening one way of doing that is to try and craft a prefix that triggers triggers a response it has anti caching headers and another is that if you've got a choice of of one ends like you will have if the front-end server it just is just part of a CDN try and target a front-end and the geographic region that's either said that's remote or sleep and is therefore not getting much traffic and thereby setting faces a chance that your winter face you'll get the poison response rather than some random other person trails on the website so that was bad but that left me wondering what happens if we embrace this possibility so here i've smuggled a

request they're saying please fetch me my API key and it is and when some well someone else's request gets concatenates don't that it will be committed with a cookie which means it'll be committed in their session and it will fetch that other users API key that user will receive an API key which is white as their own key which is Hollis but if the cache sees that happening and the user was actually trying to fetch some static resource that users can ends up being saved in the cache and then we can just go in and grab it there if this technique sounds kind of familiar that's because it's basically just a variation of the web cache deception technique the

key difference being that this technique doesn't require any user interaction you're just exploiting a random person growls on the website and you can do it over and over there's also a small catch which is that as they attack that you've got no control over where this users API key lands on the site it's just going to land on a random static file and you're gonna have to hide browser all of them in order to find it so this is the only technique in this slides where I wasn't able to find a live example of it that's because you have to log into a site to find this kind of content and by pipeline I used

to stand to find eases these samples does login but I'm pretty sure it's out there and that's roughly the location I would expect fine now on New Relic we saw that their back-end was an internal proxy but some other websites take things one step further and they decided to train the scene in Monterey CDN I saw a commode chained onto CloudFlare which is insane but I couldn't exploit that but these guys had chained a Cabaye on to Akamai I've dyed it how or why but the end result is if I change the host header in the smuggled request then I can get the response from anywhere any website any page on any website on the

at my network and the front end Akamai is happy to saver so I can basically override their home page with any content from any web site on my network now while looking at better calm itself I found it was vulnerable to request marketing and I was looking before a vulnerability to chain with it and I found this dom-based open redirects and this raised an interesting challenge because with with requests smuggling we control the URL that the backend server thinks the user is on but we don't control the oil and their victims web browser so when this get get query proper function is executed in JavaScript in the victims web browser that's running on a URL we don't control

and we can't exploit it but by finding a local redirect on the target site there's a server-side redirect I was able to take control of that oil and basically chain that with dock based a direct descendant an arbitrary location so this is a generic technique that that you can use to make any kind of dot based issue exploitable now we've seen locally though X can be useful but actually quite a few things that are normally local I mean you may direct turn into open redirects in their presence of requests modeling so on this site it's got a very common behavior that's a default behavior minute Apache and some versions of Ras which is if you

try and access a folder without a trailing slash they'll give you a helpful redirect to put the slash off and when they do that the host part of that redirect is populated the host header now this technique is really predictable it's really easy and if you can be right back the JavaScript file you can hijack and counts it if you can get that cash you can hijack everyone's account so this became my kind of go to technique for exploiting this book for exploiting this probability and I got quite a few separate bounties with it now there's a couple of points or worth mentioning if you get a 307 may direct to your arbitrary location that's wonderful

because if the browser is doing a post request let's say it's trying to log someone in by submitting their username and password and it gets the 307 B I wrecked it will reset that data to the new website so someone's browser there will be trouble and login and then the browser will just send their password to you in plain text which is fantastic also it's worth mentioning that some stick some thick thick clients like Lauren browser-based HTTP like piece whatever we'll also have this later reposted on arbitrary status codes rather than just 307 so on new hillock they had some kind of API based command line client thing and that was happy to resend its credentials even though I was

just using a 301 redirect so one of the targets this read over based cache poisoning stuff worked on was PayPal which is also so here if we try if we send a URL that look like this they would respond with a redirect containing my domain there were a couple of catches here one has the minder main one would yet concatenated with the domain for the victims house header but that was easily worked around by sticking a question mark at the end of the house error the other problem is a slightly bigger problem which is the this video effect is being done using hey EP or HTTP that means that this video act is at risk of getting blocked by

browsers mixed content protections but there were ways to bypass that in Safari and edge and I which I don't have time to talk about here but they're in my massage presentation from last year so we can exploit people with this using as long as they're using Safari or edge or IE and paper had a cache so we could persistently quite wrap this JavaScript and it was being used on PayPal's silent page unfortunately there was a catch which is PayPal's landing page also here's a CSP which one block that may direct but I wasn't even give up they're not on paper sign-in page and I noticed that the same page also loads a different debate inside an iframe and

this yo is our seed or paypal calm and it also loads my poisoned javascript file and it doesn't have CSP so that means I can hijack that iframe but I can't just leave the users password out of a parent page because at the same origin policy with docker because I'm long the same to me but my colleague go with her he's spotted paper calm slash us slash gifts which was a static page on paypal it didn't UCSB and it did import my malicious javascript file so i could first hijack the iframe on see topic our calm and then read over the iframe to paypal.com / EO / gifts we hijack it on that domain and then I was

same domain with the parent so I could just grab the users PayPal password and send it off to my website and I got nineteen thousand dollar bounty

thank you so PayPal fix this issue by making their front end which was a combined block any requests that had the word chunked and the transfer encoding henna and I was like well they they asked me like James do you think this is secure and I kind of spent my half half a day on it I was like yeah seems perfectly solid to me oh dear but then a couple of weeks later I decided to try out using my mapping to try and decent my servers and I don't really think this was gonna work on anything because a line mapping is completely valid as per the RFC and yeah it didn't work on anything directly but

what it did don't wasn't make the word chunked invisible to Akamai so they they let the request through I could once again hijack PayPal's login page and going over 20,000 thought about T which was a really generous given it was kind of my fault in the first place so at this point we've seen a whole range of different attacks you can do with requests lovely now it's time to attend the birthday boy who happens so this is a replica of a mail system it's pretty much an exact replica so this is Bugzilla this typically has lots of duty girls a zero base then bob visible to the public and so i i'm gonna take the

request the homepage I'm going to right-click on it and click Launch smuggle chrome so that option is there because of this open-source extension I've installed here we can see all the DS synchronization techniques that it's that is support so I've turned them all off apart from the ones - you're gonna work so I'm just going to say that money and now if we look a flow which is not part of this extension but is also free in the App Store we can see what my extension is actually doing behind the scenes so you can see it's using this timeout technique that I showed you at the start this message is ambiguous it's causing distinct realization and because of this

header here so if we look at the hex view it's probably too small to see but this though the ending of this vine ends with 0 a whereas every other line ends with 0 D 0 a so what that means is that the front end server thinks that this whole thing is one header and falls back to using the content length whereas the back end system sees that as being a valid line ending and thereby thinks is messages chunked which means we can do synchronize it which is why we're getting this time up so in theory if I browse to the target panel now see it stands for velocity may be fantastic so in it's attached there evidence

showing there it send this request and it ain't got a timeout so now if i were i click on this request we've got an integer option you choose smuggle it up it pops open a turbo intruder window and there you don't need to worry about any of the content here except this prefix variable so this is the evilicious prefix we'll get though they'll get applied to the next request and the tool will automatically fix up all the offsets and such life for you which is absolutely horrific to determine manually so here we're going to try and make the second request to hit the server get boy for and if i send that hopefully yeah sure enough we can see we

got a 4/4 here even though this is identical to this request and that got a 200 because of the smuggle content this score of 4 4 so you can see this mobile content just here say so that proves that this system is vulnerable to a quest modeling but we just want to prove it you can actually do some damage with it right so on Bugzilla anyone can register an account and file a bug ID on a bug they can put and and the attachment can contain HTML but this is actually safe because if you look here this site is off web davia but as soon as I upload a suspicious attachment I end up on

sandbox table VM which means that the malicious JavaScript I've got there doesn't actually work because of the same origin policy so that by itself is completely harmless but maybe we can take advantage of that behavior so I'm going to take the request to load that attachment from sandbox of him and I'm going to use that as my malicious prefix here so it's important to leave this X ignore ahead on the end because the victims the quest is gonna get stuck directly like on there like like that and if that lands on the host header then it will just break the request so now the second request to hit the server should get different my spots and as you

can see this contains some suspicious JavaScript so now in order to prove his works probably what I'm going to do is I'm going to send that payload but I'm not gonna send the fake victim follow-up requests so I'm gonna leave the back in socket who is it and that means in theory whoever else is browsing the site whatever they click it doesn't matter they're going to get my ex right back and it's gonna steal a password and I got roughly $9,000 for that one which takes the total to roughly 75 K which is the full amount earned yeah this research so far so how do you prevent this well first that you can't prevent it unless you could find

it and that makes you to be careful what tools you're using in particular make sure that your table doesn't automatically fix this content length because that will prevent you from finding half of these probabilities and also has some tools a particular curl or normalize malformed requests and once again that will make things look secure when they're not also some companies like to force pen testers to use a proxy and if you've got pen testers using a proxy in a week we'll add users normal users accessing the site directly that's terrible because those because it's a proxy walkman all their payloads the pen testers won't find the real probabilities and they and it may actually introduce extra vulnerabilities

that can only be used to hack on the pen testers so as far as preventing this go goes the ideal is to have the front end system exclusive being HT to be - - to talk to backends I believe hastily trans building defenses against this kind of stuff but that's probably not very realistic for everyone so the next best option is to have the front end realign and normalize any kind of ambiguous let's just this approach is backed up by more modern RFC's if you're forced to try it to try and prevent this by changing the backend system you should make it doesn't drop any ambiguous requests and also drop the connection so the subsequent messages aren't poison

there's loads of further bathing on this topic will be the most noteworthy thing is this year we've released a whole bunch of online me now so you can test out the old life systems that are so vulnerable to these techniques in relative safety and kind of get familiar with the vulnerability for yourself the three key things to take away are the HTTP requests smuggling is real doesn't matter how scary is it definitely exists hey CV 1.1 Ozzie is a security critical function and it should always be audited in web servers and if you're using some kind of obscure web server you should be really careful and finally detection doesn't have to be dangerous I'm gonna

take five minutes of questions now maybe just about yep cool and if you have any more after that just come and speak to me out the back or send me an email don't forget to follow me on Twitter thank you for listening

if anyone has a question put your hand up and I'll bring the mic over hi thanks James there's a sort of application this is like implementation independence so I'm assuming what your outcomes from this was enumerating which sorta servers behave in different ways this may be you were going to make public no that's a long way approach to finding these examples basically I put a bird project flower and as every single bug ballast white in it and I'm just like select all my click scan with my attention so I love the vulnerable systems I've got no idea what they want often it's quite hard to tell what the fun in system is is running no I think

they don't really advertise themselves there were some systems that I know were honorable but some of them I I can't make others like Akamai and f5 I can your best bet is just to test whatever your self whatever your setup is ok anyone else it's not then a big round of applause for change