 This talk was originally going to be at one but I'm happy we were happy to bump this talk up because this is still one of the quintessential topics in in security and without much ado my pleasure to introduce you to Travis Palmer and Brian Thomas. Thank you folks so as you said this is a quintessential topic in security we are actually not trying to win any awards for the length of the name of our talk but we're pretty sure we might have actually won and we're going to give you guys not just an update on kind of the current state of what DNS is but also go a bit further and actually give you guys a presentation on an attack that is doable very plausibly against some major resolvers from my understanding Google and some other folks have not really gotten back to us with a firm word of yeah totally we got this yet so very plausibly you could turn around and actually use this if you're very quick about it this is a nice stick to poke people to get actually moving so without further ado this is how you become the one in 34 million so I'm going to go through basically introduce ourselves then we're going to go right into we have to give some background on DNS a lot of people here are new to DEF CON and relatively new to the security industry I can't talk about the things that are different if I can't talk about the stuff that's originally we're going to talk about fragmentation attacks there's a bit of a history for that and then I'm going to talk trust me it's not it's a very important tangent into IPID inference and some of the more recent stuff that has come out of University of New Mexico and then we'll go right into the attack I'm not actually affiliated with the folks in University of New Mexico but they are not very helpful and where their white paper was more than enough to get this attack rolled together and then Brian who is actually a proper expert will be talking about mitigations so hello I'm Travis Travco Palmer I'm a security research engineer for Cisco Systems I am an OSCP and OSCE if that means anything to you and as I kind of implied yeah I'm not actually an expert on DNS or DNS sec I don't do this on a day-to-day basis Brian I don't think would want to call himself an expert but he's close enough and he is a principal engineer for Cisco System and has had his a lot of free time to work on FreeSB and OpenBSD so what did we actually do this is what we found was a more consistent way to poison the cache of DNS resolvers without using a man in the middle and using an existing attack that existed using fragmentation on DNS we took that attack reduced it from hundreds of iterations thousands of iterations to very plausibly one on IPv4 and for IPv6 reduced it from millions of iterations to very plausibly only one and also because of that we're basically bypassing all the current recommendations so even if you're doing everything right as people are telling you yeah we can probably still screw your domain so yes we did disclose responsibly I am my particular team was discovered this attack during a focused pentest engagement it was a couple of weeks but it's a little bit of an unusual pentest engagement to say the least and our team disclosed off to Cisco umbrella and umbrella has been disclosing this to other DNS operators ongoing both before DEF CON and will likely continue to do so after DEF CON as I'm sure some emails might come roaring in so to start as I said before we need to talk about DNS and what a better place to start than talking about the attacks because we can't really talk about all of DNS so in the early DNS in the way back when DNS was really only considered exploitable in a man in the middle scenario which it has no protections against still really doesn't have a ton of protections against but it's getting closer in any case back then ignoring other protocols the only thing that was actually keeping a normal DNS reply from being spoofed doing things off path not man in the middle was the DNS ID and the styling and the structure of the response itself it has to answer the query DNS queries and responses are very consistent so really we're back to only talking about DNS ID and again I said said before ignore other protocols there is of course the issue that this is being sent across the Internet and there is this extra level thing called a UDP which is going to have port numbers and some other things that are going to be very difficult to guess if you're trying to spoof a DNS reply and Kaminsky is for original attack basically determined that a number of implementations of resolvers that were being used were programmed to query over sequential very predictable set supports and this took out basically all their sources of entropy that were to exist to make it difficult for the attacker so again we're back to the 16 bits of DNS ID and that's really not enough to stop an attack once poison records get saved if you can try over and over and over again and if you succeed it gets saved well then you're good you're good to do this off path you need to be in the middle what do you mean what do I mean by off path have a diagram so dotted blue line here is the network path from DNS request from our target is taking and we're off path because our attacker boxes the red boxes were we're just not on the network path we can't see anything that's going on there we might have some idea of what's going on over there but we can't see or modify the traffic now for this particular case and I'm going to keep this going this diagram it's going to change a little bit but it's going to be largely the same are we have our attacker box off somewhere in the internet and then inside of the trust boundary some corporate network something that the resolvers servicing we have both our target and a puppet the puppet we don't really have to fully control it could be as simple as just some JavaScript in a web browser but what follows is a little less simple so first the attacker is going to basically figure out where the external facing IP is for the resolver this can be as simple as basically talking to ourselves making a request for domain that we control and as long as our box is also serving as a name server for the our own domain we get the IP address of the resolver the attacker then can just tell their puppet hey send a request on my behalf and since we know what it's requesting and when it's requesting we can immediately start sending responses to the resolver and since everything else is largely predictable in case the Khminsk attack even the even the destination port on UDP is predictable we can just start guessing DNS IDs because the resolver is going to make another request on behalf of our puppet we don't know what the idea is but we can start guessing and this might take a little while it's not always going to get cash sometimes the legitimate response is going to go straight through the resolver and so really we do have to find certain types of requests that aren't going to get cashed at least when not modified this can you can do this in a couple of different cases you can do this for a zero time to live domains or near or near zero it's a lot of it a lot of it is content delivery networks Akamai CDN YouTube a lot of those requests aren't going to live very long in the cash or we can start asking for things like domains that don't exist which won't get cashed unless of course you then proceed to give a response for them where you say that it is existent and then you start changing some other things like the records for where the name servers are at and other things which will of course all end up in the cash as well once it's in the cash it also comes down to a puppet but that doesn't really matter the important part is that it's saved so when our poor target machine goes out to ask for it it gets a response back that it probably shouldn't have gotten and starts reaching out immediately the internet for whatever it was trying to reach initially DNS is a is a protocol to find other things ultimately and reach out to our malicious server malicious server goes as and gives them yeah totally those binaries that you wanted yeah got them there you go and that person if that person wasn't paying attention they get farmed the program is reaching out not checking the TLC certificates and frankly anything that there's not good verification in place they get pound the end just as disturbing as it was a little bit more than a decade ago of course the Kominsky attack doesn't work anymore I'm glad we've made progress in the past decade shortly before that attack was presented even various DNS resolver applications were patched to make the UEDP ports unpredictable Dan Kominsky is a whitehead after all so he did tell everybody kind of ahead of time these say this puts up a heck of a damper on trying to do this kind of exploit because now you have a destination port to guess as well that's another 16 bits at 30 put two bits total and although you could exclude some of the ports this is about 65,000 times harder though the attack is still high-profile and scary you're not gonna be doing this in any kind of feasible scenario and I'm not going to pretend Kominsky alone made DNS sec happen that but this did help along so people scared of DNS being spoofed basically are now using DNS sec without going too far into it DNS sec is basically public key infrastructure for domain names and I can't I can the highest level of authority signs for various top-level domains die like dot org who then in turn signed the keys used by domains so for example Defcon dot org which then used to sign those keys for records individual records say where WWE dot Defcon dot org is of course it's a little more complicated than that but we really can't for a sake of time dig into it couple of things that DNS sec adds that are really important is data origin authentication basically the ability to verify the data you're receiving is coming from where it's it's saying it's coming from and also trying to make sure that data cannot be modified in transit since the records are signed by the zone owner and the zone's private key it would be really hard to mess with that because if it actually gets verified well it's the signatures are not going to line up this how cryptography works of course not everybody is actually deploying DNS sec and even if you were to you know deploy DNS sec in your domains it's not particularly helpful if the resolvers aren't doing it either at this part this is really not going too well in the last report this was made was in 2016 unless you're in Central Africa and your ISP is using Google DNS for everything you might be in a bad bit of luck in any case we need to bring up some more bad news and talk about what DNS sec doesn't actually do either delegation and glue records name server a records for IP addresses located in the authority and additional sections in DNS are not signed delegations or records that basically relay authority to another server so realistically dot com isn't going to know what servers example dot com is running so you have to delegate that authority down and I had mentioned glue records where glue records glue records are largely a fix to solve an issue of if you have your name server in your domain or there's some concern about somebody not knowing where your name server is for your domain you include that at the absolute end of the request or yeah pardon me include that the absolute very end of the response because otherwise someone who's looking for some resources and example dot com are going to ask the dot com domain okay where's example dot com it's going to tell hey you need to look over here for example dot com and okay well where's the name service for that we don't know okay ask dot com again this continues in an infinite loop so that's why they need to be this but somebody of course in here I hopefully is thinking why aren't these signed why can't we just figure out a way to sign this well your FC says so it's with actually good reason it's delegation of duty cloud child zones have a private key for thwarted records and the parents don't really can't be signing it for them but there's again there's data origin authentication you if you can trust that parent you can probably trust the children as well and there's you know large committees that are rather trustworthy running most the system of course there's also to deal with all the signatures all these signatures can make responses quite long especially if there's lots of records and as a bonus name servers can even sign the gaps between valid subdomains and sign nearby names to prove there is no sub domain in between using insect or insect three and but how bad could it be someone might ask like well if today you go ahead and ask defconn dot org for non-existent domain they're using insect and so they will respond very verbose Lee with one thousand nine hundred and twenty two bites to tell you something doesn't exist seriously this is this is our best solution you can't even send this across the internet we in one piece without expecting it to get fragmented which is something we need to talk about so Hertzberg and shulman realize that this was kind of a problem if the response is getting split up UDP has no means of dealing with fragmentation only really that's TCP and everything in DNS is running by UDP by default so it has to be fragmented the IP layer and that means it gets an IP identifier and mind you these are rather inexact diagrams but it's I'm trying to keep it simple is IP around UDP around DNS and in red is basically all the things that an attacker can't really spoof it's and that IP identifier is an IP layer three thing it's used on both IP four and IP v six in any case it's an additional factor source of entropy we have to guess it is an attacker but if you're noticing that second fragments looking a little lonely because all of those QC signing bits and the other protocols end up in that first fragment and the second fragment the only thing we have is that IP IP layer identifier now DNS actually adds even more stuff but again it ends up in the headers or the first couple of things in DNS nothing in the second fragment and it is it turns out the IP ID for IPv4 16 bits this familiar to anybody as a further bonus many resolvers when this paper was published were using global counters for IP ID and it was the default in Windows default and free BSD according to them when they published in 2012 and there was a lot of the lot of resolvers they were able to find right before they published that we're doing global IP ID so what is this attack end up looking like in that particular case well I have to add something to diagram a quick we now have an IP fragment cache on this diagram it holds up to 64 fragments that's relatively the default it holds them up so they can be reassembled when and if they all get received and if nothing else it drops them after a couple of minutes and in case the first thing we do when performing this attack is ask sometimes you only need to ask as an attacker we basically just ask the name server if the response is fragmented or it's IPv4 we get an IP ID back so we already know what IP ID the name server is using if it's using global IP ID and then we proceed doing what we were doing before puppet goes ahead and ask something on our behalf and while the name server is still thinking about responding to that we start guessing IP IDs and DNS is relatively well structured very consistent if you ask for something you're always going to get roughly the same reply sort of maybe some garbling up in the headers but again we don't care about the headers we're sending the second fragment over and over and over and over and over again and we actually have a good starting point we can we know what the IP was before and so we can go ahead and just send that sucker along and start guessing everything in kind of front of it mind you it is global so we have to do this kind of quickly other people could be talking to this name server and they probably are which is going to increase the IP ID but we can guess 64 times so at some point we're not just going to go through but we're actually going to be combined with the first fragment of the original legitimate request which contains all of the lovely headers that are signing this thing and then that's going to go right on up into the cache and then down to our puppet but again the thing we care about most is the cache because when at a later point when that poor target machine goes ahead and asks well hey where's deftcon.org they're going to get that assembled but tampered response and just like a Commencius detect before target makes a query for what was further and it gets told how to get told it lives with the attacker it's pulled some data from the attacker it died all downhill from there and pardon me my mouth is getting really dry so there's a lot of stuff you can actually do with this even with DNS Sack. DNS Sack does limit what you can do with these kind of poisoning attacks and there's only so much you can really mess with in the cache that isn't directly signed but of the four sections question answer authority and additional the ones we care about most with DNS Sack are those last two the ones that are going to contain the stuff that's likely to be unsigned and they're almost always going to make it in that second fragment and we get some options I would love to verbally explain to you all the limitations but they made a diagram for me so I'm going to use a diagram from their paper so the main ones you want to look at here because there's a couple and that a third from bottom line there is permissiver island basically the resolver is not actually doing some good resolving not checking anything yeah there's a lot of stuff you can do immediately if the resolver is not checking DNS Sack but for the other cases when everything is in line doing what it's supposed to do there's other stuff you still can still do so if they're you doing if you're using insect three which and you're using it with an opt-out that means you're not signing delegations with insect three and that means that if someone were to say I don't know replace one of your insect three records with an NS record for a subdomain yeah that subdomain exists now as far as your resolver is concerned the other thing you can do is basically something in two phases you can do NS hijacking which if you've noticed doesn't have a lot of requirements and name server blocking which again doesn't have a lot of requirements at the same time basically what you do is you poison an NS record that makes it in the cache and then you start performing server blocking on all the other name servers and it's actually really easy to do name server blocking because the only thing you have to do is ruin the responses from all those other name servers and if you can just ask what their IP ID is all you have to do is just mess it up you don't have to poison anything you don't have to have it even be correctly structured if it gets reassembled then it's the wrong way it's not going to be accepted and for most DNS software and unbound particularly two failed queries at a 15-minute interval that name that resolver marks that name server is not responsive all bad news and if that last slide wasn't concerning enough there's also the possibility the attacker could cause fragmentation by tricking the name server into believing that it needs to further fragment traffic which of course helps get a complete record into that second fragment or as many records as you want into that second fragment and this does work on IPv6 as well and there's been a couple of studies done that you can get this stuff well below what should be the minimum transmission unit any case there are some more limitations to this this you folks probably would have heard about this if had not been for some additional limitations there's a lot of name servers that aren't deploying with global counters anymore no real surprise there that's something we generally expect from the network stack of a printer windows is still as far as we know using a global counter but free BSD is now using a mostly random searchable queue system and Linux still isn't using global counters even back in 2012 Linux was using mostly per destination and we can't query something that gets cached just kind of like before a significant portion of difficulty here is finding the query that was that returns a predictable fragmented response and sometimes the options for a given target are pretty slim and maybe just the response to the any query is enough but mmm it can be dicey and there's also the future IPv6 throws a complete wrench in this 32 bits and trying to guess with IPv6 that puts you in the territory of 34 million iterations and that's that's doing it on average the actual case for exhausting the entire key space and this is assuming you know stuff isn't moving or other people are talking this name server is around 67 million you're not going to do this this is literal terabytes of traffic you'd have to send you're not doing this on IPv6 there's no way but there has been some notice this is this is kind of a bit of a thing for IPv4 and prior to our engagement with umbrella their implementation was using IPv6 whenever possible why wouldn't you and they detect IPv4 fragments and re-cour them over TCP or IPv6 if it's or ah pardon me re-cour it over IPv6 where possible and basically re-cour over TCP if that still fails or you can't just quarry over IPv6 there was also a presentation this May in at OWARC which wasn't us actually now please excuse the crayon colors I am taking directly from their slides but this is this is a rather pertinent presentation I had said before this was what we founded bypassed all recommendations yeah this is kind of the weird case because in an earlier slide in this presentation they had said drop all fragments but then here they say well the attacks only effective on IPv4 and kind of directly implied IPv6 is safe I digress in any case this is good news there's interested parties and the people who are the major operators of DNS are generally trying to lose tie up all the loose ends without any major performance impact so now we have to have that little tangent I was talking about before which might make a little more sense now so the sequential nature of IPID is largely why idle scanning exists it's what M-Map uses but as a lot of people here may know the kind of scan has some requirements for its zombies namely global counters and also they have to kind of be idle machines they need to act like a 1990s printer basically I won't explain what this particular team found in depth because we really don't have the time but in a somewhat similar manner to idle scanning a university of mexico research team developed a way to abuse the IP fragment cache and Linux machines to basically determine if something had been sent and much like idle scanning you could do this to figure out whether or not traffic was being sent on a link that you can neither see nor control and it works on fully per destination IPID counters which is what Linux had and you can measure how many and you can really just do any kind of measurement across the internet he was to say the Linux folks didn't appreciate this and they didn't really want every Linux machine on the internet being used as a zombie for an idle scan and so around the same time as this paper being published it they created some patches the first that we care about was to directly prevent measuring communication between two machines and the second was an optimization to IPID how IPIDs were handled so the first one I did say was a direct mitigation well it doesn't actually completely fix it because what it's doing is just making it harder it's basically incrementing the IPID by a random but normal between one and the number of kernel ticks since the last sent packet this kind of requires keeping track of the last kernel tick values as part of per destination counter and this map makes this operation rather extensive especially if you have a lot of things to talk to but it does work and if your interest was trying to do a long term idle scan or a long term query as to what was going on between two machines yeah this is going to make it real hard for you to do that because if you spend more than one kernel taken between your polling you have no idea what's actually coming back it's properly random the second one was an optimization before the network just act was basically keeping track of all the IPID counters for all destinations individually and storing them in a binary tree this caused a lot of performance issue for servers that talk to a lot of clients like name servers and sends every comp so I graduate knows that O of a constant is much better than O of long n they made a new way based on hashing and binning so destination addresses both IPv4 and IPv6 are hashed to match it with a bin which will contain the current IP ID counter which will then be used on the next thing that gets sent out the port now this does mean that some destination addresses are going to have to share an IP ID counter so to prevent an outsider knowing which addresses are being sharing a bin the seed for this hash function which is doing all the determination is secret and determined that boot perfect especially if you have enough bins and hash collisions are rare now that's that's a low number now if you think this is kind of low like I think this is kind of low the research at University of Mexico the researchers at University of Mexico would agree with you and so they of course immediately then proceeded to make another idle scanning using the Linux network stack so basically the way they do this is they use IPv6 to legitimately get very large source address spaces you could use IPv4 but as we know that that address space is a little bit sparse nowadays and it always sources they query the IP ID counter for their IP ID address with a fragmented ICMP6 echo request which then returns a fragmented response and they increment the IP ID counter for the target by basically spoofing a Sinect to the target and then query again basically figuring out the hard way whether or not the talking and the spoofing they're doing is in the same bin as what they're able to query on their address and then they just change the addresses if it doesn't appear to line up now why fragmented IPv6 echoes well IPv6 is a little weird because it doesn't fragment the IP ID counter unless the traffic is sent fragmented and well all the above requests as an extra stipulation have to arrive within one system tick one kernel tick of another to force that random perturbation of one to the number of kernel ticks to always be one it's funny you know the difference random number between one and one is always one not the best mitigation thankfully for most systems this timing is actually pretty low ever since jiffy's were invented that counter is about ten milliseconds a hundred Hertz it could be as low as point six six milliseconds on specialty systems that are running clocks all the way up to one thousand five hundred Hertz but that has to be a very specifically configured OS now once the collision is found you can basically just flip this triangle it's nice and start doing your idle scan basically instead of trying to figure whether or not you have a collision with the target you can start sending stuff off to another machine and see if whether it responds back to this machine that you're doing the querying for and they called this not an idle scan oh well so there is something that you folks probably have noticed at this point this is a lot of knowledge that you can get about the IP IDs in the state of IP IDs and the IP IDs for communications to other machines and hold on now why didn't the folks at the University of Mexico realize that this might have some other implications why didn't they realize that this was gonna have a huge implication on DNS and fragmentation tax well they were thinking about idle scanning I don't blame them and show of hands who knew about Hertzberg and shulman's research before today no hands yeah you can't blame them so we get to talk about something new today so basically this attack which mind you that's what I get for pressing the down arrow so we start this attack basically the same way as onus and no for those of you who are about to ask I am not going to call this an is or actually not an idle scan for various reasons but we're gonna start by finding collisions just like with onus and instead of a zombie in a target we basically have a name server and resolver now the text is a little bit small but if you noticed we're using IPv4 in there well what if they're talking over IPv6 what if we need to find collisions in IPv6 addresses like umbrella was planning on doing well no problem we'll make a my pv6 echo frags as well and what about getting our address space the entire point of using IPv6 to do this particular attack is it's got to be convenient how convenient is it trafco well it'll be us to the rescue so even the free tier of abdus vpc virtual private cloud you can get some IPv6 address space but the real question is of course you know is it big enough I haven't done it's extensive testing albeit but I'm gonna say that this is probably enough for those folks that can't count commas as fast as the slide is going to be up that is 18 and a half quintillion give or take a couple dozen quadrillion mind you statistically it only takes about 10 thousand addresses to get a 99.2 percent chance of a collision because there's only 2048 bints and this is outright better than trying to do global IP name servers IP a global IP ID for name servers because in this scenario we get protection we get that added improvement of all the other bits of binning and if there's a couple of random house on the internet 2047 of them aren't going to mess with our IP ID and also once we find this collision we can kind of sit on it and the service election is like literally any remotely recent Linux kernel if you're Linux kernels older than 2014 by the way you should probably patch there's some stuff that you need to deal with and as far as like what our target space looks like now well there's something that exists a lot more than existed in 2008 or 2012 when some of the other attacks were coming out and that's these lovely lovely public resolvers and they're really trusted in fact as I mentioned before there's entire central african nations where all the ISPs are going through Google DNS sure would be a shame but somebody did something to Google this yeah and frankly don't be wrong there's some presuppositions there's some difficulty in doing this attack you need to find the right set of targets but if you poison a resolver you're attacking everybody who's using these and as far as getting a puppet downstream well you can be the puppet to you can be both the attack server and the puppet because they're public resolvers you just enroll yourself it's free and as I kind of mentioned before this whole collision finding bit is completely detached from the attack time is on our side as an attacker and now it's actually really on our side as an attacker the hardest part and the most legwork to find this is in the collisions and although they could be found in minutes we're really in no rush we can probably stay around for weeks months or years because that key that is determining the hash doesn't change until the system reboots and I don't know if any of you know a lot about name servers they're not going to reboot a lot that's bad for the internet and we've got some interesting options as well because we can do a lot of really short duration cash attacks because we have a very good idea what the IP ID is and we can very plausibly do this in the first hit and we can also accumulate a ton of matches for multiple name servers multiple resolvers even if Google is running a hundred and one resolvers and we want to poison a hundred and one name servers we can just get the collisions all hooked up for that and then just start poisoning away and eventually we're going to get poisoned records into every last one of them if we know what the IP IDs are that we need to send it's kind of a strange workaround for load balancing and because we're doing this in a one-shot we may not even need a puppet in the case of non-public resolvers if you're trying to do this on a corporate network maybe you don't even need to have something make a request because there's a lot of stuff that happens at midnight and patched Tuesday there's a cron job or some automated client that's going to reach up I don't know if your blue teams are working midnight's but we can and maybe the public can be completely passive if we see common requests when they're being requested we know what the time to live is on those records and we can just wait till they go out of cash and have to be requested again by the resolver and so we can start actually consider poisoning things that are getting cached every single time because we can very plausibly do it the first time and maybe poison isn't even our purpose maybe what we want to do is just dots the entire world or prevent patched Tuesday from happening which would be very bad if we're an attacker in the middle of a corporate network and the windows up to windows updates aren't coming down anymore if we can do poisoning in one shot we can really mess up a response in one shot to so I've said a lot of words up to this point what is the actual final attack look like so basically we have to pick our targets and this is a little difficult to do we can at least figure out what the resolver is if we're a downstream puppet or we have some kind of way or it's in a public resolver and we also find some domains some domains that are likely to send some large responses and we have to find some servers that are actually running Linux that shouldn't actually be terribly difficult but it is some it is an important point once we return determine the resolvers public IP address for the request we can just basically evaluate the domain responses to see what or not we can actually poison anything and then we do our but we do our collision finding which should be good again until the name server actually finally restarts and then we wait puncture water drinking now right before we do an attack we can optionally trick the name server into lowering the PMTU and forcing fragmentation to exactly the number we want it to be or we could also just not and just request for non-existent domain on defconn.org there's a lot of domains that are using NSEC and NSEC 3 the responses get quite large and then we just query the name server to get the IP ID because we've already found the collision and then we do that yeah I should say we should do we do that directly before a known request is about to be sent we could do the query and then we basically send 64 smooth fragments we could send only one if we're very confident in our confidence in ourselves but I mean if we're doing this we might as well send the full payload that we could possibly send and we do that based on the known IP ID as described in fragmentation considered poisonous and I will point you to Hertzberg and Shulman's paper as to what you can do from here because it is all laid out and that paper is nice and old so now's a good time to start talking about how do you actually get around this with what's the fix Trafco well as I said before I'm not the expert so I'm going to hand it over to Brian who is closer to an expert and he can talk about some mitigations I'm Brian so much I work on the resolvers at Cisco so this is a really interesting problem and there are lots of parties involved there's the zone owner the person who owns the data there's the name server so that's the person that or that's where the data lives sometimes the same as the owner sometimes it's a registrar sometimes it's a third party and then there's the resolver that almost never lives with the data and the resolver normally lives closer to the to the client and of course is the client the person who actually wants to look up the address it's usually an address it's not always an address with DNS but address is the most interesting parts so really what we're what we're actually trying to avoid here or what what the problem is is that the attacker is attacking the resolver due to a bug in the name server and the name server is holding the data on behalf of the zone owner and the lie is getting propagated to the client so there's a whole ton of people involved here and really the the attack target is the resolver so that makes it my problem IP fragmentation has has been an issue for for years like since Kaminsky first first observed these these issues so our approach has always been well that's easy we drop fragments and DNS has a mechanism built in and where and when you actually ask a question of a name server you can say and by the way my maximum payload size is X so if you set X to something like 1410 and drop all fragments at the resolver well then the name server is going to respond if they respond with something that's less than 1410 bytes and it gets fragmented then we lose it we don't get the response and that's never been a problem because really modern day hardware really does have packet sizes of at least 1492 or whatever these numbers are so that's how we always played it and then we came to try to support DNS sec and DNS sec RFCs have lots of requirements and those requirements say that we we should deal with packet sizes of 4k and that's because DNS sec payloads are much larger and we don't really want to send everything over TCP so that seemed like a kind of sensible requirement so you have to come up with a solution to this this fragment problem we wanted to be able to turn on fragments but not full full victim to these these sorts of attacks so our first scheme came up with a as it turns out naive approach yeah so so our naive approach was was to assume that IP IDs were random because well that's what the RFCs say they are the random right and of course IPv4 has a 16 bit random number and well that's easy to attack and IPv6 has a 32 bit random number way way harder to attack IPv6 also uses PMTU to to discover what the the fragment sizes are so that's that's much more difficult to attack for the for the attacker as well so we naively assumed that IPv4 was bad IPv6 was good and we implemented something that cleverly marked packets at the at the far wall marked whether or not they used to be fragments and marked whether or not that first fragment was of a reasonable size 1280 in our case and if stuff arrived at the resolver and it was marked as a fragment at 1280 then we'd cash all of the data in the first 1280 bytes say that that's absolutely good and we cash all of the remaining data as kind of I'm not too sure about this stuff and if we ever need to use that data then we'd actually look it up again and we'd look it up over either v6 or tcp that seemed like a great idea until Travis came along and pointed out that that didn't actually work because these IDs aren't actually random so what do we do we could try to do the same thing for IPv6 but that's actually really really difficult because IPv6 fragments are hard hard to deal with at the far wall there and in fact well actually DNS already has this ability built in it's the ability that we used to use of limiting the payload size and just expecting things to go over tcp so I did some experiments and really when you run a kind of public facing resolver and we've observed that more or less slightly less than 0.1% of our traffic is tcp traffic so if you look at all the queries and for every thousand queries there's one tcp query and the other 999 are our UDP and in fact when you turn on DNS sec and you start querying all of those big juicy DNS sec payloads and you do all of this over IPv6 over UDP either IPv6 or IPv4 and actually that 0.1% goes all the way up to almost 0.5% so in fact the RFCs that say that this is a requirement to be able to handle large packets in UDP is just not true so how many people here have heard of DNS flag day so a handful of people four or five people so DNS flag day is a really big deal and it was a really big deal for me anyway and where the DNS community are basically trying to take some of the the awkwardness in DNS the the the kind of rule breaking that has been going on for years in the industry and make it not okay anymore so there was a DNS flag day last year and it was all about whether or not name servers versus resolvers supported EDNS so the way resolvers talk to name servers they'd say hey name server can you talk EDNS and it would do this by supplying some EDNS options and if it got no response from the from the name server it would send another packet and if it still didn't get a response it would try it without EDNS and if it got a response then it would kind of say okay this guy doesn't support EDNS and I'm going to continue on and there was an awful lot of kind of behavior like that going on and flag day is all about kind of saying okay well that behavior is not okay anymore if you don't if you don't behave properly then things just aren't going to work so there's going to be another flag day in 2020 and this flag day is all about fragmentation I'm not sure the entire DNS community is convinced but one of my kind of pushes for this flag day is going to be fragmentation is not okay all resolvers and all name servers don't do fragmentation so resolvers will block fragmentation coming inbound from the name servers and the name servers will just configure their UDP payloads to be a maximum of something smaller than their MTU. Measuring this on a resolver how do you tell whether you're getting poisoned well you can look for lots of echo responses you could look for IPv6 echo responses you could look for IPv4 echo responses you could graph them if you think you're getting poisoned what do you do about it like there's there's limited use in doing any of this this sort of stuff because if somebody attacks you will you just have bumps in your graph if you can't do anything about it there's no point in worrying about it you need to worry about it and make it not happen in the first place so on the name server side I mean the name server guys really have almost the same problem but in reverse I guess yeah I mean from a name server point of view really what you want to do is limit your your edns buffer sizes or your edns payload sizes and avoid fragments all together and you can do some clever things which aren't as it turns out to clever and so with the DNS IP ID 2048 bucket setup and that's all actually hashed using sip hash if you reboot your server you can receive that sip hash and you can basically give everybody new slots in the in the array but well how long does it take to reboot your server and even if you did introduce a way of kind of saying okay we see now really what are you gonna do like run that every second well why do you just choose random numbers in the first place so again yeah the answer for name service is to do the same don't send fragments and again you can you can try to avoid them guessing things at the at the name server you could tar pit icumps but really they could do exactly the same attack over DNS and you'll never be able to notice that because it'll be a drop in the ocean in terms of the number of queries that you're actually getting so like even if you graph that you're not even gonna see it and of course you can go a little bit more hardcore and you can rebuild your kernel you can make this I bi dense size which is set to the 2048 you can make that a bigger number or you could just change the code and actually make it pick a random number and for domains for the domain owner like if you're a domain owner and you don't really know what your your name service going to do and you don't really know what the resolvers in between are going to do well really your your only hope is to use DNS sec and the big flaw in DNS sec as as Travis said is is delegations delegations are fine if you're delegating to another sign zone if you're delegating to an on sign zone then actually the on sign zone is very vulnerable because your delegations aren't secured and remember that DNS sec all that tells you is whether or not something is good or not and it doesn't stop denial of services so it's not the answer to everything but it's the answer to most things these days and yeah of course if you're using DNS sec make sure that you've got reasonably size and reasonable sized keys don't don't go for the lower lower size keys yeah don't go for lower size keys and that Verisign tells you that a key that's going to be up on the internet for 120 days a 30-day pre-period and an active period of 90 days know that RSAs do get broken and if your key gets broken maybe choose a bigger key pair just an idea and I guess one of the more exciting things about DNS sec that's coming out recent and lately is that it's moving towards elliptic curve technology and elliptic curve uses way smaller hash sizes so the the signatures are well not not our sizes but signature sizes so as a result the signatures are smaller and you're less likely to actually bump into fragmentation problems anyway and yeah panic maybe panic a little all of the resources are up here if you need to screenshot this obviously the files are probably going to be uploaded somewhere on the DEF CON media server at a later point and I bet Travis this has been Brian and this has been in the talk I don't know if there are any questions so the question was regarding IP ID and whether or not we should have released a CVE for it and whether or not this has other implications oh yeah this totally has other implications this is actually rather terrifying for certain things like online gaming which are using a lot of UDP if you can get in the second fragment of these things and they're doing all their off in the front it's bad news we could release a CVE but what are what's the target for the CVE the internet I would have loved to send that to Mitru but I have a sneaking suspicion is probably not going to be accepted but I do appreciate the question it seems like a bit of a target yeah I guess it's worth mentioning as well for IP ID that the original RFCs for IP and talked about caching fragments for 30 seconds against being able to to marry them up with the original and deliver the packet that's clearly just not a good idea in this day and age and this day and age caching them for say at most 50 milliseconds would probably be way more appropriate but I haven't seen any RFCs that suggest that sort of behavior I mean it this this sort of thing could be mitigated a lot more certainly raw IP ID attacks sorry second yes absolutely so you cash it for a smaller amount of time and just fling them away way more eagerly and it will stop lots of second fragment attacks where people are dropping multiple second fragments hoping that they'll marry up on the IP ID okay thank you very much