 Hello DevCon. Welcome to our talk, DNS section. Today will be an interesting talk about DNS and the workings of the internet and cryptography. So what this talk is about is about Animal Privacy Bridge in the largest French cloud provider, which is also the first practical attack on NSEC, DNS Secrets on Walking. And finally it's a cautionary tale about the use of hash functions. 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. The other reason why it matters is that zone walking has not been demonstrated in the wild to this extent before and this is the first time that we actually recover very valuable interesting data from it. Who we are? Well this is Adrien. Hello and I'm Rémy. We are from École Normale Supérieure, PSL University in Paris, France in the beautiful place itself and this is not the first time that we talk at DevCon. This has been done in collaboration with Amour Ibaral and David Nakash. So without further ado, let's start with the first part of our talk. So to understand DNS is very important to understand our talk. We're going to start with that. The basic question that you ask with DNS is who's behind a website such as skytalk-fits.com for instance. 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, 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. 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. So when you want to say build a website, create a new website, well you actually need to go through several steps. 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 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 into and you have to maintain all of this of course. 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. This is the spirit behind cloud hosting which does provide the device, the hosting, the maintenance and also the DNS registration and DNS publication and this is the main thing we are going to talk about. Our target today is OVH cloud, they are the largest French cloud provider by far and second in Europe and they sell all kinds of cloud related services in particular they do sell domain names and the basic plan for domain names include email redirects, namely it means you do not get a full email account but you can redirect like contact at your OVH cloud domain to your usual Gmail account and as a side note they do host WikiLeaks since 2010. So let's create an email redirect on the example domain here dnssection.ovh which we have just bought for the occasion so in the admin panel we just add a redirect from test at dnssection.ovh to target at jobmail.com and click confirm 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. If we zoom of this then we can see that for test at dnssection.ovh and you have a TXT record with a target email so target at jobmail.com. So this means that anyone in the world can just query a test at dnssection.ovh and get the target of your email redirect. Obviously it's not easy to get the whole database because you cannot ask the dns server so the whole list of subdomains of ad.dnssection.ovh. So why does it matter? Why do we care? Well assume for a moment that we do manage to find a way to access this redirection database. It does contain a lot of interesting information and it's actually essentially client information for the users of this cloud hosting service. It includes emails of course but also names and potentially more information billing information for instance which with with which we can be creative we can actually start wondering okay what can we do with this information? Well we can perhaps spam, we can we can try password dumps, we can perform social engineering on the basis of these informations, we can perhaps find interesting information on the businesses that they hold and so forth. 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. So well let's try to naive way to do brute force to recover all the information using just a dns query directly on the on the hosts that we are interested in. So the way we would do that is we get a list of vhcloud handle domains. We select those that we are most interested in, get a sublist and we dns query these domains. It works rather well for the domains that are hosted by ovh and in doing so we have two ways essentially to get an interesting redirect email. 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. This is one way. The other way is we don't really know what the real address is or whether there are redirects to begin with so we well we try addresses we think are likely to exist such as abuse at the domain, admin at contact at the domain 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. 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 so in practice if you want to do this you better be clever and avoid trade limiting by using several clients but just for the sake of demonstrations here we cannot do this from a single host using very simple low-tech devices including bash and dig and just the file system so really we just run a first script that queries the dns server to get a lot of interesting information about the domains and then we dig the txt record the one that contains the redirect in our case so well there's a demo for that okay so let's look at this in action you have here the the bash script we just showed you and we are going to run this very script right now it will show addresses we just blurred them for privacy reasons so on the left you have the addresses that we query and we recover the txt record on the right with the redirection email this video is real-time so it shows you that this is quite fast in fact quite efficient and we do this from a single host here but of course you can parallelize this effort by calling several addresses at the same time so what do we get it it does work it does work we do get information so if we if we consider a subset of about 14 14 000 potentially vulnerable domains in the far tld what we get is about 15 000 email redirects of which about 10 000 unique email addresses something we didn't have before so this is extremely interesting but you might say well we used public emails or easily guessable emails and we found private redirection emails so well perhaps i mean it's interesting but but what are we not seeing what are we missing from the picture and that's where dns section comes into play really so what we are going to do is we are going to use dns sec dns sec is in itself a very interesting topic and a very large one if we want to go into details we might as well do a talk entirely on the topic and perhaps even several talks so very short summary what you should know about it is that dns itself is insecure if you use it like it just like like this so you need extensions which are provided for most of them by dns sec every modern good implementation of a dns server does have support for dns sec and so do resolvers essentially what dns sec does is it provides a route of trust and a tree derivation scheme that use public ecryptography digital signatures to ensure authenticity 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 to sending so it requires cryptographic elements and it requires sometimes some lock picking skills as perhaps the recent enough incident depicted here shows if you know what i'm talking about if not look into what happens in a key role of a session of dns sec so we can look at this we can we can look at the information sent to us by a dns sec compatible server one tool that we can use to recover information about dns sec is dns viz it is available in your favorite browser at dns viz.net so here we apply it to dnssection.ovh which is the website we use for demonstration proposals during this talk it has been slowed down so i can comment on it it is actually much faster than this it queries all the interesting information about the dns records here and we can see the full chain of trust for the domain 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 SOA, TXT, MX, NS and A records you can also see which algorithm have been used in this particular case dnssection.ovh uses dns sec with algorithm 8 RSA plus SHA 266 with NSEC 3 and you can go up to the ovh and above zones and see how things are derivated from the root of trust here you can see .ovh switching from algorithm 8 to algorithm 13 one of the 2020 goals for Athenic dns viz also checks for errors try it on devcon.org you will be surprised unless of course the good have watched our talk in advance and have already fixed it let us dive in the fundamental obstacle of dns sec so issue with negative responses for positive responses is quite easy if you want to authenticate that jrecordexample.com is that ip1.2.3.4 exists then it's quite easy you just affix your signature to it but if you want to authenticate that there is no record for bad.example.com this is much trickier you obviously cannot put every negative possibility in the zone this is where NSEC comes to the rescue NSEC is much more trickier and complicated that what i'm going to explain here but all you need to understand is the principle depicted in this slide so basically NSEC signed intervals where there is no domain for example it could sign there is no domain between apple.example.com and carot.example.com in lexicographical order and therefore it means that bad.example.com cannot exist because B is between A and C it does create a big issue so that you can now enumerate all records in the dns zone how to do that is quite easy just pick a random name for example fgfrd.example.com and query the gns server for it it will and obviously fgfrd does not exist it's a random name so it will answer the interval associated with it and so here it tells you that there is nothing between carot.example.com and good.example.com very good we have just found two subdomains of example.com we just repeat with a successor of good here good A get another name another interval and loop until we found every positive record in the zone so it means that it is a trivially doable for an attacker to get the whole gns zone of an NSEC enabled domain so now you might be thinking okay that's what we're going to do we're just going to use NSEC zone walking nope that's not what we're going to do because NSEC zone walking doesn't work doesn't work anymore in the real world for the simple reason that no one uses NSEC at all anymore yes you can be sad about this this is not what we're going to do we're going to do something more clever although not very different so that's what we talked about it what we're going to do is zone walking with NSEC three NSEC three has been designed and implemented and deployed for the very reason of providing resistance against zone enumeration the way we just described for NSEC so it's a patch on NSEC in a nutshell what it does is instead of having the records in plain text they hash them using several repetition of the shower and algorithm usually with sort or without sort 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 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 and NSEC three is really what is deployed today in the real world so that's what we are going to attack as Remy just explained the assumption behind NSEC three is that reversing even partially the hash is difficult well the practice turns out it's not really true you've probably heard about many people trying to break hashes especially for passwords and breaking hashes is even like basically how you mine bitcoin so I think hearing loss in the bitcoin mining farm when when they hear that sh1 cannot be referred so in practice for NSEC you can find off the shelf readily available tools to crack the NSEC free hashes however to the best of our knowledge it has never been used to dig valuable data they only use that for the same demo which is finding the list of subdomains of dot com or dot org but most of the time the list of valuable domains is better found using google all your favorite search engine okay so let's show you the NSEC free Volcker tool which is used to get the hashes from the domain zone this is actually a collection of scripts here we call the script collect of NSEC free Volcker on our DNS section dot ovh domain it starts by getting the NSEC free parameters which are the salt and the number of sh1 iteration then it is going to call for it and try around domains to find the intervals as we have explained in the previous slides this video has been slowed down a lot in practice with a good network this is actually really fast you even get a progress bar from the tool here the zone is quite small so we get all the hashes very quickly if you want to dump a tld zone i mean top level domain zone such as dot org then it takes much much more time another tool NSEC free map also exists and has advanced features such as parallel queries and automatic conversion for hashcat and john's repair unfortunately it has been written in python 2 which is in the process of going extinct so use whichever tool you feel more comfortable with well so we have just dumped all the hashes of DNS section dot ovh what do we do now well we bring out the gpu rig unfortunately we don't have a whole data center we only have a nice tslap p100 if you know nothing about gpu's let's just say this is not a potato gpu so most of you have heard about a hashcat before this is the standard tool to break hashes so let us just feed the output of NSEC free to hashcat and try different kind of attacks such as dictionary attacks and brute force attacks here we show you a little demo of hashcat in this case this is a simple brute force of all lowercase alphanumeric emails of exactly five characters as you can see on the comment line first hashcat displays some information about the gpu and compiles the open tl NSEC free kernel tailored for your gpu then it starts the hash cracking process in this case we only run it on a small subset of our findings the video has been speed up to avoid audience boredom you can see a few hashes being reversed on the screen again we blurred the result for privacy reasons as a side note we have found a bug in hashcats dots were not handled correctly many emails contain dots in the left part so this proved to be a serious concern for us we made a dirty fix for ourselves and the hashcat team has since fixed it properly thanks a lot to them let us consider about 16000 interesting gnecsec hashed record well using our gpu we were able to n-hash as much as 88% of them so that's quite a good result let's see a little breakdown of our results so in three-quarter of the cases we were able to reverse the hash and we did find an interesting email redirection in 13% we did reverse the hash but it was something else such as an spf record and in the remaining 12% well we are not able to hash thing my god's thing the remaining one are mostly domain key records which are not discriminable for email redirections 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 let's look at a few statistics so first we can just classify the target of the redirection by the email providers I use I think you can guess which email provider is used by most web pastors and this is obviously gmail.com and then if you look at the last part of the email well it does leak the name of the people quite often because well most emails are your name at something dot your country so it happens that in practice the name of the person is is found in email in about half time however it doesn't mean that we found some private information on some website people happily say that they do run the website so we try to find out how often we could not find the name in the target of the redirection on the website well this is in about two-thirds of the time so in two-thirds of the time when we have a name in the target of the redirection then this was not something we could have easily found on website so we have leaked some private information a little more complicated is how often this email would not appear in a google search and in practice this is about half of the time 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 last thing was a little more difficult to identify and this is about business connection conflict of interest or fake competitors and using the redirection we found well we were able to find such things in about one-quarter of the cases a little homework for you that we have not tried is run the phone emails for the haven been found database and find how many of them do have an entry in it what if we try to dox scam an adult website well first please don't tell my wife about it well we did try to find some names or some business connection but they are very clever and it's actually a fail their email never disclosed their name but we still have an email so who's the scammer and who's the scammer anything's more serious well we did find some famous people emails that are like politicians and sure base people we which have their own Wikipedia page we also found a few email of activists and on the much lighter note we did find a lawyer website with a redirect to guess what my little pony dot his birth date at gmail.com and also we found 50 people who had added redirects for the no reply at other domain why wouldn't do that little carrot this is actually some manual analysis we went through hundreds of websites phishing for the names and the emails so typically this means going through the contact page googling the name googling the emails and dealing with options stuff such as adobe flash website which are like really difficult to navigate for so this is all but best effort and we might have missed some public data so okay we find a lot of interesting information some of it apparently does not appear either on the website or on in google and very likely where it's information that was not meant to be made public so we thought it was an interesting issue we tried to bring it up to ovehcloud so we called the hotline and we're gonna tell you about the disclosure process so we called the hotline and we said okay we think we have a problem with your handling of private data they say send an email to abuse art 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 so well we were a bit puzzled perhaps we did not understand what they meant by send an email so we called them again and calling them again they say yes do send an email to abuse art you did the right thing just do it again perhaps they missed it so okay well we write a second email and we never got a reply 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 to the right people what to this day we are still waiting for a response so oveh if you are looking at us we tried okay so well if you want to fix it what what should you do if you do not want to be targeted by the kind of enumeration and privacy disclosure that we just described turns out that this has been a goal of NSEC for many years now this is this was the reason why NSEC 3 was proposed and obviously NSEC 3 failed but the real the correct answer to this is use publicly cryptography it's been described in in two rfcs how to do this with the nssec in a way that's compatible with the nssec and there are two leading implementations of this idea one is nssec 5 which is already six years old now and the other is to use nssec 3 but replace the hash by public key signature a digital signature the problem is nssec 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 but most importantly nssec has a bad track record this is already the fifth iteration of it and you have not heard of nssec 2 or nssec 4 in this talk and you might wonder why well perhaps they never got to see the light for good reasons the alternative is nssec 3 nssec 3 with digital signatures 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 but it's on the 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 bad carry the burden the fact that resolvers now have to perform signature verification which is actually quite slow it also requires very careful implementation and handling of algorithms and keys because ecdsa is famously brittle uh an experience in the matter shows that dns servers are well historically bad at it we gave you a reference on the slide that you can look into about the handling of rsa keys in the past remy has just explained you how to fix dns sec but most people do not want to handle their dns zone by themselves and thus use cloud hosting so assume for a second that you are an ovh close customer and you are using their redirection features how can you protect yourself right now well there are two different things to protect first the target of the email redirection an easy way to hide the real target email is to use double redirects let me explain first redirect test at dns section dot ovh to test dot dns section at gmail.com into ovh cloud admin panel then in your gmail interface redirect test dot dns section at gmail.com to your personal email address and attacker will only be able to see the first redirect and thus will not learn anything useful second you want to protect your domain email list this is actually quite tricky what about disabling dns sec entirely well there is a reason dns sec exists and dropping the security properties of dns sec might not be worth it or you may also have services for which dns sec use is the most another possibility to protect the list would be to use long and unpredictable emails so the hash is almost impossible to reverse for online websites which this works quite well the web server does not care much however a long and non-human friendly email is not going to make a good first impression on your business card if your domain email list is especially sensitive the best way out is probably to stop using vulnerable ovh cloud redirection for now upgrade to an ovh cloud plan with real email addresses 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 to say already the lesson to remember do not store private information in your dns zone if you do not have to this is likely to leak unless well countermeasures are widely deployed dns sec and sec 3 attacks exist they are practical and they can reveal information that was not obtained in any other way that we know of so try to push you local representative for dns server to adopt modern countermeasures against zone enumeration and sec 5 is not yet final try to push for it and adoption of ecd assay as a signature for zone enumeration is also on the way but you know it's it's taking time so try and get there that's all we had to say and do have a look at the proof of concept website that we put up for you to play with thank you again have a great day and try this at home very carefully of course bye bye