DNS Cache Poisoning - Computerphile

let's continue our conversation about dns and start talking about dns cache poisoning attacks right very cool name very cool kind of attack so dns is the system we use to link domain names like google.com to an ip address which might be changing you know day to day and that allows us to type in convenient human readable urls into bars and actually get a website back from a computer that exists which is useful dns cache poisoning is is a is essentially a flaw in dns where we can inject or an attacker could inject a malicious ip address into a name server so that it tells people to go to this ip address instead of the actual ip address right now it's less common now it was quite a big deal when when these these attacks first started appearing we already talked about dns let's talk very briefly you've got a computer here and you use some process which wants to visit a website or ping some machine you need to look up that ip address right so what you're going to do is you're going to look up your name server of choice right probably your isps one or something like that and you're going to put in a query here now this is a recursive resolver it's probably not going to know it will check its cash this is its cash right you will also have a cash by the way which for the sake of argument we don't have anything in it it will then send off to here which will go to a route and then it will go to a you know a global top level domain and so on dot dot until it gets to what we call an authoritative name server for that zone right and then it will give us an actual ip address now this will take some amount of time because there's a few hops here root and then back and then you know and so because these won't generally speaking forward on our request for us they're not that they don't work that hard for on our behalf so there's some amount of time passes when this name server reaches out for an answer where we have an opportunity to give it an answer that it wasn't expecting right which sounds way more exciting than perhaps it is one thing we talked about was this will put a query id of let's say 1000 on this query which will actually eventually go to this name server here now while it's going out with a query id we have an opportunity to send back a response with a query id of a thousand that points to a different machine so let's imagine this is my nefarious server here all right so this is sort of my skull and crossbones thing it's the worst thing i've ever seen i've got to try and fix how do you make it look like ah i i know what it is there we go that's is that bit better okay this is my very nefarious server and you know who knows what's on there like malware and stuff um but what i want to do is this has got a different ip so let's say for the sake of ease it's 10.00.9.9 and what's going to happen is this will come up here and then my attacking machine will send a stream of responses to this with query id 1000 query idea thousand and one query idea thousand and two we do a thousand and three and so on is it just chancing its arm it's just having a go yeah and we'll talk about how you choose a query id in a minute but yes basically it's just sending a sequence of query ids and with this name server it's basically saying so let's suppose this query was for google.com this query is also going to be what is google.com and we're saying google.com is 10.0.9.9 which it isn't right it's my virus server all that has to happen for this to work right is for this query id to be correct and for this to be received before the actual authoritative answer comes back from a google name server right which given that this is probably somewhere else in the world you've got a few couple hundred milliseconds maybe if i'm on a similar network to this machine that could be a big problem to this machine so how do we guess this query id well the good news was that you know back in sort of the early 2000s they just incremented a counter every time so if they sent a query id 1001 you there was there was good money it was going to be a thousand and two the next one and a thousand and three and so on so all you need to do is observe a query id and then spam it when the next one's up right so what you would do is you would send a request to this name server for some unknown domain right which points back to your name server and then see what query id it used right so you have a way of sniffing out what the query idea was and then all you would do is spam let's say 20 or 30 of the nearest numbers to it and you'd probably hit right and then it gets worse right because not only has this now received the wrong answer but it's also cached it right so you say vip for google.com is this right and also this is going to be valid for 20 days this is called the time to live now if you said that then this is gonna not bother you know asking actual google again for 20 days right and so what will happen is so someone else on this website goes someone else here goes to google.com they get a response that's this ip which is incorrect and they will get that same response while that remains in the cache right which could be for a long long time that is a huge problem if you go to a website you know you don't see the ip address right on your browser for example you just type in you know amazon credit uk nottingham.edu at uk you just you know youtube.com you type them in the domain name could be anything right there are other checks and balances like certificates that we can talk about that will prevent this from causing a huge problem but back when this was a problem that also wasn't as robust and that nefarious server is it likely that it's going to serve up something that looks close enough to the real thing i mean that depends on what the attacker wants to do right but that's one option well what you could do is you could have a fake logon prompt which looks exactly like the front page of some known social network or something like that and then you just bag the credentials rather than um you know logging them in because you can't right and then you would forward them to the actual website and they just assume that nothing happened they go that's strange and log in again and it would work the second time because they've been re-routed or you know modern day you just serve them an exploit kit right which is essentially a web server that stuffs them full of malware as quickly as possible it looks at what browser they're running what flat what you know adobe flash plugins they're running what javascript um and java runtimes are running and tries to hit them with the correct targeted payloads right which will join them into a botnet or serve them ransomware or something along these lines you don't really want this to happen to you there's a way of flushing out that cash i mean this could be done by by an administrator but they're not going to because no one's no one's looking at these caches right and then nobody kind of knows this has happened no no no unless you notice it's like an affair for this website or there's a certificate issue which is you know likely these days for for the web certainly for other services not running on you know using tls then maybe not there's really no way to know until this expires that's a huge problem now they did start to mitigate this right um because it gets a little bit more complicated you see so it was spot it was spotted that incrementing this query number was a bad idea right so what they would do instead is they would randomize it right now it's 16 bits so you've got 2 to the 16 you've got about 65 000 different query ids that you could do right now you've got your chance of hitting this is much much lower then comes along dan kaminski in about 2008 right who's a security researcher and he comes up with this idea that allows you to get around this issue so what he does is instead of requesting google.com or facebook.com he requests you know random one two three dot and then random1235.google now those are kind of similar addresses but they're new each time so this name server doesn't have them in the cache and so it performs with lookup right and it gives you another opportunity to guess like say 50 random numbers before the actual response comes back and then you can try again and then you can try again and you can do the attack in about 10 seconds now the neat thing about this because of course overriding someone's random random1234.google.com is only useful if they go to that website the interesting thing about this that was you know really quite good was that what dan also did was he attaches to the response oh and by the way i don't know for this one but the authoritative name server for google.com is actually this ip and points the actual name server at the attacker's name server right neat so so what happens basically is the name server gets a response a spammed response back but says i don't know but this one this guy might but don't trust him because he's he's he's shady so um so you have to set up your own name server but then all bets are off right once you control a name server for some zone like google or facebook or amazon or something like that you can then serve whatever ip you want for any query that comes in to that one right that's a big big problem so the final change that they made and this was about 2000 in response to this was and i should add by the way that there was a single um i believe there was a single domain name client that already did this which was dan bernstein's right all the others followed suit they don't just randomize the query id they also randomize the source port from which the query originates so you go if you remember from networking you go from an ip to an ip but you also go from a source port to a destination port right that's in tcp or udp and if you randomize that you've then got 16 2 16 possible queries and 2 to 16 ish a little bit less possible ports right then you've got somewhere you know but technically speaking about 4 billion different possible combinations some of the ports are not going to be in use so maybe hundreds of millions of different combinations this becomes much much more difficult much much slower this is not so practical right technically it's still possible right they haven't solved the issue what they've done is made it harder you know who when someone comes along with enough bandwidth to do this maybe they will be able to pull it off the long-term solution to something like this it's probably not random port numbers and things it's probably dns sec which is where you actually um authenticate things like the losing global top level domains and some of these name servers using certificates right and public key infrastructure and that means that it's much much harder to set up a spoof name server because the dns resolver will check the certificate and realize it's bogus i'm not going to use this query at all um so this actually already exists in a lot of the higher level domains some of it lots of name servers still don't support this but it is being rolled out so that's you know a good thing you only have to work out whether it's worth alerting the user if you find the key so you know you download the temporary exposure key you perform the encryption you generate the potential rpis and you compare them with the ones you've seen or if you want a more slightly comprehensible message it's saying maybe you haven't applied a function to enough arguments

Channel: Computerphile

Views: 198,567

Rating: 4.9615169 out of 5

Keywords: computers, computerphile, computer, science, Computer Science, University of Nottingham, Dr Mike Pound, Cache Poisoning, Cache Spoofing, Dan Kaminsky, DNS, Exploit, Attack

Id: 7MT1F0O3_Yw

Length: 11min 4sec (664 seconds)

Published: Wed Jul 22 2020