Domain Takeovers For Fun And Profit by Dan Oates-Lee

thank you everybody for coming and I'm going to talk about sub domain hijacking and uh cut how devops could be making is a little bit more vulnerable but first of all the obligatory uh who am I my name is Daniel oatsley I'm a co-founder of security and director uh I'm a Dev fed Cyclops enthusiast I started off my career working on the help desk made my way onto the server team onto the networks team um and then it was discovered that I was pretty good at hacking stuff so he shook me on the security team about 17 years ago and I put automator up there because I love doing devops integrating security testing into everything that I do I am a I am definitely a security guy I play lots of Capture the Flag competitions and and take part in lots of security and community events and all around General geek my wife who's currently in in the audience and she will attest to that if I'm not working then I'm generally hacking something or doing something techy so what am I going to talk about today well first of all before we could talk about DNS supplement hijacks we're just going to quickly cover off what DNA how DNS works then we're going to cover off a couple of uh sub domain takeover attacks why should we care and then how your organization can defend itself including using the tool that we 've so DNS so there are 13 root DNS servers out there in the world that will hold the top level domain as records so when you're doing a Google lookup if you're not using your DNS caching using the root service to go to First it will go there first to go and find out who the top level domain is so the top level domains are the code.uks the dot coms the DOT io.net so the the root server will forward you down to the tldr service then the tldr servers will then enumerate the next part of your domain which is the domain that you go and buy from your domain register so in our case we're going to be talking about onsecurity.co.uk today so it will be one of the um one of the DNS hosts so that'll be GoDaddy or Azure or AWS wherever you choose to store your DNS records and then inside these DNS inside your DNS server you will then have hold your records so these will be a class records your MX records your txts whatever it is that you need to create to be able to make your web service works so if we look at access you have and what bits you can configure you can't do anything to the to the top to the root service and so the registry servers they will just hold an NS record which will point you down to your own domain server and then your own DNS server which is public is completely configurable by you so I think we're all pretty familiar with that but how does it work if your client goes through it well it will go off to the root server it will do as we've explained it will pull back the DNS NS records the NS records will point to the tldr server the TL VR server will then point down to your own uh DNS server which will then return an IP address for connecting to a website and these are just a couple of uh subdomain examples so the top so our domain would be public security.co.uk and www would baby be the subdomain or our website and blog would be to get through to our blog server and our doc service might get through to The Document Services so let's have a look at scenario one which is we are using a SAS a SAS product uh out on the internet and we're going to have a look at how we could potentially do a DNS takeover attack so for instance we've decided to configure up punk security.docs.orgsecurity.co.uk and we're pointing that off to github.io because we've decided that our API documentation is going to be held on GitHub next to our source code so we do a quick ping and lo and behold we can resolve the names we've submitted a ticket to our operations teams they've gone and created our property DNS record and it's now pointing off there however if we go to the website and we go and try and browse there it looks like our um our it hasn't actually been configured yet in inside GitHub now this is quite typical um what will happen is a your the developers will submit a support ticket to ask for a CNN record that'll be configured maybe a couple of weeks before the developers go and configure the the SAS service and what we've started finding is that attackers are finding these name these these DNS records that are pointing to SAS based products uh that can easily be taken over and that's what we're going to show you now so inside GitHub you can go and create these things called custom domains now get because it doesn't need to do any validation you can set your custom domains whatever you like what to represent your your Repository because you own the domain and you pointed it to GitHub GitHub will do no validation for it so our attacker has found that we're pointing at GitHub but it wasn't actually serving any Pages uh he's now gone and registered it and he's taken over that domain so that is what that is subdomain takeover number one where we have a SAS product we point our C name to that SAS service it hasn't been stood up yet and then an attacker can go on stand up for service there and start serving Pages underneath your sub underneath your domain name we'll have a quick look at scenario two and then we'll cover off why uh that is a bad thing in the world of devops so we're going to have a look at name server um delegation so we've talked about subdomains being www.com but we can also allow uh some some um DNS services so say the development team wants to be able to control their own uh their own DNS records in real time and so they request the operations teams for them for them to have a sub domain of dev.com security.co.uk so they can stand up their own so they can stand up their own web services uh sorry their own uh name servers and so the operations team will go into uh the main domain and they will go and create a cname record which will point off to their new uh to the new name server the new name server will then allow the development teams to go and create their NS records or their across records or whatever else that they want to go and create but this can also have its own problems so if we have a quick look here we're going to see that the operations teams are going to go and create a subdomain called Dev .com security.com you which is what was requested with using AWS Route 53 here just simply because it's easiest way and there we go we've now got a name server and we can see uh in a second while just highlight and copy the uh the the net where where those names where that new sub DNS zone is being held that's dev.com security.co.uk now we've got to go back into the parent folders to go and create the name the the NS records to point to that sub domain what you can see there that somebody's made a mistake they've called it developer and this happens quite a lot and the develop the operations teams can be understood on the strain and they will go and make and they will go and accidentally type in the wrong thing so now We've Ended off in a position where we've got dev.com security.co.uk where the developers can go and create their name service but we've also got this developers.com security.co.uk where the NS records where it's pointing nowhere so what I did what an attacker can do now is that they can try and see if they can get Route 53 to give them those name servers so they can host their own zones now we wrote a python script for testing this and within about 15 minutes we were able to take over those those names by just simply calling AWS CLI and we would try and register it and we would find that we would get the wrong name Services we'd then try again and maybe we might get the last two and then we'll try again and we might get a couple more and at this point we can then say right well we've now got a couple of these name services so we'll just leave it the way it is so we can start so the attacker can start servicing DNS records as your main domain so why is devops potentially making this worse Gene he talks about devops it's relating to core context so core is the bit that you want to develop yourselves so like your your Niche little bits about your application and context is if there's a service that you can go buy off the shelf go buy it off the shelf because somebody else takes control of all of those patching and maintenance and looking after it so that might be something like a web service or an email certain you don't want your developers building in brand new web server when all you want to do is build like another product or sit on top of it we also ID we also use these idea of ticketing systems so when a developer wants to release something or create a new service record or something like that they will typically go and create a ticket it will then sit in a queue it'll take a few weeks for the operations team's potentially carry it out then it will go back to the developer and it might not be in that Sprint it might be in a couple of Sprints time so we end up having this period where we've requested a cname or an S record to be created and there's a period of time where it's then not implemented where an attacker can go and take over it we're still doing quite a lot of Click option as well so where we're using terraform or infrastructure as code the operations teams aren't still quite up to speed with using terraform our infrastructure as code and they will just go copy and paste what was in the previous maybe pull requests or whatever they've done previously and then they might make them safe and delegation is obviously one of the things that are causing us a little bit of concern as well because um we are trusting that the development teams are creating these illness records as they need them and destroying them as well when when they don't need them so you might be thinking well so what we can create some names that we could as some attacker can take control of the name a DNS name and what's the problem with that the problem is and the the URLs that are up on the site now are ones that were actually publicly taken over and have been publicized on hacker one is that we can create credible now fishing lengths so like sign up uber.com we're telling our we're telling our users to be really careful about what we click on and make sure it looks legitimate but who would have thought that sign up.uber.com would have been an illegitimate domain name or subdomain and it would have passed through any URL reputational checks as well because uber.com is trusted which will then lead us to Credible email addresses like helper sign up dot uber.com where the phishing attack could be sent out and ask users to go and reset the passwords also to go and verify a password change however the most scary bet are Loosely scoped cookies and this is the part where the the hackers where the uh the pen testers in the room will be a bit more interested because if you can take control of a subdomain and the website has a Loosely scoped ticket for cookie you can steal the parents cookie I'll show you how that works so what happens um is we have a web name website running at unsecurity.co.uk and we've got a couple of sub domains the cookies at the parents uh created at the parent domain will feed down automatically if they are not what we call scopes so if we look at this website we've got three cookies on our Punk security website we've got two by calendly and we've got one from uh from cloudflare if we have a little look if you look at the Domain is the main name that indicates a Loosely scoped cookie which means it is possible to use that computer that domain and any child demands so if we go back to our previous NS name server attack we created developers accidentally and our evil attackers has now gone taken over developers uh name citizens stood up www.developers.com UK so anybody that logs into Point Security Now and we send them a phishing link when they click on that link we're going to be able to get hold of their cookies and which could include authentication information so that nicely leads on to my third demo so what we're going to do here is we're going to use example.org which is just a local uh web service we're going to just open up the development browser so then we can go and drop in a cookie now normally you would log into a website or you'd be able to go start or a web service and create your cookie uh you know you might be able to get a cookie out of it that way what we decided just for the sake of ease that we do it this way so we've created an authentication cookie and we've got the word Secret in there just to show what would happen now currently it's only scoped for example.org so to make this Loosely scoped we're going to need to or stop in front of it so we put the whole stuff in front of the front of it now the attacker has also taken we've we've this scenario here is if we've lost our name server so that NS server record so an attacker now has gone going to go and create a sub a sub um a sub domain website sort of running and potentially sent a phishing link through to a user to click on a link and connect to subdomain Dot example.org and when they click on that lo and behold you can see there the cookie is just come to our website for the authentication for the secret inside there so we've been able to take that and all we've done is sent the web image so this is one of the reasons why we need to be careful about what we're doing with our name services and why we need to think about what we're doing with our public DNS so how can we defend ourselves one of the biggest things that we're going to have to start doing is periodic reviews and audits of what we've got enough of inside our public DNS zones how many people in this room can tell me that they know exactly every single public and what it's used for how many people think there are dead DNS records in their DNS zones today that aren't pointing off for anybody or are being used what would happen if somebody went in and deleted all of your public DNS Zone records do you think you'd be able to quickly recover from it probably not and it's one of the lowest things that we think about as well it's not on the top of the agenda because it's not one of the Gucci things that we think about but because we're moving to this idea of devops and you need to be able to create DNS records pointing to these cloud services so we need to start thinking about looking after them better another way I've been able to defend against it is to sign up to a bug Bounty program like hacker one and paying some bug Bounty guy 200 for finding a faulty DNS record and sounds sounds brilliant and we did also find that there was one service out there on um on the market for a thousand dollars a month they will scan your domain the sub domain takeovers and that to me sounds value for money we can also ask our pen testers we could ask our pen testers to start checking our external DNS records or pen testers it's typically they're overloaded anyway if time constraints and what have it so all you're going to do is degrade your pen Testament potentially a little bit more we could move to infrastructure as code we at Punk security we do that all of our DNS settings all our DNS records our external network load balances all the wax and everything are all configured and controlled under terraform so we know exactly what's been deployed and we can go through the pull requests and we can validate that what we're pushing out is correct however I'd like to talk to you about a brand new tool that we have created called DNS Reaper uh incidentally there are batteries stickers along the front which you can help yourselves to what we came up with this conclusion is with DNS Reaper is um it should be relatively simple to be able to check these DNS zones so we had a look at what was how we could potentially do that and we came up with a simple solution it's a little python script that went and checked your DNS records and then goes and checks that the end the target host is actually up and alive into something that's dead so DNS repair will run as a document can download it as a pipe a list of your domains or you can configure it to log into your name server So currently we support GoDaddy Azure AWS cloudflare and there are a couple other ones I can't remember I'll show you in a minute and we then when we're testing these domains we've written signatures so when you go to GitHub rather than just looking for the word 404 where um the web pages typically get a return a 200 um HTTP code so what we're doing is we're scanning through the actual page that's returned and look for key signatures which then give us a confidence level to validate that that page is susceptible to being taken over and then we give you a nice little report on the screen as CSV or a Json file however you see that to be able to digest it now the use cases for DNS Reaper are auditing your DNS configurations and for those that in the audience that want to go and start making a little bit of money on the side again this Reaper is pretty good if you go sign up to the book bounce program and use DNS Reaper to help you earn some dollars uh we don't ask for anything so don't worry about that or you can just use it as part of the plan to check employees has actually made sense and that lingering around that shouldn't be there now I know that there are a couple of people in the audience today who've used DNS Reaper and it would found a few DNS zones that were susceptible to DNS takeovers and it seems to be picking up on popularity there are some large banks that have also been using it just for checking doing manual checks so feel free to use it so what does it look like and how where can you get it you can go to GitHub go and download source code or we do do nightly builds where we resolve any security issues and push out a new image every night um to Docker Hub we also do a full documentation Suite so rather than you just having to guess what I am permissions you need to give DNS repair we've created like I am rules that you can copy and paste in so then DNS Reaper has only got access to what it requires and with every good security tool we've got some of the world's best ASCII art and make it look pretty because yeah that's the only way to use the security tool isn't it landline so as you can see here we can either take we can do DNS Zone trance Zone transfers you can download all of your DNS records if you don't trust DNS Reaper into a file and just get it to scan it it can log into cloudflare it can log into AWS you can log into Azure digitalocean it can even check simple uh Linux buying servers so rather than you having to know every single DNS record you can just get DNS reader to log in and then it will go and check all of those zones for you automatically and if we point it at security.com we can see here I don't know where you guys can see it but we can see that we've got uh it's found developers.security.credit UK is um it's it's potentially susceptible so you get this idea that we are giving you a confidence rating as well so if we say it's potential it means you need to go manually check it if we give you a confidence of confirmed that means one of our signatures that we've written is checked done that manual check for you and it is acceptable to being taken over so it will tell you exactly the the score then now I'm going to do two Shameless plugs really quickly we do have three other tools as well we've got SM beagle which is a which we design tool you can run it as a low privilege user on your network scan your whole network and it will then document every file and folder inside every single Network share you can see and put it into elastic so then you can understand what you would lose in the event run somewhere but the pen test is in the room people are beginning to use this now they're scanning the network because what good it admin