00:00:00.033-->00:00:05.038 >>My name is Jim Nitterauer I'm a senior security officer with AppRiver. My talk is entitled, 00:00:05.038-->00:00:11.078 DNS, Devious Name Services Destroying Your Privacy and Anonymity Without Your Consent. 00:00:11.078-->00:00:14.982 Before we get started you can read all this legal stuff here. I don't really care too much 00:00:14.982-->00:00:20.654 about it. AppRiver is a web and email security company. We offer three main services. Secure surf 00:00:20.654-->00:00:25.259 which is a spam filtering service, uh hosted exchange and then secure surf. Which is where 00:00:25.259-->00:00:30.764 I come into the picture. Uh my expertise is in building out that DNS infrastructure. So, 00:00:30.764-->00:00:35.769 before we get, oop it jumped on me there. Here we go. Before we get started, um so why am I 00:00:38.505-->00:00:44.344 doing this talk? In 2014 Glenn Greenwald gave an outstanding Ted Talk about why privacy 00:00:44.344-->00:00:49.416 matters. He discussed the good people, bad people fallacy and the dichotomy between what 00:00:49.416-->00:00:53.754 corporate America says about privacy and what C-level execs personally believe when their 00:00:53.754-->00:01:00.227 own privacy is at risk. Greenwald mentioned a uh, quote from Eric Schmidt in 2009. And 00:01:00.227-->00:01:04.331 he said if, if you remember he said if you have something that you don't want people to know 00:01:04.331-->00:01:09.736 maybe you shouldn't be doing it in the first place. Yet in 2005 Google blacklisted CNET 00:01:09.736-->00:01:15.175 reporters from talking to google employees for 1 full year until July 2006. This was all because 00:01:15.175-->00:01:19.313 CNET published some information on Schmidt including his political views, hobbies, 00:01:19.313-->00:01:23.350 salaries, neighborhood and all this other information. Guess where they got that data? 00:01:23.350-->00:01:28.355 Google. So maybe he should uh be a little more careful about what he puts in his own services. In 00:01:30.924-->00:01:35.662 2010 there was a TechCrunch interview uh with um Mark Zuckerberg and he essentially 00:01:35.662-->00:01:40.667 told the reporter that privacy is dead and that um, yes in 2013 Mark Zuckerberg bought 4 homes 00:01:43.737-->00:01:49.743 that surround his own home as a buffer zone to prevent people from getting close. Uh oh, this 00:01:49.743-->00:01:54.748 things gone wonky on me here. Make sure I'm on the right spot. Yes that's. I'm sorry. [off-mic 00:01:59.519-->00:02:04.458 comment] Yeah it's, it's going crazy here all of a sudden. [off-mic comment] Yeah, alright. 00:02:09.963-->00:02:14.301 So, I'm going to unplug it and replug it back, see what happens. Ya know what they say. 00:02:14.301-->00:02:18.372 What can go wrong will go wrong, right? It was working perfectly in the ready room and working 00:02:18.372-->00:02:23.377 perfectly earlier, so. We will start this again. I think we're back on track. Maybe. So, point 00:02:35.656-->00:02:40.193 is privacy should be important to all of us, right? WE shouldn't be expecting the 00:02:40.193-->00:02:44.965 corporate leaders in America to have a different standard for how they treat our own privacy. 00:02:44.965-->00:02:50.637 Here we go. See if it goes down. Yay, ok so, more recently the Chinese government made it clear 00:02:50.637-->00:02:55.776 that they were going to crack down VPN users within China and yet another attempt to quash 00:02:55.776-->00:03:00.380 privacy. As I began to understand the details of the DNS protocol as it related to 00:03:00.380-->00:03:04.551 our service offerings I noticed there were some components of DNS that if it were used in 00:03:04.551-->00:03:09.423 appropriately it would result in further erosion of user privacy and possibly diminish your 00:03:09.423-->00:03:13.994 security. So, I believe education is key and that's why I put this talk together. I 00:03:13.994-->00:03:19.399 first learned about the use of EDNS client's subnet while I was working to optimized content 00:03:19.399-->00:03:25.572 deliver via DNS. In May 2016 I received a call from Matt Calder at Microsoft. He called me and 00:03:25.572-->00:03:30.510 said you guys are using EDNS client subnet in a caching environment. That's kind of 00:03:30.510-->00:03:35.148 weird because the only other people we see in our passive DNS data doing that is the Chinese 00:03:35.148-->00:03:38.885 government. And he, we had a good discussion about why we were doing it and what the impl- 00:03:38.885-->00:03:43.423 implications were. But it was interesting to me that the Chinese government was 00:03:43.423-->00:03:48.428 implementing this in a way to uh, continue uh, spy on people. So companies like Akamai, 00:03:51.164-->00:03:57.370 Google, CISCO which owns OpenDNS now and others are making use of DNS in unique ways. Sometimes 00:03:57.370-->00:04:02.342 the rush to offer these new services to improve the security and functionality of the, comes 00:04:02.342-->00:04:07.247 at expense of our own personal privacy. With the repeal of the FCC regulations prohibiting the 00:04:07.247-->00:04:13.753 collection and resale of user browser data. That was senate joint resolution 34 uh, in 2017 00:04:13.753-->00:04:17.758 and 18. The internet and content providers now have the freedom to profit from the sale of your 00:04:17.758-->00:04:22.662 data. If you were here for track 3 yesterday afternoon there was a great talk on how that 00:04:22.662-->00:04:29.035 supposedly anonymized data could be uh, de anonymized and returned to point to specific 00:04:29.035-->00:04:32.839 users. So it was kind of a scary talk. You might want to look that one up. So here on the left 00:04:32.839-->00:04:37.544 you see, I don't know if you know who Suffering Bastard is, some of Jack Daniel in the room 00:04:37.544-->00:04:41.181 or if Suffering Bastard is here, but kind of follow the adventures of him on Twitter. 00:04:41.181-->00:04:46.019 But I saw this picture. Jack gave me permission to use it and I appreciate it. Uh, this 00:04:46.019-->00:04:50.957 picture reminds me of us as the user suffering bastard. And somebody threw some bread crumbs 00:04:50.957-->00:04:55.929 on the ground. Those bread crumbs to me represent the data that we're putting out that. And 00:04:55.929-->00:05:01.768 the pigeons or the providers collecting that data. Trying to uh distribute that information 00:05:01.768-->00:05:05.572 without us really wanting it distributed. And suffering bastard pretty much sums up the 00:05:05.572-->00:05:09.609 reason for this talk. Is this the life that we really want. Do we want everybody knowing every 00:05:09.609-->00:05:15.715 move that we have on the internet? I would say not. So, should out to Jack Daniel. I 00:05:15.715-->00:05:20.720 don't know if anybody. Oop, here we go again. Yeah I know. [laughter] S- S- S- S- S-. Sorry 00:05:32.265-->00:05:37.270 about this. That's just the way it goes sometimes. So. [off-mic comment] Maybe the next slide 00:05:48.548-->00:05:53.553 will be better. We'll going to keep going. Because we're going to run out of time if we keep 00:05:57.958-->00:06:02.896 mucking with this here today. Alright, s- i- well that doesn't look good at all, does it? 00:06:06.867-->00:06:11.538 [laughter] Well I'm going to keep going on with the talk and you'll have to deal with seeing 00:06:11.538-->00:06:16.142 the slides in uh retro-disco mode here. So today what we're going to do is we're going to 00:06:16.142-->00:06:21.481 review DNS. Give a quick history of DNS. Review the introduction of EDNS0 extensions and the 00:06:21.481-->00:06:26.519 option codes that go along with those. We're going to discuss the rationale for EDNS0 use. 00:06:26.519-->00:06:31.891 We're going to examine EDNS client subnet as one of the options that's in uh use right 00:06:31.891-->00:06:36.196 now as an example of how those option codes are used. We're gonna review some DNS servers 00:06:36.196-->00:06:40.500 that support that. We're gonna examine some tools and procedures for testing that and 00:06:40.500-->00:06:46.039 we're gonna discuss the privacy implications that EDNS0 options could have in your environment. 00:06:46.039-->00:06:50.410 And hopefully have some time for questions if we're not staying in disco mode too long. By the 00:06:50.410-->00:06:55.348 end of this talk you should understand the basics about EDNS option resource records. You 00:06:55.348-->00:06:59.519 should understand the potential that they have to be a threat to your privacy. We should have 00:06:59.519-->00:07:04.324 some direction for testing how those are put in play in DNS world. And you'll be able to 00:07:04.324-->00:07:10.497 understand how to better protect you online privacy. So, very quickly we're going to do a 00:07:10.497-->00:07:16.369 quick review of some history of DNS here. So stick with me for a minute. DNS was originally 00:07:16.369-->00:07:20.774 devised to support the growth and communication of email via the ARPANET. Host names were 00:07:20.774-->00:07:25.078 developed as a way to make it easier for humans, us to remember and recall addresses. 00:07:25.078-->00:07:29.949 Initially the name number relationships were kept in local files on servers and these files 00:07:29.949-->00:07:34.554 were prone to errors as a result of it, it d- it was difficult to share and maintain this 00:07:34.554-->00:07:39.125 information. Those originally files were called the host master file so that's why it 00:07:39.125-->00:07:42.896 typically when you're dealing with somebody that's registering a domain name they have a host 00:07:42.896-->00:07:48.401 master account. They uh system grew, it became obvious that a distributed system was necessary 00:07:48.401-->00:07:54.307 and, and in 1983 uh, uh Paul Mockapetris and Jon Postel proposed the domain name system. 00:07:54.307-->00:07:59.312 And those RFCs that we now use for DNS are RFC 1034 and 1035. DNS was designed to be a 00:08:02.449-->00:08:07.620 distributed database that's hierarchical in nature. The master level is the dot domain. 00:08:07.620-->00:08:11.925 All other domains are directly linked back to this dot domain or the root domain. A fully 00:08:11.925-->00:08:17.797 qualified domain name must be expressed with the trailing dot. Domains consist of a namespace 00:08:17.797-->00:08:22.669 which is a level and location in a tree. The resource records that define that namespace and 00:08:22.669-->00:08:29.609 the resolvers that propagate and manage those records. Second generation DNS improvements uh 00:08:29.609-->00:08:34.614 came about in uh well the introducing of incremental zone transfers with RFC 1995 in 1996. 00:08:36.716-->00:08:42.856 Prior to that time changes in a DNS zone required the full transfer of all hosted zones to 00:08:42.856-->00:08:47.594 other interested neighbors. That now would be possible to transfer only those zone threat 00:08:47.594-->00:08:52.799 changes eh- eh to the interested neighbors. This is done by comparing serial numbers in the 00:08:52.799-->00:08:59.205 SOA record uh for the interested neighbors. The RFC 1996 also introduces the concept of a 00:08:59.205-->00:09:03.777 master and slave records as well as a notify message. This improved the efficiency of DNS 00:09:03.777-->00:09:10.450 by reducing network traffic. Less than a year later the third generation of DNS was introduced 00:09:10.450-->00:09:16.156 with RFC 2136 and the concept of dynamic updates. This takes transfer efficiency to the next 00:09:16.156-->00:09:20.827 level by enabling master servicers to transfer only changed resource records within 00:09:20.827-->00:09:25.598 a zone to those zones that are interested neighbors. This further improves the traffic 00:09:25.598-->00:09:30.203 flow and introduced the concept of the TTL or the time to live that we're all familiar with 00:09:30.203-->00:09:35.208 right now. In 1999 RFC 2671 and now later 6891 bring about the addition of the extension 00:09:38.778-->00:09:43.783 mechanism for DNS or EDNS0. And we'll dig into those eh details a little more here coming up. 00:09:45.852-->00:09:48.955 Fifth generat- or fourth generation DNS enhancements included the edition of 00:09:48.955-->00:09:54.060 standards for RFC 2181 which just redefined some of the standards for DNS and the 00:09:54.060-->00:10:00.767 implementation of standards for NXDOMAIN and responses defined in RFC 2308. If you wanna look 00:10:00.767-->00:10:07.240 at some more information about um, the fifth-generation DNS improvements came about with the 00:10:07.240-->00:10:12.245 inclusion of DNSSEC in the EDNS0 options and uh then the definition of the option codes 00:10:14.614-->00:10:18.685 that we're going to be looking at a bit more coming up. If you want a quick reference on the 00:10:18.685-->00:10:22.322 best places to look to get an overview of DNS here's a couple quick ones that you can look at. 00:10:22.322-->00:10:27.327 S o, let's look at RFC 2671 a little bit more. RFC 6891 is the one that's currently in play. 00:10:30.330-->00:10:35.335 RFC 2671 was proposed by Paul Vixie in 1999 and replaced by RFC 6891 in 2013. The standards 00:10:39.305-->00:10:44.477 for following DNS to exchange information about servers and services within a given zone. 00:10:44.477-->00:10:50.717 Now remember DNS is a layer 7 protocol that essentially uses UDP to exchange DNS information. 00:10:50.717-->00:10:56.589 TCP is used for zone transfer and more recently as a way to mitigate a DNS amplification 00:10:56.589-->00:11:01.528 attacks. DNS data has a hard packet size limit of 512 bytes when EDNS0 options or EDNS0 is 00:11:04.764-->00:11:10.603 not in play. And the DNS packets contain more than 512 bytes will typically fragment leading to 00:11:10.603-->00:11:17.043 some interesting DNS results. So option records contain at the very minimum eh, eh the extended 00:11:17.043-->00:11:23.049 datagram size, which is the size of the packet extended return codes and the DNS OK flag. That 00:11:23.049-->00:11:28.588 tells whether DNSSEC is uh enabled on the network. This allows for additional space and 00:11:28.588-->00:11:33.593 additional return codes and a DNS message. DNS option records have a record ID of 41. They are 00:11:36.429-->00:11:42.135 not stored in uh record files so they cannot be loaded from zone files. They can only be set 00:11:42.135-->00:11:47.140 programmatically. Alright so again this is a type 41 record. Uh the R code field uh is from 4 00:11:50.777-->00:11:55.782 to 12 bytes long. And then EDNS uh um RFC 6891 defines the option record sizes. And RFC 00:11:59.352-->00:12:04.290 3225 defines information about DNSSEC. Alright this is an example of, uh this this option 00:12:09.429-->00:12:15.568 record is option 41, w- we talk about that and again it shows the information about DNSSEC. so 00:12:15.568-->00:12:20.573 here we have, this shows the format of one of these option records. Um. [off-mic comment] 00:12:30.883-->00:12:35.888 >>Let's get this out of your way here. >>Sorry for the technical difficulties. We did test this 00:12:48.134-->00:12:54.440 earlier and everything worked fine so. Maybe somebody's figuring out a way to hack HDMI 00:12:54.440-->00:12:59.445 remotely. Well earlier there were people with macs having the same issue to its, it's, so it's 00:13:07.987-->00:13:12.992 a shared, shared problem. [off-mic comment] [laughter] Do they know what PowerPoint is? 00:13:32.378-->00:13:35.248 [off-mic comments] [laughter] So we interrupt this talk for a brief comedy routine by the 00:13:35.248-->00:13:40.253 audience. [laughter] >>Woo >>I won't be able to see. [applause] Will I be able to see my notes? 00:13:45.992-->00:13:52.165 [applause] I can just follow them on the other screen. That's fine, I can follow them on the 00:13:52.165-->00:13:57.170 other computer. Alright, so now I gotta have, now I gotta have one mic for the mic and one hand 00:14:00.339-->00:14:05.478 for the computer. So here we go now we've gotta play catch up. Let's get us up to where we are 00:14:05.478-->00:14:11.484 on the other screen. Alright, that's where we are, right? Option resource records. These 00:14:11.484-->00:14:17.290 option resource records are defined in the RFC and they are uh, showing you that how each 00:14:17.290-->00:14:21.794 packet is defined and inside this the important part that we are going to look at in a few 00:14:21.794-->00:14:26.799 minutes is the R data filed. And that is where the option codes will be stored for DNS. This 00:14:30.937-->00:14:36.509 part of the record here is the TTL fields. So, if we go, try- trying to find the, up. If we go 00:14:36.509-->00:14:42.115 back up the TTL field is used to store information about DNSSEC information within the EDNS0 uh 00:14:42.115-->00:14:47.120 option record. or OPT record. And if we look at the RDATA structure, this is attached. 00:14:50.056-->00:14:56.362 Back up one. The last row here the RDATA field has a structure that's a variable for each of 00:14:56.362-->00:15:02.301 the 65,335 different option codes that area available for EDNS0. And this would be the 00:15:02.301-->00:15:07.306 structure of a typical record. Alright, what we're looking at here is a bit of a Wireshark 00:15:09.609-->00:15:15.148 capture that shows uh EDNS0 OPT record. Starts with the root there, shows you the OPT record. 00:15:15.148-->00:15:21.320 But if you look down in there you'll see that his shows the TTL record which has the DO bit. 00:15:21.320-->00:15:27.160 Which tells you whether DNSSEC is available or not. And then below that it has 1 option 00:15:27.160-->00:15:31.297 record in there and this one it happens to be option 8 which is EDNS client subnet. We're gonna 00:15:31.297-->00:15:36.869 look at that a little bit more in detail here as we go forward. So all of these EDNS option 00:15:36.869-->00:15:41.874 codes are defined uh via RFC or by drafts. This is from the IANA website and lists all of the 00:15:44.277-->00:15:50.316 current assignments for EDNS0 option codes. And tells you, gives you links to the RFCs that 00:15:50.316-->00:15:57.256 pertain to them. If you wanna look at drafts you have to go to the IFT dot org website. If you 00:15:57.256-->00:16:03.429 search through the option codes that are available there and use the keyword EDNS it will give 00:16:03.429-->00:16:08.968 you the options that apply to EDNS as they're released or put in the uh list for review. So 00:16:08.968-->00:16:15.141 this is a table that shows the option codes, they're available. Right now um th- this shows the 00:16:15.141-->00:16:18.811 status, the name, the description, and the vendor, Uh who proposed it. And we're gonna 00:16:18.811-->00:16:23.082 go through a few of these. This is the same information. Uh the last 2 at the bottom show 00:16:23.082-->00:16:28.554 proposed drafts and we'll look at those here in just a second. So, option codes 5, 6 and 7 are 00:16:28.554-->00:16:32.558 related to DNSSEC implementation. This lets resolvers know which 00:16:32.558-->00:16:37.997 cryptographic algorithm was used to generation the digital signal, signature that's used to 00:16:37.997-->00:16:44.470 exchange information via DNSSEC. This specifies a way for end users to validate what types of 00:16:44.470-->00:16:49.141 encryption algorithms are in play. They're not required for DNSSEC to work but it does make 00:16:49.141-->00:16:54.146 it much easier for DNSSEC to work. Option Code 8. This is EDNS client subnet. This is the 00:17:00.753-->00:17:04.757 one that is pro- probably most widely used and we're gonna look into some of the details of this 00:17:04.757-->00:17:11.397 here in a little bit. A- as we move forward. This lets resolvers know the IPv4 WAN or 00:17:11.397-->00:17:17.069 IPv6 address of a subnet of the requestor that's making a DNS request. It's developed to 00:17:17.069-->00:17:22.742 enable content delivery via DNS. And we'll look at bit more at this here coming up. Option code 00:17:22.742-->00:17:29.582 29, or 26946, this is called DeviceID. This is issued by CISCO's umbrella platform, 00:17:29.582-->00:17:34.887 formerly OpenDNS. It sends the information that's shown there, you have an organization ID, a 00:17:34.887-->00:17:41.294 remote internal IP and a remote IPv6 address that is forwarded to CISCO's umbrella, uh API or 00:17:41.294-->00:17:47.867 via CISCO's umbrella to their umbrella dashboard. This is either forwarded from a client 00:17:47.867-->00:17:52.805 that has the umbrella client installed on it, so it could be a laptop, could be tablet, 00:17:52.805-->00:17:58.311 whatever. Or it's from a router that may or may not have a umbrella enabled via API pr- uh 00:17:58.311-->00:18:03.249 DNS proxy and API. This one here is the ISP draft location. This is another gift from the China 00:18:06.152-->00:18:12.325 Internet Network Information Center. So it's gotta be legit. Right? So, they're proposing 00:18:12.325-->00:18:17.330 here their basic gist of this is that uh EDNS client subnet provides IP information. Chinese 00:18:20.166-->00:18:24.170 government wasn't to know the country the area and the ISP that's sending that information 00:18:24.170-->00:18:30.776 as well in a DNS packet. So, this isn't sketchy at all, right? This last one is the 00:18:30.776-->00:18:36.782 ClientID this is uh forwarded in DNS queries. This is proposed by Akamai. It's currently in draft. 00:18:36.782-->00:18:41.787 It's being fast tracked for RFC. And what they wanna do is send the mac address and a hash of 00:18:43.990-->00:18:50.796 some other information from your device through DNS in and EDNS0 option packet to their upstream 00:18:50.796-->00:18:56.936 DNS servers. The rationale behind this is it allows for uh when a device seems to be making 00:18:56.936-->00:19:00.873 uh calls to compromised domains you can attribute that compromise that a specific 00:19:00.873-->00:19:05.878 device on the network. So, let's look at EDNS client subnet with a little more detail. So we can 00:19:05.878-->00:19:11.083 see how these kinds of things evolve. This was an initial draft in 2011. It was uh 00:19:11.083-->00:19:17.757 released by Google, Verisign and Neustar. Uh the rev- first revision uh of the draft came in 00:19:17.757-->00:19:22.762 2013. And if you look here you'll see, I'm gonna go through these a little bit quickly. This 00:19:22.762-->00:19:28.267 is how quickly the changes were made to this draft once it became uh fast tracked for 00:19:28.267-->00:19:33.272 implementation. So, within a year it was RFC and now it's RFC 7871. There was also 2 patents 00:19:36.776-->00:19:42.381 submitted for this RFC, they'll never pass but somebody tried. Uh the Europea-, somebody in the 00:19:42.381-->00:19:47.586 European Union is trying to get a patent on it, uh that will make it impossible for anybody 00:19:47.586-->00:19:51.624 else to implement this without paying them royalties. And there's the US Patent number 00:19:51.624-->00:19:56.362 that's pending. I don't suspect that either of these will ever be issued. So how does EDNS 00:19:56.362-->00:20:02.635 client subnet work? Normally a client makes s- a DNS request to a sub stream cache resolver. 00:20:02.635-->00:20:07.573 That resolver if it has it in the cache will answer and give you the DNS data back to the uh 00:20:07.573-->00:20:12.578 device. Now if that resolver supports EDNS client subnet it will pen the EDNS option packet 00:20:16.048-->00:20:21.954 with the option 8 data and send that to every upstream server involved in the DNS request 00:20:21.954-->00:20:28.894 chain. Think about that for a minute. Alright, normally the DNS server 1 hop up knows your 00:20:28.894-->00:20:35.835 public IP address. With E EDNS uh client subnet in play, every server in the chain potentially 00:20:35.835-->00:20:42.575 has the ability to read your uh WAN IP address. The authoritative server then will 00:20:42.575-->00:20:48.314 do some calculations based on the data that's provided in this ECS packet and return an, a 00:20:48.314-->00:20:54.086 record based on whether or not, or, or a geolocation is in play and send you to the correct 00:20:54.086-->00:21:00.793 site. So, this is a content delivery network load balancing via a geolocation and IP. If you 00:21:00.793-->00:21:05.798 look at a client subnet record, we looked at this uh, part of this in a larger sec through the 00:21:08.601-->00:21:13.939 EDNS0 record but this is an example of what you see if you see it in Wireshark. So, the 00:21:13.939-->00:21:18.444 first line just tells you what option it is. Uh the option length in this case is 8 bytes. 00:21:18.444-->00:21:24.083 Gives you the option data. It shows you that it's using IPV4 as the IP address that's being 00:21:24.083-->00:21:30.756 passed up to the upstream provider. In this case the source netmask is 32. So, this 00:21:30.756-->00:21:36.195 is a misconfiguration by the RFC. It should be a slash 24 or greater. And the scope netmask 00:21:36.195-->00:21:42.334 tells the receiving server uh what range of geolocation to provider and answer for. And 00:21:42.334-->00:21:48.007 then you see obviously the IP address of the requesting client in the packet. These are the 00:21:48.007-->00:21:53.546 authoritative servers and caching recursive servers that currently support EDNS client 00:21:53.546-->00:21:58.551 subnet or ECS. Uh Google, Akamai, NS1, OpenDNS, UltraDNS, PowerDNS, BIND 9.11 greater, 00:22:01.453-->00:22:06.458 Amazon CloudFront they all pass ECS data from any edge through the DNS chain. Recursive 00:22:08.627-->00:22:14.133 resolvers, Unbound supports it from 1 point 6, 2 and above. It has to be currently compiled 00:22:14.133-->00:22:18.337 with an option to enable that. Uh if you don't compile it without and option right now if 00:22:18.337-->00:22:22.408 you just download it and install it through the normal package uh it does not include support for 00:22:22.408-->00:22:28.047 this. But I suspect that will change uh here in the near future. So OpenDNS and BIND also 00:22:28.047-->00:22:34.220 supports, uh Bind 9 point 11 and greater also support EDNS uh client subnet. There's was a 00:22:34.220-->00:22:38.157 move a foot called a faster internet. This was a consortium of people who got together and 00:22:38.157-->00:22:45.130 decided that we wanted to push uh client EDNS client subnet or ECS through to RFC. They are, 00:22:45.130-->00:22:50.369 were very active, they've been kind of dormant lately and none of these providers really 00:22:50.369-->00:22:55.374 provider you any information as to if they do or do not support uh the uh protocol. So, problems 00:22:58.043-->00:23:02.114 with this, we need to be able to evaluate whether this is in use or in play on our network, 00:23:02.114-->00:23:07.853 right? So, there's really no registry showing my, our name servers support uh ECS right? 00:23:07.853-->00:23:11.924 So, we don't know if it's an ECS client resolver. You're relegated to reading the 00:23:11.924-->00:23:15.961 provider's tech material and some of them will put it in their website and tell you that 00:23:15.961-->00:23:21.300 they do use it and aside the faster internet is not current. Recursive uh resolvers are now 00:23:21.300-->00:23:25.404 uh that support this are now becoming more prevalent and they're also same deal, there's 00:23:25.404-->00:23:30.909 no register listening to give you any insight into whether they're supported. So how can we 00:23:30.909-->00:23:37.016 check to see whether it's in use? Well l, one of the best tools right now is dig. We can 00:23:37.016-->00:23:42.221 do a dig against anything after the at sign would be the name server we want to hit. Uh and if 00:23:42.221-->00:23:48.394 we'd sue that domain EDNS dash client dash sub dot net that's a registered domain that's hosted 00:23:48.394-->00:23:53.299 by a power DNS. Thank you to them for putting that out there. It will return a JSON packet 00:23:53.299-->00:23:59.305 that tells you whether the server you queried against supports ECS in the query chain. 00:23:59.305-->00:24:05.177 The second way we can do it is we can use dig. And we can use the plus subnet option. Now this 00:24:05.177-->00:24:09.248 is built into the later versions of dig. Uh last time I checked the version that's installed in 00:24:09.248-->00:24:13.786 Cali supports it. Uh the version you would download in from bind and install on Windows also 00:24:13.786-->00:24:18.924 supports it. So you would use this plus sub net option and you could change that option, the IP 00:24:18.924-->00:24:23.495 address in that option to any IP that you want and you can see what kind of information is 00:24:23.495-->00:24:28.567 returned from the server based on the domain that you're looking up. So for example you 00:24:28.567-->00:24:34.573 could run this against Google's cache server 8, 8, 8, 8 and use Google dot com and you'll see 00:24:34.573-->00:24:39.178 that the IP addresses that are returned based on the client subnet change as you change the 00:24:39.178-->00:24:44.183 subnet IP. This is an example here of um, using the first method where we're actually 00:24:50.556-->00:24:56.428 querying the EDNS dash client dash sub dot net and you see the JSON packet there in the 00:24:56.428-->00:25:01.333 response. And it gives you the option if you look half way through you'll see ECS colon 00:25:01.333-->00:25:06.105 true. So it tells you that it does support it and you'll also find the source mask and the 00:25:06.105-->00:25:11.710 scope mask in that packet. There's no information in the opt pseudosection so the 00:25:11.710-->00:25:17.249 upstream server that I queried in this case did not receive an ED, ECS packet when i- when it 00:25:17.249-->00:25:22.254 was queried. It only returned one based on the result of the uh query. This is an example 00:25:24.490-->00:25:30.295 using dig. We're using uh dig against 8 dot 8 dot 8 for Google with that subnet option it gives 00:25:30.295-->00:25:35.334 you those IPs. If we were to change the IPs that we use in the plus subnet option e would 00:25:35.334-->00:25:40.239 get different IPs back for Google. And you can try this against other uh, cloud type 00:25:40.239-->00:25:45.244 systems to see whether it works. Some other tools that we use for uh testing support would be to 00:25:47.813-->00:25:53.285 install Packetbeat. Okay so Packetbeat can be installed on many, many different platforms. 00:25:53.285-->00:25:58.290 And one of the um Packet capture uh protocols built into Packetbeat is to capture all DNS 00:26:00.592-->00:26:05.230 traffic. So, it's a parallel capture and it can forward all of that traffic to some sort of 00:26:05.230-->00:26:10.569 log aggregation. In our case uh we use Graylog which you could easily use Splunk or any other 00:26:10.569-->00:26:15.407 log aggregator that would read the JSON packet that Packetbeat sends to it. Or you could put it 00:26:15.407-->00:26:20.045 directly into Elasticsearch and read it with Kibana. And I'll show you an example here of how 00:26:20.045-->00:26:24.950 that works. So, what you do then is you create a stream for example in Graylog and you can 00:26:24.950-->00:26:31.089 tag the stream for a particular field. The field that's returned is that Packetbeat DNS option 00:26:31.089-->00:26:37.529 subnet field. Right now, uh Packetbeat only has the ability to support option 8 which is 00:26:37.529-->00:26:42.434 ECS. But in the future I would imagine that other options would be able to be read from that 00:26:42.434-->00:26:48.407 string. Here's an example of what you get. You get a graph. Um basically what we have is a 00:26:48.407-->00:26:53.111 small ISP set up for some internal customers that have public facing IPs. They use 00:26:53.111-->00:26:58.116 these DNS resolvers and you can see that i- their IP address is in the second column there under 00:27:01.253-->00:27:07.226 messages. So we would see if we were 3 hops out, we would still see their um WAN IP address in 00:27:07.226-->00:27:12.264 those DNS packets and be able to capture that. So this is not anything that's very difficult. 00:27:12.264-->00:27:17.636 Any ISP could do this at any point in their network and gather information about a 00:27:17.636-->00:27:24.543 domain request for any IP address. So, other things that we could do to evaluate use is 00:27:24.543-->00:27:30.148 we could run uh captures on local interfaces. PCAP captures uh in Wireshark you would use uh 00:27:30.148-->00:27:36.388 a filter. Here it has a built in uh filter for DNS where you can do the DNS opt code filter. If 00:27:36.388-->00:27:42.594 you put a number after the doubles equals that's the option code number. One of those 65,535 00:27:42.594-->00:27:49.501 codes. So if you put in 8 you'll find all of the ECS data. You can go through and try this with 00:27:49.501-->00:27:54.940 other option codes and you might be interested to see what's in your DNS. Just a side note. Um, 00:27:54.940-->00:27:59.945 how many of you have looked at Microsoft's Windows 10 lately? So it's uh, they've added a 00:28:01.880-->00:28:06.885 multicast DNS cache resolver on port 53, 53 that's built into uh Windows 2016 and Windows 10. So 00:28:11.023-->00:28:14.593 if you're looking at DNS you also have to take into account the fact that multi case DNS 00:28:14.593-->00:28:19.665 could be present on your network and could leak DNS information that you may not capture in your 00:28:19.665-->00:28:26.271 normal Wireshark uh data capture so it's just something to keep in mind. This is a single line 00:28:26.271-->00:28:31.810 Wireshark capture of a query. A send and receive and it shows you where the ECS data is 00:28:31.810-->00:28:36.815 highlighted down at the bottom. Nmap also has a script that's available. This probably came 00:28:39.484-->00:28:44.890 this came out before um support was built into dig. So you can if you're doing engagements and 00:28:44.890-->00:28:49.194 wanna do some automated scripting you can use this nmap script to gather information 00:28:49.194-->00:28:54.399 about ECS uh support upstream. It's a little cumbersome it returns a lot of data and you 00:28:54.399-->00:28:59.137 kind of have to sort through it and manually compare IP addresses to see if support is 00:28:59.137-->00:29:04.743 there. Uh not really recommended way for doing it. I'm working on a too. l didn't get a chance to 00:29:04.743-->00:29:09.214 finish it, uh but what we're gonna do, what I'm gonna do is look through uh maybe Alexa top 00:29:09.214-->00:29:13.085 1 million or whatever number of I uh domains we can look at. We're gonna look at the domain 00:29:13.085-->00:29:18.857 name. We can run dig against each name server in that and we can sort out to see which one's 00:29:18.857-->00:29:24.863 support ECS or supply ECS data using several different methods that I've already gone over. So, 00:29:24.863-->00:29:29.334 once I have that information available and put that out there I will uh put that in a blog 00:29:29.334-->00:29:35.007 somewhere where somebody can get at it. So, the other thing that's uh, we noticed when uh, 00:29:35.007-->00:29:41.013 when I start looking at uh programming support for uh DNS the libraries that support uh 00:29:41.013-->00:29:46.818 looking at DNS traffic. AIRSoft Tools supports option 8 manipulation so you can set it 00:29:46.818-->00:29:51.289 you can read it. Uh right now it doesn't support any other options but once that support is 00:29:51.289-->00:29:55.694 built in then you'll be able to look at some of those other option codes that we looked at. 00:29:55.694-->00:30:00.999 Uh Python also has support in their programming language for being able to read EDNS or ECS 00:30:00.999-->00:30:06.004 option 8. I think uh pyth- the PHP net DNS 32 has it in there as well, or DNS2 uh Scapy does 00:30:09.608-->00:30:16.515 not have support for it at the moment. Uh Scapy is a open source packet generation tool so 00:30:16.515-->00:30:23.288 being open source if somebody were interested they could add those options and s- uh parsing 00:30:23.288-->00:30:27.626 for those options into the code repository. So, it's just a matter of time until that's out 00:30:27.626-->00:30:32.197 there. Uh it's kind of interesting because once that's in the ability for Scapy to 00:30:32.197-->00:30:37.002 generate packets, packets with spoofed information could be created and sent upstream 00:30:37.002-->00:30:43.575 resolvers. So, what is privacy and security implement- implications of all of this? 00:30:43.575-->00:30:50.215 Well, this was in 2013 when we found out the NSA was reading all of our data. Dilbert kind of 00:30:50.215-->00:30:55.220 sums it up. So ECS leaks your IP information if it's in play to every DNS server in the DNS 00:30:58.857-->00:31:03.929 chain if those servers are able to read that data or if there's packet B or some other logging 00:31:03.929-->00:31:09.034 mechanism installed on those servers that data can be gathered. So, interesting, 00:31:09.034-->00:31:14.039 right? The first server in a chain for ECS may not honor the subnet restriction. Meaning, i- 00:31:16.308-->00:31:21.580 if your WAN has a slash 22 and that's what you want broadcast so everybody in that same 00:31:21.580-->00:31:27.552 network gets the SME cache results, it may actually send a slash 32 or a slash 128 for an 00:31:27.552-->00:31:33.358 IPv6 so you can attribute the DNS request to a specific endpoint. Now remember there's 00:31:33.358-->00:31:38.363 no such concept as NAT with IPv6 right? So IPv6 is deployed all the way to the endpoint so if 00:31:40.432-->00:31:45.670 you're sending out a slash 128 through one of these options it's getting back to the actual 00:31:45.670-->00:31:52.644 device that has that IP address bound to it. Many of these uh options are proprietary with no 00:31:52.644-->00:31:58.183 insight into how to send, how the data is sent to them. The data that's sent is not always 00:31:58.183-->00:32:02.821 fully disclosed. And the other problem is that they all talk about in the RFCs that there 00:32:02.821-->00:32:07.826 should be privacy mechanisms in place and there should be ways to opt out. How many of you know 00:32:07.826-->00:32:12.597 how you could opt out of some of these options? Probably nobody, right? I don't. None of these 00:32:12.597-->00:32:17.836 providers have given us any of this insight. They also don't advertise whether they support 00:32:17.836-->00:32:22.774 it or not it's up to us to test to see if they do. And the implementers can track your data 00:32:22.774-->00:32:27.112 without your knowledge. As we saw on the talk yesterday about web browsing data. Now imagine 00:32:27.112-->00:32:32.350 DNS data. Right? So, every call out to the internet from every device, every application, not 00:32:32.350-->00:32:38.456 just web browsing uses DNS to get you out to the internet and get results. So basically, 00:32:38.456-->00:32:44.863 nothing you do on the internet in any way will be private. So it can also return data to the 00:32:44.863-->00:32:49.401 client. This is kind of the scary part. People haven't figured this out yet how to use 00:32:49.401-->00:32:52.904 it but once they do and once programming libraries are in play there's going to be new 00:32:52.904-->00:32:56.341 ways for botnet commanding control traffic to be transmitted, right? Remember 00:32:56.341-->00:33:02.747 there's 65,535 of these options. Anybody with a little programming creativity wants 00:33:02.747-->00:33:06.084 some of these programming libraries support the ability to add these options and DNS 00:33:06.084-->00:33:12.090 packets. Can add data to the, those packets and send it across the wire. So how many of you 00:33:12.090-->00:33:17.095 monitor your DNS right now? I should see every hand in here up. Every hand, right? But how 00:33:20.832-->00:33:27.505 many of you that monitor your DNS, monitor DNS for option data that goes out of your network? 00:33:27.505-->00:33:32.677 Right we can look at DNS traffic and we can find exfiltration by subnets added to A records and 00:33:32.677-->00:33:35.714 text records but how many actually look at these records to see what kinds of things are 00:33:35.714-->00:33:41.219 going on in your network. This is going to be a big deal once people understand how this 00:33:41.219-->00:33:46.925 works. The other problem is third party recipients can buy information regarding your DNS 00:33:46.925-->00:33:51.696 habits. Right, so if somebody tracks that 3 or 4 hops up stream then that data's 00:33:51.696-->00:33:56.101 available for sale, the log gives us these providers the ability to sell it. People can 00:33:56.101-->00:34:00.105 use that for various reasons as we saw yesterday they could use it for good. They could use it 00:34:00.105-->00:34:06.478 for uh malicious purposes. And unethical people could buy that information and use it as well. 00:34:06.478-->00:34:13.318 So, the privacy as it relates to DNS without extra steps in place is pretty much dead. So, one of 00:34:13.318-->00:34:18.456 the problems is this is, eh just a sub example here. This is a correct configuration of unbound 00:34:18.456-->00:34:23.461 how it's set up to send uh E ECS data upstream. So for IPv6 it will send a slash 64. That's the 00:34:25.563-->00:34:32.237 smallest amount that should be applied to an interface or for a client a slash 24. But it's just 00:34:32.237-->00:34:38.376 as easy to configure it to send a slash 128 or slash 32. So now we get down to the specific 00:34:38.376-->00:34:43.848 device IP address. So these configurations are not very well um, controlled. They're not very 00:34:43.848-->00:34:48.887 well explained and this is just one example and if you look at one other thing. If you look in 00:34:48.887-->00:34:53.892 the configuration for unbound for example it gives you the option code for EDNS client 00:34:56.528-->00:35:00.966 subnet. They built into this the ability to do other options they just have released the ability 00:35:00.966-->00:35:07.005 to do it at this point so eh kind of watch wants' going on with that. Alright so how do we, 00:35:07.005-->00:35:11.376 how do we define against this sort of thing? Alright, 1 is know what's normal. Log your 00:35:11.376-->00:35:16.881 DNS. You can log it through looking at just DNS logs or you can do full packet capture, the 00:35:16.881-->00:35:20.385 point is you need to know what's normal on your network. I would imagine that if you dig into 00:35:20.385-->00:35:25.256 your DNS no pun intended if you dig into your DNS traffic a little bit more you're gonna 00:35:25.256-->00:35:30.395 find things that you never expected to see on your network. Ya know route all n- all DNS to 00:35:30.395-->00:35:35.934 known resolvers. Don't let your users change your resolvers right? Make them force your DNS 00:35:35.934-->00:35:40.438 to resolvers that you know and you trust. Lock out non-validated DNS at the edge. 00:35:40.438-->00:35:45.977 You could disable EDNS0 but my guess is you would break a whole lot of things so I wouldn't 00:35:45.977-->00:35:51.016 suggest that. Uh monitor your DNS logs obviously and do for PCAP capture. Something like 00:35:51.016-->00:35:56.521 security on your [inaudible] on a spam board on your edge network would be nice. If you 00:35:56.521-->00:36:03.028 start seeing things in your DNS create IPS rules to block it. You could enforce uh DNSSEC 00:36:03.028-->00:36:07.866 requirement for it. Uh but stuff will break. A lot of people don't maintain their DNSSEC uh 00:36:07.866-->00:36:14.172 keys correctly. Uh, particularly the big brother domain the dot gov we've seen those break 00:36:14.172-->00:36:19.778 several times where they don't rotate their keys and, they fix it pretty quickly but, anyway it 00:36:19.778-->00:36:25.383 breaks DNS. Some offensive options that you could use to prevent people from um forging 00:36:25.383-->00:36:30.555 information uh for gathering information about you. Is you could create DNS with forged 00:36:30.555-->00:36:35.460 option data, right. You can create packets that forge that information and basically blur 00:36:35.460-->00:36:39.764 what you're doing based on your IP. But I would suggest that if you're doing any kind of 00:36:39.764-->00:36:44.703 engagement, you're doing anything where privacy is in the least bit critical that you use 00:36:44.703-->00:36:49.908 full VPN tunnel and then Tor out past that VPN to a safe end point. And I'll give you some 00:36:49.908-->00:36:53.344 insight on a couple of other things I would do as well. One of the big things that people 00:36:53.344-->00:36:59.017 don't do is account for IPv6 traffic. So, which protocols preferred on almost every 00:36:59.017-->00:37:03.955 network stack? Ipv6 right? Windows IPv6 is preferred. All version of Linux that I Know of, 00:37:07.292-->00:37:11.963 IPv6 is preferred. So, if it's on your network and you get an IPv6 address that's what it's 00:37:11.963-->00:37:16.801 going to use. So, you need to make sure that when you're doing engagements, you're doing things 00:37:16.801-->00:37:22.340 where you want to hide yourself that you're only using IPv4 or you're accounting for your IPv6 00:37:22.340-->00:37:27.212 traffic on your network. Because some things will leak information that you may not 00:37:27.212-->00:37:32.217 expect. If you use TorGhost for example on Kali it only supports IPv4. Uh my home router has IPv6 00:37:35.787-->00:37:39.057 enabled because I have to be careful what I'm doing when I use Kali at home. I have to 00:37:39.057-->00:37:44.996 disable it completely on uh boxes when I'm doing things that I wanna test. And you can also 00:37:44.996-->00:37:50.535 test on your local network with Wireshark or TCPDUMP to make sure your DNS is going where you 00:37:50.535-->00:37:55.540 think it should. And again check for Multicast DNS as well. The other way you can make DNS 00:37:57.909-->00:38:03.982 really secure is you can build yourself a DNSCrypt resolver in the crypt. DNSCrypt is put out 00:38:03.982-->00:38:10.255 as an open source project by OpenDNS, now CISCO. Uh you can build your own. You can build it 00:38:10.255-->00:38:15.160 into unbound. You can pile unbound with it. But basically, what it does is it creates a way 00:38:15.160-->00:38:21.032 to prevent DNS from being spoofed. But the other thing you can do then also is, wow. 00:38:21.032-->00:38:26.037 [laughter] Must've gotten somebody upset. So the other thing you can do is uh set that 00:38:31.576-->00:38:36.581 resolver to um not, not push any ECS information out over the network. I don't know if I can 00:38:40.485-->00:38:46.024 talk loud enough for this. So we're almost done here anyway. So if you set your resolver 00:38:46.024-->00:38:51.029 using a DNSCrypt proxy on Kali. Download and install that package and uh point your 00:38:54.165-->00:39:00.538 resolver to the 1, 2, 7, 0, 2, 1 address and then it will route your DNS to a series of DNSCrypt 00:39:00.538-->00:39:05.143 resolvers that are a part of a public list. You can adjust that list and forward it only to your 00:39:05.143-->00:39:10.982 own DNSCrypt resolver. And that way you know for sure that your DNS is secure or is at least as 00:39:10.982-->00:39:15.987 secure as you can make it. So summary, a option data usage has several useful purposes. It 00:39:19.023-->00:39:25.697 allows CDN by DNS. It enables DNSSEC. It gives DNS responses that can be used to mitigate 00:39:25.697-->00:39:30.468 DDoS in um certain situations. And the signature of compromise can be attributed to a 00:39:30.468-->00:39:34.872 particular device when a device is compromised. Those are all good things. The problem of it 00:39:34.872-->00:39:39.844 is that all DNS servers in a DNS chain contract that data if they're enabled to read it. No 00:39:39.844-->00:39:44.482 standard has been set for developing for opting out of that. Forwarding ENDS options 00:39:44.482-->00:39:49.220 compromises your privacy and there is no mechanism to verify the opt out again. The opt data 00:39:49.220-->00:39:53.258 could have potential for abuse because people are mining that data. It could be spoofed right. 00:39:53.258-->00:39:57.795 So if somebody is using that data for uh legal reasons, law enforcement maybe. There is no 00:39:57.795-->00:40:02.800 way to attribute that data to you accurately because other people can modify that data. Uh 00:40:02.800-->00:40:06.738 botnet commanding control traffic. I think you'll start to see that happen over the, these 00:40:06.738-->00:40:11.843 options and data exfiltration could be done via these DNS option packets. So these are all 00:40:11.843-->00:40:15.480 things to keep in mind and look for. And if you have any questions you can find me 00:40:15.480-->00:40:20.485 afterwards. I'll be here through Sunday but I appreciate your time. Thank you. [applause]