1 00:00:03,210 --> 00:00:08,360 Hello DEF CON, welcome to our talk DNS section. 2 00:00:09,280 --> 00:00:17,080 Today will be an interesting talk about DNS and the workings of the internet and cryptography. 3 00:00:17,480 --> 00:00:32,560 So what this talk is about is about an email privacy breach in the largest French cloud provider which is also the first practical attack on NSEC, DNS Secure Zone Working. 4 00:00:32,660 --> 00:00:38,180 And finally it's a cautionary tale about the use of hash functions. 5 00:00:39,400 --> 00:00:54,000 Why this matters is because DNS is everywhere, it's part of the internet, it's heavily used, it's very important and there are tons of potentially very valuable interesting data all over the place. 6 00:00:54,560 --> 00:01:07,200 The other reason why it matters is that zone working has not been demonstrated in the wild to this extent before and it's the first time that we actually recover very valuable interesting data from it. 7 00:01:08,880 --> 00:01:10,380 Who we are? 8 00:01:10,380 --> 00:01:12,920 Well this is Adrien. 9 00:01:13,560 --> 00:01:14,760 Hello! 10 00:01:15,180 --> 00:01:16,520 And I'm Rémy. 11 00:01:16,520 --> 00:01:24,060 We are from Ecole Normale Supérieure, PSL University in Paris, France, in the beautiful place itself. 12 00:01:24,140 --> 00:01:27,340 And this is not the first time that we talk at DEFCON. 13 00:01:27,340 --> 00:01:34,040 This has been done in collaboration with Amaury Barral and David Nekash. 14 00:01:34,200 --> 00:01:40,340 So without further ado let's start with the first part of our talk. 15 00:01:44,780 --> 00:01:50,160 So to understand DNS it's very important to understand our talk. 16 00:01:50,160 --> 00:01:51,340 We're going to start with that. 17 00:01:51,440 --> 00:02:00,700 The basic question that you ask with DNS is who is behind a website such as skytalk-vids.com for instance. 18 00:02:01,200 --> 00:02:11,760 So DNS, the domain name system, is a system to name remote resources, to give you access to them, and it does that by holding a distributed database. 19 00:02:12,380 --> 00:02:25,600 A system that contains record resources and domain names and that allows resolvers to figure out the translation between a domain name and an IP address. 20 00:02:26,440 --> 00:02:39,720 The DNS tree itself is subdivided into subtrees that are called zones and are administrated by different people, different entities, whose role it is to keep it up to date. 21 00:02:39,720 --> 00:02:49,160 So when you want to, say, build a website, create a new website, well, you actually need to go through several steps. 22 00:02:49,160 --> 00:03:00,120 Once you have a device and you have a server and you have a website running on it, you need to add your device, your IP address, to a DNS server. 23 00:03:00,440 --> 00:03:12,140 And to do that you call a registrar and you run a DNS server that advertises your IP in connection to the domain name that you are interested in. 24 00:03:12,760 --> 00:03:15,010 And you have to maintain all of this, of course. 25 00:03:15,700 --> 00:03:29,420 Most people do not want to go to such trouble to get their website running, and therefore they just pay someone to do the job for them, including getting all this working together. 26 00:03:29,420 --> 00:03:42,700 This is the spirit behind cloud hosting, which does provide the device, the hosting, the maintenance, and also the DNS registration and DNS publication. 27 00:03:43,200 --> 00:03:48,120 And this is the main thing we are going to talk about. 28 00:03:51,840 --> 00:03:54,640 Our target today is OVHcloud. 29 00:03:54,640 --> 00:03:59,860 They are the largest French cloud provider, by far, and second in Europe. 30 00:03:59,900 --> 00:04:04,220 And they sell all kinds of cloud-related services. 31 00:04:05,500 --> 00:04:08,720 In particular, they do sell domain names. 32 00:04:08,860 --> 00:04:13,500 And the basic plan for domain names include email redirects. 33 00:04:13,500 --> 00:04:23,250 Namely, it means you do not get a full email account, but you can redirect, contact at your OVHcloud domain to your usual Gmail account. 34 00:04:23,330 --> 00:04:27,330 And as a side note, they do host Wikileaks since 2010. 35 00:04:29,610 --> 00:04:34,930 So let's create an email redirect on the example domain. 36 00:04:34,930 --> 00:04:39,730 Here, dnssection.ovh, which we have just bought for the occasion. 37 00:04:39,830 --> 00:04:51,410 So in the admin panel, we just add a redirect from test.dnssection.ovh to target.yopmail.com and click confirm. 38 00:04:52,390 --> 00:05:01,450 And if we go look at the DNS zone, which we can also find in the admin panel, then we realize there is a new DNS record in there. 39 00:05:01,690 --> 00:05:13,850 If we zoom out this, then we can see that for test.dnssection.ovh, then you have a txt record with a target email, so target.yopmail.com. 40 00:05:14,670 --> 00:05:26,390 So this means that anyone in the world can just query test.dnssection.ovh and get the target of your email redirect. 41 00:05:26,570 --> 00:05:38,730 Obviously, it's not easy to get the whole database because you cannot ask the DNS server for the whole list of subdomains of at.dnssection.ovh. 42 00:05:44,260 --> 00:05:45,960 So why does it matter? 43 00:05:45,960 --> 00:05:47,260 Why do we care? 44 00:05:47,320 --> 00:05:54,600 Well, assume for a moment that we do manage to find a way to access this redirection database. 45 00:05:54,660 --> 00:05:57,360 It does contain a lot of interesting information. 46 00:05:57,360 --> 00:06:03,760 It's actually essentially client information for the users of this cloud hosting service. 47 00:06:03,760 --> 00:06:13,980 It includes emails, of course, but also names and potentially more information, billing information, for instance, with which we can be creative. 48 00:06:13,980 --> 00:06:17,700 We can actually start wondering, okay, what can we do with this information? 49 00:06:17,700 --> 00:06:31,620 Well, we can perhaps spam, we can try password dumps, we can perform social engineering on the basis of this information, we can perhaps find interesting information on the businesses that they hold, and so forth. 50 00:06:31,620 --> 00:06:40,280 So there's really a lot of ideas about what we can do with this information, and we will show you that in the latest part of this talk. 51 00:06:42,420 --> 00:06:56,980 So, well, let's try the naive way to do brute force to recover all the information using just a DNS query directly on the hosts that we are interested in. 52 00:06:56,980 --> 00:07:11,060 So the way we would do that is we get a list of OVH cloud-handled domains, we select those that we are most interested in, get a sublist, and we DNS query these domains. 53 00:07:11,160 --> 00:07:16,880 It works rather well for the domains that are hosted by OVH. 54 00:07:17,380 --> 00:07:23,440 And in doing so, we have two ways essentially to get an interesting redirect email. 55 00:07:23,440 --> 00:07:33,500 Either we look for the public email addresses, the ones that are displayed on the website, and we try to see whether they redirect to something interesting. 56 00:07:33,500 --> 00:07:35,000 This is one way. 57 00:07:35,200 --> 00:07:42,620 The other way is we don't really know what the real address is or whether they are redirects to begin with. 58 00:07:42,620 --> 00:07:54,300 So we, well, we try addresses we think are likely to exist, such as abuse at the domain, admin at contact at the domain. 59 00:07:54,380 --> 00:08:14,120 And in doing so, we, if we get a response, we get not only the existence of this particular email address that we just guessed, but also the corresponding target email redirect, which does not appear either on the website or in that case elsewhere. 60 00:08:15,780 --> 00:08:32,220 Of course, if you just try to do this, you're going to run into trouble because it's very likely that it is not stealthy to just query massively random DNS servers with random email addresses. 61 00:08:32,220 --> 00:08:40,180 So in practice, if you want to do this, you better be clever and avoid rate limiting by using several clients. 62 00:08:40,180 --> 00:08:55,260 But just for the sake of demonstrations, here we can do this from a single host using very simple low-tech devices, including bash and dig and just the file system. 63 00:08:55,260 --> 00:09:04,660 So really, we just run a first script that queries the DNS server to get a lot of interesting information about the domains. 64 00:09:04,660 --> 00:09:12,240 And then we dig the txt record, the one that contains the redirect in our case. 65 00:09:12,780 --> 00:09:15,060 So well, there's a demo for that. 66 00:09:20,710 --> 00:09:23,850 Okay, so let's look at this in action. 67 00:09:23,850 --> 00:09:28,270 You have here the bash script we just showed you. 68 00:09:31,060 --> 00:09:35,940 And we are going to run this very script right now. 69 00:09:38,190 --> 00:09:44,410 It will show addresses we just blurred them for privacy reasons. 70 00:09:44,510 --> 00:09:54,670 So on the left, you have the addresses that we query, and we recover the txt record on the right with the redirection email. 71 00:09:54,830 --> 00:10:03,210 This video is real-time, so it shows you that this is quite fast, in fact, quite efficient. 72 00:10:03,310 --> 00:10:06,170 And we do this from a single host here. 73 00:10:06,190 --> 00:10:12,770 But of course, you can parallelize this effort by calling several addresses at the same time. 74 00:10:18,550 --> 00:10:19,830 So what do we get? 75 00:10:19,830 --> 00:10:21,570 It does work. 76 00:10:21,730 --> 00:10:22,650 It does work. 77 00:10:22,650 --> 00:10:24,090 We do get information. 78 00:10:24,090 --> 00:10:43,910 So if we consider a subset of about 14,000 potentially vulnerable domains in the frtld, what we get is about 15,000 email redirects, of which about 10,000 unique email addresses, something we didn't have before. 79 00:10:43,910 --> 00:10:45,930 So this is extremely interesting. 80 00:10:45,930 --> 00:10:55,710 But you might say, well, we used public emails or easily guessable emails, and we found private redirection emails. 81 00:10:55,890 --> 00:11:00,670 So well, perhaps, I mean, it's interesting, but what are we not seeing? 82 00:11:00,670 --> 00:11:03,210 What are we missing from the picture? 83 00:11:03,470 --> 00:11:07,230 And that's where DNS section comes into play, really. 84 00:11:12,530 --> 00:11:17,390 So what we are going to do is we are going to use DNSSEC. 85 00:11:17,870 --> 00:11:23,050 DNSSEC is in itself a very interesting topic and a very large one. 86 00:11:23,050 --> 00:11:30,250 If we want to go into details, we might as well do a talk entirely on the topic and perhaps even several talks. 87 00:11:30,310 --> 00:11:38,970 So very short summary, what you should know about it is that DNS itself is insecure if you use it like it, just like this. 88 00:11:38,970 --> 00:11:43,750 So you need extensions, which are provided for most of them by DNSSEC. 89 00:11:43,970 --> 00:11:52,230 Every modern good implementation of a DNS server does have support for DNSSEC and so do resolvers. 90 00:11:52,370 --> 00:12:03,010 Essentially, what DNSSEC does is it provides a route of trust and a tree derivation scheme that use public key cryptography, digital signatures to ensure authenticity. 91 00:12:03,010 --> 00:12:14,390 So you know that you are really talking to the server you think you are talking to and that the information provided there is at least the one that it commits to sending. 92 00:12:14,870 --> 00:12:28,950 So it requires cryptographic elements and it requires sometimes some lockpicking skills, as perhaps the recent enough incident depicted here shows, if you know what I'm talking about. 93 00:12:28,950 --> 00:12:35,290 If not, look into what happens in a key rollover session of DNSSEC. 94 00:12:35,730 --> 00:12:44,510 So we can look at this, we can look at the information sent to us by a DNSSEC compatible server. 95 00:12:49,850 --> 00:12:56,950 One tool that we can use to recover information about DNSSEC is DNSViz. 96 00:12:57,050 --> 00:13:03,370 It is available in your favorite browser at dnsviz.net. 97 00:13:05,370 --> 00:13:15,070 So here we apply it to dnssection.ovh, which is the website we use for demonstration purposes during this talk. 98 00:13:15,250 --> 00:13:19,110 It has been slowed down so I can comment on it. 99 00:13:19,110 --> 00:13:22,550 It is actually much faster than this. 100 00:13:26,760 --> 00:13:36,260 It queries all the interesting information about the DNS records here and we can see the full chain of trust for the domain. 101 00:13:37,360 --> 00:13:51,320 So in particular we can see all the cryptographic information, the algorithm in use and we can also see some of the common sub-records that appear in the DNS zone. 102 00:13:51,440 --> 00:13:57,160 SOA, TXT, MX, NS and A records. 103 00:13:58,120 --> 00:14:02,440 You can also see which algorithms have been used. 104 00:14:02,440 --> 00:14:14,900 In this particular case, dnssection.ovh uses DNSSEC with algorithm 8, RSA plus SHA 265 with NSEC3. 105 00:14:18,730 --> 00:14:27,350 And you can go up to the OVH and above zones and see how things are derivated from the root of trust. 106 00:14:27,350 --> 00:14:37,250 Here you can see .ovh switching from algorithm 8 to algorithm 13, one of the 2020 goals for AFNIC. 107 00:14:39,010 --> 00:14:42,450 DNSviz also checks for errors. 108 00:14:42,450 --> 00:14:46,230 Try it on Defcon.org, you will be surprised. 109 00:14:46,530 --> 00:14:52,570 Unless of course the goons have watched our talk in advance and have already fixed it. 110 00:15:02,710 --> 00:15:07,550 Let us dive in a fundamental obstacle of DNSSEC. 111 00:15:07,970 --> 00:15:10,410 Issues with negative responses. 112 00:15:11,090 --> 00:15:13,190 For positive responses, it's quite easy. 113 00:15:13,190 --> 00:15:23,110 If you want to authenticate that the record example.com is at IP 1.2.3.4 exists, then it's quite easy. 114 00:15:23,110 --> 00:15:25,710 You just affix your signature to it. 115 00:15:25,710 --> 00:15:32,470 But if you want to authenticate that there is no record for bad.example.com, this is much trickier. 116 00:15:32,470 --> 00:15:38,130 You obviously cannot put every negative possibility signing in the zone. 117 00:15:38,610 --> 00:15:41,090 This is where NSSEC comes to the rescue. 118 00:15:42,990 --> 00:15:54,490 NSSEC is much more trickier and complicated than what I'm going to explain here, but all you need to understand is the principle depicted in this slide. 119 00:15:54,490 --> 00:16:01,130 So basically NSSEC signs intervals where there is no domain. 120 00:16:01,230 --> 00:16:18,430 For example, it could sign there is no domain between apple.example.com and carrot.example.com in lexicographical order and therefore it means that bad.example.com cannot exist because B is between A and C. 121 00:16:20,070 --> 00:16:29,210 And it does create a big issue so that you can now enumerate all records in the DNS zone. 122 00:16:29,210 --> 00:16:31,010 How to do that is quite easy. 123 00:16:31,010 --> 00:16:39,450 Just pick a random name, for example fgfrd.example.com and query the DNS server for it. 124 00:16:40,270 --> 00:16:55,950 Obviously fgrd does not exist, it's a random name, it will enter the interval associated with it and so here it tells you that there is nothing between carrot.example.com and good.example.com. 125 00:16:55,950 --> 00:17:00,170 Very good, we have just found two subdomains of example.com. 126 00:17:00,170 --> 00:17:12,950 We just repeat with a successor of good, here good A, get another name, another interval, and loop until we've found every positive record in the zone. 127 00:17:12,950 --> 00:17:23,490 So it means that it is trivially doable for an attacker to get the whole DNS zone of an NSEC-enabled domain. 128 00:17:26,950 --> 00:17:32,690 So now you might be thinking okay that's what we're gonna do, we're just gonna use NSEC zone walking. 129 00:17:32,690 --> 00:17:39,230 No, that's not what we're gonna do, because NSEC zone walking doesn't work. 130 00:17:39,230 --> 00:17:46,810 It doesn't work anymore in the real world for the simple reason that no one uses NSEC at all anymore. 131 00:17:47,170 --> 00:17:50,210 Yes, you can be sad about this, it's not what we're gonna do. 132 00:17:50,210 --> 00:17:55,710 We're gonna do something more clever, although not very different, so that's why we talked about it. 133 00:17:57,970 --> 00:18:01,390 What we're gonna do is zone walking with NSEC 3. 134 00:18:01,550 --> 00:18:13,490 NSEC 3 has been designed and implemented and deployed for the very reason of providing resistance against zone enumeration, the way we just described for NSEC. 135 00:18:13,490 --> 00:18:15,390 So it's a patch on NSEC. 136 00:18:15,790 --> 00:18:28,850 In a nutshell, what it does is instead of having the records in plain text, they hash them using several repetitions of the SHA-1 algorithm, usually with sort or without sort. 137 00:18:29,210 --> 00:18:42,330 So the idea is it should hide the contents of the DNS records, and assuming you cannot do anything with hash values, well, you don't get access to them, you cannot enumerate. 138 00:18:42,330 --> 00:18:52,570 The truth is you can still dump the hash itself, so you can still do zone walking, you can still extract the hashes, it still kind of works. 139 00:18:52,810 --> 00:19:00,690 And NSEC 3 is really what is deployed today in the real world, so that's what we are going to attack. 140 00:19:05,050 --> 00:19:13,670 As Remy just explained, the assumption behind NSEC 3 is that reversing even partially the hash is difficult. 141 00:19:13,670 --> 00:19:17,530 Well, in practice, it turns out it's not really true. 142 00:19:17,530 --> 00:19:27,390 You've probably heard about many people trying to break hashes, especially for passwords, and breaking hashes is even basically how you mine Bitcoin. 143 00:19:27,390 --> 00:19:39,810 So I think I'm hearing laughs in the Bitcoin mining farm when they hear that SHA-1 cannot be reversed. 144 00:19:39,810 --> 00:19:51,130 So in practice, for DNSSEC, you can find off-the-shelf readily available tools to crack the NSEC 3 hashes. 145 00:19:51,410 --> 00:19:58,530 However, to the best of our knowledge, it has never been used to dig valuable data. 146 00:19:58,630 --> 00:20:16,130 They only use that for the same demo, which is finding the list of subdomains of .com or .org, but most of the time the list of valuable domains is better found using Google or your favorite search engine. 147 00:20:20,530 --> 00:20:30,350 Okay, so let's show you the NSEC 3 Volcker tool, which is used to get the hashes from the domain zone. 148 00:20:30,490 --> 00:20:34,170 This is actually a collection of scripts. 149 00:20:34,290 --> 00:20:42,330 Here we call the script collect of NSEC 3 Volcker on our dnssection.ovh domain. 150 00:20:46,680 --> 00:20:55,540 It starts by getting the NSEC 3 parameters, which are the salt and the number of SHA-1 iterations. 151 00:20:56,980 --> 00:21:07,620 Then, it is going to crawl through it and try 100 domains to find the intervals as we have explained in the previous slides. 152 00:21:11,820 --> 00:21:15,420 This video has been slowed down a lot. 153 00:21:15,580 --> 00:21:20,680 In practice, with a good network, this is actually really fast. 154 00:21:21,440 --> 00:21:25,020 You even get a progress bar from the tool. 155 00:21:26,060 --> 00:21:32,180 Here, the zone is quite small, so we get all the hashes very quickly. 156 00:21:32,480 --> 00:21:43,620 If you want to dump a TLD zone, I mean top-level domain zone, such as .org, then it takes much much more time. 157 00:21:46,790 --> 00:21:59,190 Another tool, NSEC 3 map, also exists and has advanced features, such as parallel queries and automatic conversion for Hashcat and John the Ripper. 158 00:21:59,790 --> 00:22:06,950 Unfortunately, it has been written in Python 2, which is in the process of going extinct. 159 00:22:07,470 --> 00:22:11,950 So, use whichever tool you feel more comfortable with. 160 00:22:14,640 --> 00:22:20,000 Well, so we have just dumped all the hashes of dnssection.ovh. 161 00:22:20,000 --> 00:22:21,520 What do we do now? 162 00:22:21,520 --> 00:22:24,900 Well, we bring out the GPU rig. 163 00:22:25,260 --> 00:22:27,820 Unfortunately, we don't have a whole datacenter. 164 00:22:27,820 --> 00:22:30,920 We only have a nice Tesla P100. 165 00:22:30,920 --> 00:22:36,060 If you know nothing about GPUs, let's just say this is not a potato GPU. 166 00:22:39,360 --> 00:22:42,700 Most of you have heard about Hashcat before. 167 00:22:42,700 --> 00:22:45,880 This is the standard tool to break hashes. 168 00:22:46,000 --> 00:22:56,720 So, let us just feed the output of NSEC 3 to Hashcat and try different kind of attacks, such as dictionary attacks and brute force attacks. 169 00:22:59,380 --> 00:23:03,720 Here, we show you a little demo of Hashcat. 170 00:23:03,740 --> 00:23:16,020 In this case, this is a simple brute force of all lowercase alphanumeric emails of exactly five characters, as you can see on the command line. 171 00:23:20,470 --> 00:23:32,770 First, Hashcat displays some information about the GPU and compiles the OpenCL NSEC3 kernel tailored for your GPU. 172 00:23:33,450 --> 00:23:38,370 Then, it starts the hash cracking process. 173 00:23:39,150 --> 00:23:45,330 In this case, we only run it on a small subset of our findings. 174 00:23:45,770 --> 00:23:50,710 The video has been sped up to avoid audience boredom. 175 00:23:51,050 --> 00:23:55,630 You can see a few hashes being reversed on the screen. 176 00:23:55,870 --> 00:24:00,910 Again, we blurred the result for privacy reasons. 177 00:24:05,120 --> 00:24:09,400 As a side note, we have found a bug in Hashcat. 178 00:24:09,700 --> 00:24:12,760 Dots were not handled correctly. 179 00:24:13,400 --> 00:24:21,000 Many emails contained dots in the left part, so this proved to be a serious concern for us. 180 00:24:21,680 --> 00:24:28,800 We made a dirty fix for ourselves, and the Hashcat team has since fixed it properly. 181 00:24:28,800 --> 00:24:30,580 Thanks a lot to them. 182 00:24:33,220 --> 00:24:39,880 Let us consider about 16,000 interesting DNSSEC hashed records. 183 00:24:40,000 --> 00:24:48,140 Well, using our GPU, we were able to unhash as much as 88% of them, so that's quite a good result. 184 00:24:48,800 --> 00:24:52,440 Let's see a little breakdown of our results. 185 00:24:52,440 --> 00:25:00,240 So, in three quarters of the cases, we were able to reverse the hash, and we did find an interesting email redirection. 186 00:25:00,360 --> 00:25:06,600 In 14%, we did reverse the hash, but it was something else, such as an FPF record. 187 00:25:06,640 --> 00:25:11,700 And in the remaining 12%, well, we were not able to unhash. 188 00:25:12,460 --> 00:25:21,780 By God's thing, the remaining ones are mostly domain key records, which are not descriptible for email redirections. 189 00:25:23,080 --> 00:25:34,360 A little disclaimer, we are not here to dox people, so obviously, all people names and domain names in the following example have been modified. 190 00:25:38,000 --> 00:25:40,740 Let's look at a few statistics. 191 00:25:41,520 --> 00:25:51,000 So, first, we can just classify the target of the redirection by the email provider they use. 192 00:25:51,140 --> 00:26:00,140 I think you can guess which email provider is used by most webmasters, and this is obviously Gmail.com. 193 00:26:00,900 --> 00:26:17,660 And then, if you look at the left part of the email, well, it does leak the name of the people quite often, because, well, most emails are your name at something, not your country. 194 00:26:17,660 --> 00:26:28,120 So it happens that, in practice, the name of the person is found in the email in about half the time. 195 00:26:28,500 --> 00:26:37,020 However, this doesn't mean that we found some private information on some website, where people happily say that they do run the website. 196 00:26:37,420 --> 00:26:46,160 So we try to find out how often we could not find the name in the target of the redirection on the website. 197 00:26:46,160 --> 00:26:48,840 Well, this is in about two-thirds of the time. 198 00:26:48,840 --> 00:26:59,360 So, in two-thirds of the time, when we have a name in the target of a redirect, then this was not something we could have easily found on website. 199 00:26:59,360 --> 00:27:02,860 So we have leaked some private information. 200 00:27:03,680 --> 00:27:11,240 A little more complicated is how often this email would not appear in a Google search. 201 00:27:11,320 --> 00:27:14,780 And in practice, this is about half of the time. 202 00:27:14,780 --> 00:27:25,060 So this means that there are a lot of emails that are not publicly available, and we did, again, find a lot of private info using them. 203 00:27:26,100 --> 00:27:32,400 The last thing was a little more difficult to identify. 204 00:27:32,500 --> 00:27:38,200 And this is about a business connection, conflict of interest, or fake competitors. 205 00:27:39,040 --> 00:27:47,500 And using the redirection we found, well, we were able to find such things in about one-quarter of the cases. 206 00:27:48,760 --> 00:28:01,980 A little homework for you, that we have not tried, is run the found emails for the haven't-been-pwned database, and find how many of them do have an entry in it. 207 00:28:03,860 --> 00:28:08,820 What if we try to dox a scam on an adult website? 208 00:28:08,900 --> 00:28:11,940 Well, first, please don't tell my wife about it. 209 00:28:12,340 --> 00:28:20,800 Well, we did try to find some names or some business connections, but they are very clever, and it's actually a fail. 210 00:28:20,800 --> 00:28:23,720 Their email never discloses their name. 211 00:28:23,800 --> 00:28:28,460 But we still have the email, so who's the scammer and who's the scammer. 212 00:28:30,720 --> 00:28:32,620 Anything more serious? 213 00:28:32,620 --> 00:28:42,100 Well, we did find some famous people emails, like politicians and showbiz people, which have their own Wikipedia page. 214 00:28:42,540 --> 00:28:57,480 We also found a few emails of activists, and on a much lighter note, we did find a lawyer website with a redirect to, guess what, mylittlepony.hisbirthdate at gmail.com. 215 00:28:58,020 --> 00:29:05,180 And also, we found 50 people who had added redirects for the no-reply at other domain. 216 00:29:05,180 --> 00:29:07,000 Why would they do that? 217 00:29:08,740 --> 00:29:12,800 A little caveat, this is actually some manual analysis. 218 00:29:12,800 --> 00:29:17,860 We went through hundreds of websites phishing for the names and the emails. 219 00:29:17,880 --> 00:29:29,900 So typically, this means going through the contact page, googling the name, googling the emails, and dealing with obscene stuff such as adult flash websites, which are really difficult to navigate through. 220 00:29:29,900 --> 00:29:34,940 So this is all by best effort, and we might have missed some public data. 221 00:29:39,740 --> 00:29:43,440 So okay, we found a lot of interesting information. 222 00:29:43,440 --> 00:29:54,320 Some of it apparently does not appear either on the website or in Google, and very likely was information that was not meant to be made public. 223 00:29:54,440 --> 00:29:57,500 So we thought it was an interesting issue. 224 00:29:57,500 --> 00:30:00,220 We tried to bring it up to OVHcloud. 225 00:30:00,320 --> 00:30:06,020 So we called the hotline, and we're going to tell you about the disclosure process. 226 00:30:06,280 --> 00:30:13,560 So we called the hotline, and we said, okay, we think we have a problem with your handling of private data. 227 00:30:13,560 --> 00:30:17,040 They say, send an email to abuseat. 228 00:30:17,180 --> 00:30:27,820 Okay, so we write the email, and we include the technical details, some of which we just shared with you right now, and we never got a reply. 229 00:30:28,560 --> 00:30:31,940 So well, we were a bit puzzled. 230 00:30:31,940 --> 00:30:35,620 Perhaps we did not understand what they meant by send an email. 231 00:30:35,780 --> 00:30:41,780 So we called them again, and calling them again, they say, yes, do send an email to abuseat. 232 00:30:41,780 --> 00:30:42,880 You did the right thing. 233 00:30:42,880 --> 00:30:43,540 Just do it again. 234 00:30:43,540 --> 00:30:44,540 Perhaps they missed it. 235 00:30:44,540 --> 00:30:50,700 So okay, well, we write a second email, and we never got a reply. 236 00:30:52,600 --> 00:31:05,900 So at that point, what we tried is to contact people working there, try to ping the right person, and to try and get them to forward our email internally to the right people. 237 00:31:07,020 --> 00:31:09,940 Well, to this day, we are still waiting for a response. 238 00:31:09,940 --> 00:31:13,540 So OVH, if you are looking at us, we tried. 239 00:31:16,790 --> 00:31:29,130 Okay, so if you want to fix it, what should you do if you do not want to be targeted by the kind of enumeration and privacy disclosure that we just described? 240 00:31:29,690 --> 00:31:35,270 Turns out that this has been a goal of NSEC for many years now. 241 00:31:35,270 --> 00:31:41,290 This was the reason why NSEC 3 was proposed, and obviously NSEC 3 failed. 242 00:31:41,730 --> 00:31:47,530 But the real, the correct answer to this is use public key cryptography. 243 00:31:47,530 --> 00:31:55,770 It's been described in two RFCs how to do this with NSEC, in a way that's compatible with the NSEC. 244 00:31:55,770 --> 00:32:00,290 And there are two leading implementations of this idea. 245 00:32:00,290 --> 00:32:04,990 One is NSEC 5, which is already six years old now. 246 00:32:05,290 --> 00:32:14,050 And the other is to use NSEC 3 but replace the hash by a public key signature, a digital signature. 247 00:32:14,530 --> 00:32:26,670 The problem is NSEC 5 was met with skepticism in the first draft, and the draft has not been finalized, and it has not been standardized, and it brings latency into the game. 248 00:32:27,030 --> 00:32:30,570 But most importantly, NSEC has a bad track record. 249 00:32:30,570 --> 00:32:39,590 This is already the fifth iteration of it, and you have not heard of NSEC 2 or NSEC 4 in this talk, and you might wonder why. 250 00:32:39,890 --> 00:32:44,410 Well, perhaps they never got to see the light for good reasons. 251 00:32:45,190 --> 00:32:49,690 The alternative is NSEC 3, NSEC 3 with digital signatures. 252 00:32:49,890 --> 00:33:12,450 And today that means ECDSA algorithm 13 in the DNS SEC documentation, mainly because it is the only one that can be used in this list, because it signs fast and the signatures are small enough that it is actually practical to use. 253 00:33:13,130 --> 00:33:26,350 But it's on a fixed curve with a fixed hash function, and it's a bit of an old algorithm, to be honest, which makes, amongst other issues, resolvers carry the burden. 254 00:33:26,350 --> 00:33:33,070 The fact that resolvers now have to perform signature verification, which is actually quite slow. 255 00:33:33,470 --> 00:33:41,790 It also requires very careful implementation and handling of algorithms and keys, because ECDSA is famously brittle. 256 00:33:42,290 --> 00:33:49,770 An experience in the matter shows that DNS servers are, well, historically bad at it. 257 00:33:50,010 --> 00:33:58,170 We gave you a reference on the slide that you can look into about the handling of RSA keys in the past. 258 00:33:59,950 --> 00:34:12,490 Remy has just explained you how to fix DNSSEC, but most people do not want to handle their DNS zone by themselves, and thus use cloud hosting. 259 00:34:12,730 --> 00:34:20,870 So, assume for a second that you are an OVHclose customer, and you are using their redirection features. 260 00:34:21,090 --> 00:34:23,930 How can you protect yourself right now? 261 00:34:24,510 --> 00:34:27,790 Well, there are two different things to protect. 262 00:34:27,870 --> 00:34:31,390 First, the target of the email redirection. 263 00:34:31,530 --> 00:34:36,670 An easy way to hide the real target email is to use double redirects. 264 00:34:37,250 --> 00:34:39,830 Let me explain. 265 00:34:39,830 --> 00:34:51,730 First, redirect test.dnssection.ovh to test.dnssection.gmail.com in the OVHcloud admin panel. 266 00:34:52,010 --> 00:35:02,010 Then, in your Gmail interface, redirect test.dnssection.gmail.com to your personal email address. 267 00:35:02,010 --> 00:35:09,530 An attacker will only be able to see the first redirect, and thus will not learn anything useful. 268 00:35:10,210 --> 00:35:14,730 Second, you want to protect your domain email list. 269 00:35:14,730 --> 00:35:16,750 This is actually quite tricky. 270 00:35:17,850 --> 00:35:21,930 What about disabling DNSSEC entirely? 271 00:35:21,990 --> 00:35:31,030 Well, there is a reason DNSSEC exists, and dropping the security properties of DNSSEC might not be worth it. 272 00:35:31,030 --> 00:35:36,250 Or you may also have services for which DNSSEC use is a must. 273 00:35:36,730 --> 00:35:45,930 Another possibility to protect the list would be to use long and unpredictable emails, so the hash is almost impossible to reverse. 274 00:35:46,570 --> 00:35:51,090 For online websites, this works quite well. 275 00:35:51,090 --> 00:35:53,750 The web server does not care much. 276 00:35:53,930 --> 00:36:02,410 However, a long and non-human friendly email is not going to make a good first impression on your business card. 277 00:36:03,070 --> 00:36:13,470 If your domain email list is especially sensitive, the best way out is probably to stop using vulnerable OVHcloud redirection for now. 278 00:36:13,610 --> 00:36:17,730 Upgrade to an OVHcloud plan with real email addresses. 279 00:36:20,310 --> 00:36:30,390 So, well, that brings us to a conclusion for this talk, which will be rather fast, because you heard most of what we had to say already. 280 00:36:30,390 --> 00:36:39,030 The lesson to remember, do not store private information in your DNS zone if you do not have to. 281 00:36:39,030 --> 00:36:45,710 This is likely to leak unless, well, countermeasures are widely deployed. 282 00:36:46,330 --> 00:36:49,290 DNSSEC and SEC3 attacks exist. 283 00:36:49,290 --> 00:36:56,290 They are practical and they can reveal information that was not obtained in any other way that we know of. 284 00:36:56,290 --> 00:37:06,930 So try to push your local representative for DNS server to adopt modern countermeasures against zone enumeration. 285 00:37:07,250 --> 00:37:09,550 NSEC5 is not yet final. 286 00:37:09,550 --> 00:37:11,270 Try to push for it. 287 00:37:11,270 --> 00:37:17,990 And adoption of ECDSA as a signature for zone enumeration is also on the way. 288 00:37:17,990 --> 00:37:20,550 But, you know, it's taking time. 289 00:37:20,550 --> 00:37:22,070 So try and get there. 290 00:37:22,070 --> 00:37:23,870 That's all we had to say. 291 00:37:24,190 --> 00:37:30,150 And do have a look at the Proof of Concept website that we put up for you to play with. 292 00:37:31,450 --> 00:37:32,870 Thank you again. 293 00:37:32,870 --> 00:37:35,650 Have a great day and try this at home. 294 00:37:36,070 --> 00:37:37,890 Very carefully, of course. 295 00:37:38,150 --> 00:37:38,990 Bye-bye.