[00:03.210 --> 00:08.360] Hello DEF CON, welcome to our talk DNS section. [00:09.280 --> 00:17.080] Today will be an interesting talk about DNS and the workings of the internet and cryptography. [00:17.480 --> 00:26.040] So what this talk is about is about an email privacy breach in the largest French cloud provider [00:26.730 --> 00:32.560] which is also the first practical attack on NSEC, DNS Secure Zone Working. [00:32.660 --> 00:38.180] And finally it's a cautionary tale about the use of hash functions. [00:39.400 --> 00:46.240] Why this matters is because DNS is everywhere, it's part of the internet, it's heavily used, [00:46.240 --> 00:51.780] it's very important and there are tons of potentially very valuable interesting data [00:51.780 --> 00:59.140] all over the place. The other reason why it matters is that zone working has not been demonstrated [00:59.140 --> 01:05.260] in the wild to this extent before and it's the first time that we actually recover very valuable [01:05.260 --> 01:18.100] interesting data from it. Who we are? Well this is Adrien. Hello! And I'm Rémy. We are from Ecole [01:18.100 --> 01:24.880] Normale Supérieure, PSL University in Paris, France, in the beautiful place itself. And this [01:24.880 --> 01:31.620] is not the first time that we talk at DEFCON. This has been done in collaboration with Amaury [01:31.620 --> 01:40.340] Barral and David Nekash. So without further ado let's start with the first part of our talk. [01:44.780 --> 01:50.980] So to understand DNS it's very important to understand our talk. We're going to start with [01:50.980 --> 01:59.620] that. The basic question that you ask with DNS is who is behind a website such as skytalk-vids.com [01:59.620 --> 02:07.060] for instance. So DNS, the domain name system, is a system to name remote resources, to give you [02:07.060 --> 02:13.800] access to them, and it does that by holding a distributed database. A system that contains [02:14.360 --> 02:19.100] record resources and domain names and that allows resolvers [02:19.650 --> 02:25.600] to figure out the translation between a domain name and an IP address. [02:26.440 --> 02:32.860] The DNS tree itself is subdivided into subtrees that are called zones and are [02:32.860 --> 02:39.720] administrated by different people, different entities, whose role it is to keep it up to date. [02:39.720 --> 02:47.680] So when you want to, say, build a website, create a new website, well, you actually need to go [02:47.680 --> 02:52.680] through several steps. Once you have a device and you have a server and you have a website running [02:52.680 --> 03:01.400] on it, you need to add your device, your IP address, to a DNS server. And to do that you [03:01.400 --> 03:09.880] call a registrar and you run a DNS server that advertises your IP in connection to the domain [03:09.880 --> 03:15.010] name that you are interested in. And you have to maintain all of this, of course. [03:15.700 --> 03:20.700] Most people do not want to go to such trouble to get their website running, [03:20.700 --> 03:25.420] and therefore they just pay someone to do the job for them, [03:25.420 --> 03:32.680] including getting all this working together. This is the spirit behind cloud hosting, [03:32.680 --> 03:40.740] which does provide the device, the hosting, the maintenance, and also the DNS registration and DNS [03:41.260 --> 03:48.120] publication. And this is the main thing we are going to talk about. [03:51.840 --> 03:58.140] Our target today is OVHcloud. They are the largest French cloud provider, by far, [03:58.140 --> 04:04.220] and second in Europe. And they sell all kinds of cloud-related services. [04:05.500 --> 04:12.200] In particular, they do sell domain names. And the basic plan for domain names include email [04:12.800 --> 04:17.770] redirects. Namely, it means you do not get a full email account, but you can redirect, [04:17.770 --> 04:23.250] contact at your OVHcloud domain to your usual Gmail account. [04:23.330 --> 04:27.330] And as a side note, they do host Wikileaks since 2010. [04:29.610 --> 04:36.810] So let's create an email redirect on the example domain. Here, dnssection.ovh, [04:36.810 --> 04:44.150] which we have just bought for the occasion. So in the admin panel, we just add a redirect from [04:44.150 --> 04:54.830] test.dnssection.ovh to target.yopmail.com and click confirm. And if we go look at the DNS zone, [04:54.830 --> 05:01.450] which we can also find in the admin panel, then we realize there is a new DNS record in there. [05:01.690 --> 05:08.470] If we zoom out this, then we can see that for test.dnssection.ovh, [05:08.470 --> 05:13.850] then you have a txt record with a target email, so target.yopmail.com. [05:14.670 --> 05:24.730] So this means that anyone in the world can just query test.dnssection.ovh and get the target of [05:24.730 --> 05:31.170] your email redirect. Obviously, it's not easy to get the whole database because you cannot ask [05:31.170 --> 05:38.730] the DNS server for the whole list of subdomains of at.dnssection.ovh. [05:44.260 --> 05:50.960] So why does it matter? Why do we care? Well, assume for a moment that we do manage to find a [05:50.960 --> 05:57.740] way to access this redirection database. It does contain a lot of interesting information. It's [05:57.740 --> 06:04.000] actually essentially client information for the users of this cloud hosting service. [06:04.000 --> 06:09.760] It includes emails, of course, but also names and potentially more information, [06:09.760 --> 06:14.500] billing information, for instance, with which we can be creative. We can actually [06:14.500 --> 06:20.380] start wondering, okay, what can we do with this information? Well, we can perhaps spam, we can [06:20.380 --> 06:26.300] try password dumps, we can perform social engineering on the basis of this information, [06:26.300 --> 06:31.620] we can perhaps find interesting information on the businesses that they hold, and so forth. [06:31.620 --> 06:36.320] So there's really a lot of ideas about what we can do with this information, [06:36.320 --> 06:40.280] and we will show you that in the latest part of this talk. [06:42.420 --> 06:51.400] So, well, let's try the naive way to do brute force to recover all the information using just [06:51.860 --> 06:59.020] a DNS query directly on the hosts that we are interested in. So the way we would do that is we [06:59.020 --> 07:06.640] get a list of OVH cloud-handled domains, we select those that we are most interested in, [07:06.640 --> 07:14.540] get a sublist, and we DNS query these domains. It works rather well for the domains that are [07:14.540 --> 07:23.440] hosted by OVH. And in doing so, we have two ways essentially to get an interesting redirect email. [07:23.440 --> 07:30.000] Either we look for the public email addresses, the ones that are displayed on the website, [07:30.000 --> 07:35.560] and we try to see whether they redirect to something interesting. This is one way. The [07:35.560 --> 07:41.840] other way is we don't really know what the real address is or whether they are redirects to begin [07:41.840 --> 07:50.100] with. So we, well, we try addresses we think are likely to exist, such as abuse at the domain, [07:50.100 --> 07:57.980] admin at contact at the domain. And in doing so, we, if we get a response, [07:57.980 --> 08:03.820] we get not only the existence of this particular email address that we just guessed, but also the [08:03.820 --> 08:12.300] corresponding target email redirect, which does not appear either on the website or in that case [08:13.000 --> 08:18.960] elsewhere. Of course, if you just try to do this, you're going to run into trouble [08:19.500 --> 08:28.180] because it's very likely that it is not stealthy to just query massively random DNS [08:29.160 --> 08:35.180] servers with random email addresses. So in practice, if you want to do this, you better be [08:35.180 --> 08:42.400] clever and avoid rate limiting by using several clients. But just for the sake of demonstrations, [08:43.280 --> 08:50.120] here we can do this from a single host using very simple low-tech devices, including [08:50.800 --> 08:59.140] bash and dig and just the file system. So really, we just run a first script that [08:59.140 --> 09:07.140] queries the DNS server to get a lot of interesting information about the domains. And then we dig the [09:07.140 --> 09:15.060] txt record, the one that contains the redirect in our case. So well, there's a demo for that. [09:20.710 --> 09:28.270] Okay, so let's look at this in action. You have here the bash script we just showed you. [09:31.060 --> 09:41.510] And we are going to run this very script right now. It will show addresses we just blurred them [09:41.510 --> 09:47.730] for privacy reasons. So on the left, you have the addresses that we query, [09:47.730 --> 09:57.410] and we recover the txt record on the right with the redirection email. This video is real-time, [09:57.410 --> 10:05.270] so it shows you that this is quite fast, in fact, quite efficient. And we do this from a single host [10:05.270 --> 10:11.790] here. But of course, you can parallelize this effort by calling several addresses at the same [10:11.790 --> 10:25.810] time. So what do we get? It does work. It does work. We do get information. So if we consider [10:26.010 --> 10:34.910] a subset of about 14,000 potentially vulnerable domains in the frtld, what we get is about [10:34.910 --> 10:42.990] 15,000 email redirects, of which about 10,000 unique email addresses, something we didn't have [10:42.990 --> 10:50.150] before. So this is extremely interesting. But you might say, well, we used public emails or [10:50.150 --> 10:57.830] easily guessable emails, and we found private redirection emails. So well, perhaps, I mean, [10:57.830 --> 11:03.930] it's interesting, but what are we not seeing? What are we missing from the picture? And that's [11:03.930 --> 11:16.130] where DNS section comes into play, really. So what we are going to do is we are going to use [11:16.130 --> 11:24.070] DNSSEC. DNSSEC is in itself a very interesting topic and a very large one. If we want to go into [11:24.070 --> 11:30.550] details, we might as well do a talk entirely on the topic and perhaps even several talks. So [11:31.170 --> 11:36.770] very short summary, what you should know about it is that DNS itself is insecure if you use it like [11:36.770 --> 11:43.750] it, just like this. So you need extensions, which are provided for most of them by DNSSEC. [11:43.970 --> 11:50.770] Every modern good implementation of a DNS server does have support for DNSSEC and so do [11:50.770 --> 11:57.230] resolvers. Essentially, what DNSSEC does is it provides a route of trust and a tree derivation [11:57.230 --> 12:03.610] scheme that use public key cryptography, digital signatures to ensure authenticity. So you know [12:03.610 --> 12:08.610] that you are really talking to the server you think you are talking to and that the information [12:08.610 --> 12:16.730] provided there is at least the one that it commits to sending. So it requires cryptographic [12:16.730 --> 12:24.890] elements and it requires sometimes some lockpicking skills, as perhaps the recent enough [12:24.890 --> 12:31.650] incident depicted here shows, if you know what I'm talking about. If not, look into what happens [12:31.650 --> 12:40.090] in a key rollover session of DNSSEC. So we can look at this, we can look at the information [12:40.090 --> 12:53.490] sent to us by a DNSSEC compatible server. One tool that we can use to recover information [12:53.490 --> 13:03.370] about DNSSEC is DNSViz. It is available in your favorite browser at dnsviz.net. [13:05.370 --> 13:12.550] So here we apply it to dnssection.ovh, which is the website we use for demonstration [13:12.550 --> 13:21.010] purposes during this talk. It has been slowed down so I can comment on it. It is actually much faster [13:21.010 --> 13:31.740] than this. It queries all the interesting information about the DNS records here [13:31.740 --> 13:36.260] and we can see the full chain of trust for the domain. [13:37.360 --> 13:45.400] So in particular we can see all the cryptographic information, the algorithm in use and we can also [13:45.400 --> 13:57.160] see some of the common sub-records that appear in the DNS zone. SOA, TXT, MX, NS and A records. [13:58.120 --> 14:05.820] You can also see which algorithms have been used. In this particular case, dnssection.ovh [14:05.820 --> 14:21.250] uses DNSSEC with algorithm 8, RSA plus SHA 265 with NSEC3. And you can go up to the OVH [14:21.250 --> 14:29.650] and above zones and see how things are derivated from the root of trust. Here you can see .ovh [14:29.650 --> 14:37.250] switching from algorithm 8 to algorithm 13, one of the 2020 goals for AFNIC. [14:39.010 --> 14:46.230] DNSviz also checks for errors. Try it on Defcon.org, you will be surprised. [14:46.530 --> 14:52.570] Unless of course the goons have watched our talk in advance and have already fixed it. [15:02.710 --> 15:10.410] Let us dive in a fundamental obstacle of DNSSEC. Issues with negative responses. [15:11.090 --> 15:16.610] For positive responses, it's quite easy. If you want to authenticate that the record example.com [15:16.610 --> 15:25.710] is at IP 1.2.3.4 exists, then it's quite easy. You just affix your signature to it. [15:25.710 --> 15:30.770] But if you want to authenticate that there is no record for bad.example.com, [15:30.770 --> 15:38.130] this is much trickier. You obviously cannot put every negative possibility signing in the zone. [15:38.610 --> 15:41.090] This is where NSSEC comes to the rescue. [15:42.990 --> 15:49.330] NSSEC is much more trickier and complicated than what I'm going to explain here, but all you need [15:49.330 --> 15:56.490] to understand is the principle depicted in this slide. So basically NSSEC signs [15:57.450 --> 16:03.590] intervals where there is no domain. For example, it could sign there is no domain [16:03.590 --> 16:12.050] between apple.example.com and carrot.example.com in lexicographical order and therefore it means [16:12.050 --> 16:18.430] that bad.example.com cannot exist because B is between A and C. [16:20.070 --> 16:29.210] And it does create a big issue so that you can now enumerate all records in the DNS zone. [16:29.210 --> 16:36.390] How to do that is quite easy. Just pick a random name, for example fgfrd.example.com [16:36.390 --> 16:44.350] and query the DNS server for it. Obviously fgrd does not exist, it's a random name, [16:44.350 --> 16:51.010] it will enter the interval associated with it and so here it tells you that there is nothing [16:51.010 --> 16:58.450] between carrot.example.com and good.example.com. Very good, we have just found two subdomains [16:58.450 --> 17:06.050] of example.com. We just repeat with a successor of good, here good A, get another name, [17:06.050 --> 17:12.950] another interval, and loop until we've found every positive record in the zone. [17:12.950 --> 17:20.210] So it means that it is trivially doable for an attacker to get the whole DNS zone [17:20.210 --> 17:30.210] of an NSEC-enabled domain. So now you might be thinking okay that's what we're gonna do, [17:30.210 --> 17:35.290] we're just gonna use NSEC zone walking. No, that's not what we're gonna do, [17:35.890 --> 17:40.750] because NSEC zone walking doesn't work. It doesn't work anymore in the real [17:41.410 --> 17:48.690] world for the simple reason that no one uses NSEC at all anymore. Yes, you can be sad about this, [17:48.690 --> 17:52.170] it's not what we're gonna do. We're gonna do something more clever, [17:52.170 --> 17:55.710] although not very different, so that's why we talked about it. [17:57.970 --> 18:05.130] What we're gonna do is zone walking with NSEC 3. NSEC 3 has been designed and implemented and [18:05.130 --> 18:11.530] deployed for the very reason of providing resistance against zone enumeration, the way [18:11.530 --> 18:18.490] we just described for NSEC. So it's a patch on NSEC. In a nutshell, what it does is instead of [18:18.490 --> 18:26.190] having the records in plain text, they hash them using several repetitions of the SHA-1 algorithm, [18:26.190 --> 18:35.070] usually with sort or without sort. So the idea is it should hide the contents of the DNS records, [18:35.890 --> 18:40.890] and assuming you cannot do anything with hash values, well, you don't get access to them, [18:40.890 --> 18:46.630] you cannot enumerate. The truth is you can still dump the hash itself, so you can still [18:46.630 --> 18:53.470] do zone walking, you can still extract the hashes, it still kind of works. And NSEC 3 [18:53.470 --> 19:00.690] is really what is deployed today in the real world, so that's what we are going to attack. [19:05.050 --> 19:12.170] As Remy just explained, the assumption behind NSEC 3 is that reversing even partially the hash [19:12.170 --> 19:18.870] is difficult. Well, in practice, it turns out it's not really true. You've probably heard about [19:18.870 --> 19:25.610] many people trying to break hashes, especially for passwords, and breaking hashes is even basically [19:25.610 --> 19:36.750] how you mine Bitcoin. So I think I'm hearing laughs in the Bitcoin mining farm when they hear [19:36.750 --> 19:46.910] that SHA-1 cannot be reversed. So in practice, for DNSSEC, you can find off-the-shelf readily [19:46.910 --> 19:54.890] available tools to crack the NSEC 3 hashes. However, to the best of our knowledge, it has [19:54.890 --> 20:03.910] never been used to dig valuable data. They only use that for the same demo, which is finding the [20:03.910 --> 20:11.530] list of subdomains of .com or .org, but most of the time the list of valuable domains is [20:11.530 --> 20:24.470] better found using Google or your favorite search engine. Okay, so let's show you the NSEC 3 [20:24.470 --> 20:32.530] Volcker tool, which is used to get the hashes from the domain zone. This is actually a collection [20:32.530 --> 20:42.330] of scripts. Here we call the script collect of NSEC 3 Volcker on our dnssection.ovh domain. [20:46.680 --> 20:55.540] It starts by getting the NSEC 3 parameters, which are the salt and the number of SHA-1 iterations. [20:56.980 --> 21:05.560] Then, it is going to crawl through it and try 100 domains to find the intervals as we have explained [21:05.560 --> 21:18.360] in the previous slides. This video has been slowed down a lot. In practice, with a good network, [21:18.360 --> 21:27.700] this is actually really fast. You even get a progress bar from the tool. Here, the zone is [21:27.700 --> 21:35.860] quite small, so we get all the hashes very quickly. If you want to dump a TLD zone, I mean [21:35.860 --> 21:49.290] top-level domain zone, such as .org, then it takes much much more time. Another tool, NSEC 3 map, [21:49.290 --> 21:56.190] also exists and has advanced features, such as parallel queries and automatic conversion [21:56.190 --> 22:04.450] for Hashcat and John the Ripper. Unfortunately, it has been written in Python 2, which is in the [22:04.450 --> 22:11.950] process of going extinct. So, use whichever tool you feel more comfortable with. [22:14.640 --> 22:22.000] Well, so we have just dumped all the hashes of dnssection.ovh. What do we do now? Well, [22:22.000 --> 22:27.820] we bring out the GPU rig. Unfortunately, we don't have a whole datacenter. [22:27.820 --> 22:34.500] We only have a nice Tesla P100. If you know nothing about GPUs, let's just say this is not [22:34.720 --> 22:44.240] a potato GPU. Most of you have heard about Hashcat before. This is the standard tool [22:44.240 --> 22:51.660] to break hashes. So, let us just feed the output of NSEC 3 to Hashcat and try different [22:51.660 --> 22:56.720] kind of attacks, such as dictionary attacks and brute force attacks. [22:59.380 --> 23:08.220] Here, we show you a little demo of Hashcat. In this case, this is a simple brute force of all [23:08.220 --> 23:16.020] lowercase alphanumeric emails of exactly five characters, as you can see on the command line. [23:20.470 --> 23:29.970] First, Hashcat displays some information about the GPU and compiles the OpenCL NSEC3 kernel [23:29.970 --> 23:38.370] tailored for your GPU. Then, it starts the hash cracking process. [23:39.150 --> 23:47.830] In this case, we only run it on a small subset of our findings. The video has been sped up [23:47.830 --> 23:55.630] to avoid audience boredom. You can see a few hashes being reversed on the screen. [23:55.870 --> 24:09.400] Again, we blurred the result for privacy reasons. As a side note, we have found a bug in Hashcat. [24:09.700 --> 24:17.220] Dots were not handled correctly. Many emails contained dots in the left part, [24:17.220 --> 24:24.720] so this proved to be a serious concern for us. We made a dirty fix for ourselves, [24:24.720 --> 24:30.580] and the Hashcat team has since fixed it properly. Thanks a lot to them. [24:33.220 --> 24:42.640] Let us consider about 16,000 interesting DNSSEC hashed records. Well, using our GPU, [24:42.640 --> 24:48.140] we were able to unhash as much as 88% of them, so that's quite a good result. [24:48.800 --> 24:54.340] Let's see a little breakdown of our results. So, in three quarters of the cases, [24:54.340 --> 25:00.240] we were able to reverse the hash, and we did find an interesting email redirection. [25:00.360 --> 25:06.600] In 14%, we did reverse the hash, but it was something else, such as an FPF record. [25:06.640 --> 25:11.700] And in the remaining 12%, well, we were not able to unhash. [25:12.460 --> 25:17.720] By God's thing, the remaining ones are mostly domain key records, [25:17.720 --> 25:21.780] which are not descriptible for email redirections. [25:23.080 --> 25:30.480] A little disclaimer, we are not here to dox people, so obviously, all people names and [25:30.480 --> 25:40.740] domain names in the following example have been modified. Let's look at a few statistics. [25:41.520 --> 25:51.000] So, first, we can just classify the target of the redirection by the email provider they use. [25:51.140 --> 25:57.700] I think you can guess which email provider is used by most webmasters, and this is obviously [25:57.700 --> 26:07.420] Gmail.com. And then, if you look at the left part of the email, well, it does leak the name [26:07.420 --> 26:15.320] of the people quite often, because, well, most emails are your name at something, [26:15.320 --> 26:25.380] not your country. So it happens that, in practice, the name of the person is found in the email in [26:26.060 --> 26:32.480] about half the time. However, this doesn't mean that we found some private information [26:33.100 --> 26:37.020] on some website, where people happily say that they do run the website. [26:37.420 --> 26:44.640] So we try to find out how often we could not find the name in the target of the redirection [26:44.640 --> 26:50.880] on the website. Well, this is in about two-thirds of the time. So, in two-thirds of the time, when [26:50.880 --> 26:58.180] we have a name in the target of a redirect, then this was not something we could have easily found [26:58.180 --> 27:05.940] on website. So we have leaked some private information. A little more complicated is [27:05.940 --> 27:14.340] how often this email would not appear in a Google search. And in practice, this is about half of the [27:14.340 --> 27:21.900] time. So this means that there are a lot of emails that are not publicly available, and we did, [27:21.900 --> 27:30.260] again, find a lot of private info using them. The last thing was a little more difficult to [27:31.120 --> 27:37.020] identify. And this is about a business connection, conflict of interest, or fake [27:37.020 --> 27:45.600] competitors. And using the redirection we found, well, we were able to find such things in about [27:45.600 --> 27:54.340] one-quarter of the cases. A little homework for you, that we have not tried, is run the found [27:54.340 --> 28:01.980] emails for the haven't-been-pwned database, and find how many of them do have an entry in it. [28:03.860 --> 28:11.940] What if we try to dox a scam on an adult website? Well, first, please don't tell my wife about it. [28:12.340 --> 28:19.120] Well, we did try to find some names or some business connections, but they are very clever, [28:19.120 --> 28:23.720] and it's actually a fail. Their email never discloses their name. [28:23.800 --> 28:28.460] But we still have the email, so who's the scammer and who's the scammer. [28:30.720 --> 28:36.480] Anything more serious? Well, we did find some famous people emails, like politicians [28:37.040 --> 28:44.960] and showbiz people, which have their own Wikipedia page. We also found a few emails of [28:44.960 --> 28:51.920] activists, and on a much lighter note, we did find a lawyer website with a redirect to, [28:51.920 --> 29:00.820] guess what, mylittlepony.hisbirthdate at gmail.com. And also, we found 50 people who [29:00.820 --> 29:07.000] had added redirects for the no-reply at other domain. Why would they do that? [29:08.740 --> 29:15.020] A little caveat, this is actually some manual analysis. We went through hundreds of websites [29:15.020 --> 29:19.780] phishing for the names and the emails. So typically, this means going through the contact [29:19.780 --> 29:24.980] page, googling the name, googling the emails, and dealing with obscene stuff such as adult [29:24.980 --> 29:31.940] flash websites, which are really difficult to navigate through. So this is all by best effort, [29:31.940 --> 29:43.440] and we might have missed some public data. So okay, we found a lot of interesting information. [29:43.440 --> 29:51.080] Some of it apparently does not appear either on the website or in Google, and very likely was [29:51.080 --> 29:57.620] information that was not meant to be made public. So we thought it was an interesting issue. We [29:57.620 --> 30:04.480] tried to bring it up to OVHcloud. So we called the hotline, and we're going to tell you about [30:04.480 --> 30:09.780] the disclosure process. So we called the hotline, and we said, okay, we think we have a problem [30:10.560 --> 30:19.920] with your handling of private data. They say, send an email to abuseat. Okay, so we write the email, [30:19.920 --> 30:25.020] and we include the technical details, some of which we just shared with you right now, [30:25.020 --> 30:33.300] and we never got a reply. So well, we were a bit puzzled. Perhaps we did not understand [30:33.300 --> 30:39.980] what they meant by send an email. So we called them again, and calling them again, they say, yes, [30:39.980 --> 30:44.540] do send an email to abuseat. You did the right thing. Just do it again. Perhaps they missed it. [30:44.540 --> 30:50.700] So okay, well, we write a second email, and we never got a reply. [30:52.600 --> 30:59.540] So at that point, what we tried is to contact people working there, try to ping the right [30:59.540 --> 31:05.900] person, and to try and get them to forward our email internally to the right people. [31:07.020 --> 31:12.480] Well, to this day, we are still waiting for a response. So OVH, if you are looking at us, [31:12.480 --> 31:22.290] we tried. Okay, so if you want to fix it, what should you do if you do not want to be [31:22.810 --> 31:29.130] targeted by the kind of enumeration and privacy disclosure that we just described? [31:29.690 --> 31:36.710] Turns out that this has been a goal of NSEC for many years now. This was the reason why [31:36.710 --> 31:44.530] NSEC 3 was proposed, and obviously NSEC 3 failed. But the real, the correct answer [31:45.090 --> 31:52.410] to this is use public key cryptography. It's been described in two RFCs how to do this with [31:52.410 --> 31:59.390] NSEC, in a way that's compatible with the NSEC. And there are two leading implementations of this [31:59.390 --> 32:08.730] idea. One is NSEC 5, which is already six years old now. And the other is to use NSEC 3 but replace [32:08.730 --> 32:18.310] the hash by a public key signature, a digital signature. The problem is NSEC 5 was met with [32:18.310 --> 32:24.550] skepticism in the first draft, and the draft has not been finalized, and it has not been standardized, [32:24.550 --> 32:30.850] and it brings latency into the game. But most importantly, NSEC has a bad track record. This is [32:30.850 --> 32:38.070] already the fifth iteration of it, and you have not heard of NSEC 2 or NSEC 4 in this talk, and [32:38.070 --> 32:46.070] you might wonder why. Well, perhaps they never got to see the light for good reasons. The alternative [32:46.070 --> 32:55.450] is NSEC 3, NSEC 3 with digital signatures. And today that means ECDSA algorithm 13 in the DNS [32:55.990 --> 33:04.310] SEC documentation, mainly because it is the only one that can be used in this list, [33:05.330 --> 33:12.450] because it signs fast and the signatures are small enough that it is actually practical to use. [33:13.130 --> 33:19.570] But it's on a fixed curve with a fixed hash function, and it's a bit of an old algorithm, [33:19.570 --> 33:26.830] to be honest, which makes, amongst other issues, resolvers carry the burden. The fact that [33:26.830 --> 33:33.070] resolvers now have to perform signature verification, which is actually quite slow. [33:33.470 --> 33:39.570] It also requires very careful implementation and handling of algorithms and keys, because ECDSA [33:39.570 --> 33:47.570] is famously brittle. An experience in the matter shows that DNS servers are, well, [33:47.570 --> 33:53.510] historically bad at it. We gave you a reference on the slide that you can look into [33:54.030 --> 34:04.870] about the handling of RSA keys in the past. Remy has just explained you how to fix DNSSEC, [34:04.870 --> 34:12.490] but most people do not want to handle their DNS zone by themselves, and thus use cloud hosting. [34:12.730 --> 34:19.630] So, assume for a second that you are an OVHclose customer, and you are using their redirection [34:19.630 --> 34:27.790] features. How can you protect yourself right now? Well, there are two different things to protect. [34:27.870 --> 34:33.790] First, the target of the email redirection. An easy way to hide the real target email [34:33.790 --> 34:43.970] is to use double redirects. Let me explain. First, redirect test.dnssection.ovh [34:43.970 --> 34:54.890] to test.dnssection.gmail.com in the OVHcloud admin panel. Then, in your Gmail interface, [34:54.890 --> 35:03.510] redirect test.dnssection.gmail.com to your personal email address. An attacker will only [35:03.510 --> 35:09.530] be able to see the first redirect, and thus will not learn anything useful. [35:10.210 --> 35:16.750] Second, you want to protect your domain email list. This is actually quite tricky. [35:17.850 --> 35:26.070] What about disabling DNSSEC entirely? Well, there is a reason DNSSEC exists, [35:26.070 --> 35:32.130] and dropping the security properties of DNSSEC might not be worth it. Or you may also have [35:32.130 --> 35:39.010] services for which DNSSEC use is a must. Another possibility to protect the list [35:39.010 --> 35:45.930] would be to use long and unpredictable emails, so the hash is almost impossible to reverse. [35:46.570 --> 35:54.870] For online websites, this works quite well. The web server does not care much. However, [35:55.070 --> 36:00.150] a long and non-human friendly email is not going to make a good first impression [36:00.150 --> 36:08.290] on your business card. If your domain email list is especially sensitive, the best way out is [36:08.290 --> 36:15.570] probably to stop using vulnerable OVHcloud redirection for now. Upgrade to an OVHcloud plan [36:15.570 --> 36:24.370] with real email addresses. So, well, that brings us to a conclusion for this talk, [36:24.370 --> 36:30.390] which will be rather fast, because you heard most of what we had to say already. [36:30.390 --> 36:38.330] The lesson to remember, do not store private information in your DNS zone if you do not have [36:38.330 --> 36:47.270] to. This is likely to leak unless, well, countermeasures are widely deployed. DNSSEC and [36:47.270 --> 36:52.930] SEC3 attacks exist. They are practical and they can reveal information that was not obtained in [36:52.930 --> 37:02.110] any other way that we know of. So try to push your local representative for DNS server to adopt [37:02.110 --> 37:11.270] modern countermeasures against zone enumeration. NSEC5 is not yet final. Try to push for it. [37:11.270 --> 37:18.810] And adoption of ECDSA as a signature for zone enumeration is also on the way. But, you know, [37:18.810 --> 37:25.310] it's taking time. So try and get there. That's all we had to say. And do have a look [37:25.310 --> 37:30.150] at the Proof of Concept website that we put up for you to play with. [37:31.450 --> 37:38.990] Thank you again. Have a great day and try this at home. Very carefully, of course. Bye-bye.