BSides Toronto 2019 Anuj Mistry

all right so good present about the front-end web servers that's the smoking crater a quick 20 seconds about me my name is on which mystery I'm a senior consultant with CGI for offensive security and that's my twitter handle that's big number what does that number show Irish any guesses number of attacks no it's 1.7 billion I'll give some hint that's right those are the number of web servers in the world 1.7 billion web servers in the world seven billion population so imagine how many websites are there and to each user this is what we see and user and a web server but in practice that's not the case they're usually an intermediate server by intermediate server it could

be a cache it could be a proxy query reverse proxy a load balancer any of those actually be enabled intermediaries this usually been in the front end and the back end server just for performance reasons they do not terminate the HTTP connection after every request it's an active HTTP connection the same connection that's being reused now when the same connection is being reused one challenge is to identify the boundaries of messages how do we differentiate the length of each message differentiate one message from the other this is where we get an opportunity to attack the backend server whenever the front-end server and the backend server do not agree in terms of the implementation for the message length

when do we consider a message to be complete when the connection is close by the server some of the messages have an implied content length the two or three or four messages they have zero content length so the front and the back and service they agree that yes this is the message length so they can differentiate between different messages a third method is the content length header in the example content length is five so ABC and then crlf so twelve five bytes is the content length and another header called chunked encoding in anyway we have transfer encoding header the former is a number the length of the data and then zero zero to indicate that that's the end of

the message it could be multiple chunks in our first chunk is just three bytes second chunk is five bytes and then zero which shows that the that's the end of message so like I said earlier when we were different and the back-end server they do not agree on the same means to determine the end of message we have an opportunity suppose the user sends a malformed request which travels to different end which goes through different end server server but then it gets attached to the different requests at the back end this is what is request modeling it's all about I'll show you how to do it to an example suppose I have setup with SunRun proxy server it's

pretty old setup right now son one web server the way they are implemented is whenever there are two content length headers in the request the son one proxy server uses the second header it considers the second header as the length of the message and that's why it discriminates the boundary of the message the web server uses the first header that's mentioned so what happens if we have to contaminant headers in our request here if you notice there's a content let header say zero another one say is 53 let's see how this message flows into independent server which is the sanguine proxy and then into the web server the front front end server the proxy which

considers the second content length header we'll think this is the end of message which means that's request 1 and the remaining is request to when this message flows on to the HTTP connection which is kept alive on to the back-end server now the back-end server looks at content length header 1 this one and if it says length is 0 so this URL F this is where the request ends so this is the view of the back-end server in terms of the messages now when you see the difference between how the front-end server we used the messages and the backend server use the messages it gives us this message from get to foo that's being smuggled into the backend server a

give moment to process this because this highlighted request is being swung go to the backend server be the different in server knowing it nor the implications of it typically we can we encounter for different types of setups or environments some where both of them look at content with headers but different ones that's called the CL dot CL as we saw in the first example here the second kind of setup is very different and server looks at the content length header but the backend server looks at the transfer encoding header the third kind of setup is the reverse where the front end server looks at the transfer encoding header and the back and throw looks at the content

length so here again there's a mismatch in verdict how they are implemented in terms of marking the boundaries of messages and the fourth one is when there are multiple transfer encoding headers but then different tender back and server they look at different different ones so these are four types of vulnerable setups that will will encounter in the wild using using these four setups or this technique we can perform an HTTP request modeling as we saw in the first example right we smuggled a request from the front end server to the back end server without the fronting server recognizing it we can even perform a stupid request mod response smuggling we can split the request and we can split the response so

these are four different types of attack vectors using the HTTP desync methodology we saw the first one already in an example and I can I'll show you an example of the last one that is HTTP response splitting how do we force the back-end server to spit out two different responses after sending just one request simple example friend and server sends a message to the back-end server and we make the back-end server send out two different responses let's see how this can be exploited this can be exploited when any application embeds user data into a response header and we see an example how this can be accomplished suppose I have a site where normal requests to the index dot PHP

page says this and the response this is the user request and it's embedded into a header in the response this is gold for for ethical hackers right here the user input is the country code which is Canada what if as an attacker I change the user input to add some more headers and some more headers so for the request this entire is a request we are sending one request to the back-end server what sending practically I need to URL encoded so this how it looks the request is a single request with this malformed data being Center sent to the back-end server the backend server will spit out two different responses one for the first first that we saw and second one would

be the tornado key request so so one request going out two responses coming back this one this how it looks so the user is sending just one request there are two responses being sent back the front-end server will cube this response the response 1b and it will reply that that to the second request now how this can be exploited is when a user is so this is user 1 and suppose a different user is going to use the application so different users of the application we can as an attacker we can force a response to the different user to this technique I'm just putting it all into one picture so that we know how it works

just one request two different responses coming back the the impact you know there's a validity of which you can exploit it we'll look at the impact one impactive web cache poisoning so most different end servers also implement caching and we can we can implement we can have a result of a web cache poisoning which means on facebook for example on login page if we if you poison the cache to respond with a logout any of the users which try to go to the login page they'll be redirected to the logout page automatically this is a temporary attack because then whenever the cache is purged and then it's build new the application works normally another kind of attack is the response

hijacking so we can hijack the response from a back-end server which enables us to to steal a lot of data any additional headers from the front-end server that are being added any session cookies are being added by the front-end server we can we can basically ask the backend server to spit it out to us it's possible deface a website which which has business impact in terms of the commercial and the in the image it's possible to bypass any of the security controls on the front end side so it's it's possible to bypass any web application firewalls next-gen firewall Network firewalls PS IDs systems using this technique and it's possible to steal credentials just like we said we could make the backend

server spit out additional responses so we can make the backpack answer as paid out credentials of other users to us so interesting we can see that all these different types of possible attacks using this technique are very severe they're very critical this is a very small list of the systems they're vulnerable most of them these are actually all of these are now patched but this is only a very small number recent researchers have seen that any new field that they go in any new target they attack they do have these kind of nobodies seeing the money but is what are some of those steps the blue side if I can take in in order to remediate this one maybe it's

usually multi-layer the first one is that application layer where I know there's a web app the back-end server they have to sanitize everything in user input special characters crlf everything has to be sanitized so very strict input stereo decision has to be implemented about using single session until my strip yacht use Kerberos instead which is more like a tickling base not at the intermediary's level which is most of the front end servers the load balancers cache servers all those windows they need to drop or fix by data when there's bad data coming in from a user either fix it or drop it they need to be very strict in terms of implementing the RFC's specifically to 6-1-6 any

deviation from RFC and then the front-end back-end server they will have disagreements in terms of the length of the message and that's that's called users should be two towards the backend which has a much stronger implementation and and also disallowed trace methods if possible the the frameworks which are used just to not embed any bad data into the responses that's how you damn idiot on the framework level just a quick recap so it should be dissing vulnerabilities are critical and they're widespread there for different kinds of setups or environments that that we usually encounter the attacks that are possible are four key kinds of attacks and remediation is always multi-layered there's no just one fix it has to be at

each layer at the front-end server the application layer the the framework layer that's how that's a way to remediate such attacks one of a huge grade goes to Amit and James I'm ed from he's the one who would generally did a lot of research back in 2005 and then after that it was kind of her garden and James Carroll from from poor trigger recently did a very good research he's developed a methodology to detect confirm and then exploit these molarities and even added a small add-on on to Bob's way to test for desync attacks so shout out to Amit and James thank you so much oh I'll live thank you while taking questions I'll leave this

on just for recap yeah any questions

thank you very much and a token of our appreciation thank you very much [Applause]