Good evening and thanks for joining me for my talk on subdomain hijacking. Why DevOps is making us more vulnerable. So before we jump into the topic, who am I? So my name is Simon Gurney, I'm a co founder of punk Security. We're a devsecops company here in the UK, based in the northeast. I'm a devsecops consultant, still do consultancy as the company's grown. Still very much a geek at heart, so very technical. Python developer, also security guy, came from an infrastructure background, so really quite broad skill set. And what's the agenda for this evening's talk? So first we'll go into quickly how DNS works. So we're going to look at what does the infrastructure behind DNS look like? What are some of the common records look like? And then what happens when you request a DNS record for a website. So you go to a website or you try and connect to a server, whatever that may be. You punch in a human friendly name and it resolves it to an IP address. But how does that work under the scenes? Because that's going to be important. When we start talking about how we attack that, we're going to go through two methods to attack subdomains. Typically there's plenty of different SaaS platforms we can try and attack, but typically they fall into two methods. So we're going to cover both those methods this evening. One, we're going to demo against GitHub pages and one against AWS. And then we're going to quickly touch on why should you care? So when we understand what are subdomain hijacking attacks, why should you be interested and why should you try and prevent it? And what can you do to defend your organization? So it's not all doom and gloom, the end. We'll show that it's actually quite simple to keep on top of this stuff. So let's kick it off. Can intro to DNS. So what is DNS? We're going to go to the infrastructure first, so you understand what actually is responsible for making DNS work. And then we'll have a look at how DNS, these process itself works. So DNS starts with some routing servers. There's 13 of these servers all dotted around the globe, typically mostly centered on the US, actually like the US army runs it and I think Nasa's got some. So these are fairly static servers, really high load tolerant servers, really highly available. They are hard coded onto DNS servers. So if you deploy a Windows DNS server, for instance, there'll be an option to use root hints. So these are hard coded IP addresses where it knows that it can go to start the whole DNS journey of how do I resolve a domain name? So if it hasn't got anything in its cache or no other direction, the routing server is where it's going to start its journey. As I said, that's generally hard coded into the applications. It doesn't change very often. And what do these routine servers hold? So they have a record type called a name server record and they point at the DNS servers responsible for what we call a top level domain. So these you recognize as coms.org co uK. So these very top level of a domain that is maintained by an organization. So co UK here in the UK is maintained by nominate. So these will have their own DNS servers. So the job of the routine server is to point people when they're after a co UK subdomain at nominates co UK services. So these are the TLD servers. So as I say, we've got co UK there by nominates and we have these name server records pointing at these TLD servers. The routines aren't going to get updated that often. Only if nominate decide to change their ip addresses for their co UK servers. Or recently you probably novices, there's a flood of tlds. We used to be just co UK, maybe 100 tlds, now there's thousands. You can get kitchen security, shop, Google. It just exploded recently, the number of tlds and then the tlds will have the same NS records, but this time they're going to point to their customers domains and then they're going to point to wherever you've told them you're hosting your DNS records. So in this case we're co UK again. So we're over at nominate, we've purchased a domain test co UK and we've told nominate that we're serving that from Azure. So if someone wants to go and find our websites, these can look up our DNS records over Azure. So we tell them that they provision NS records or we provision it via their web interface or whatever mechanism they've got. And then they can then point all people at our azure servers which we can update as fast or as slow as we like. So on our servers we have more records than NS now. So we can have a records which are how to turn a name into an IP address quad a records which are how to turn a name into an IPV six address cname records which are kind of like a reference. So you get Cname records to another DNS record and you may even start that whole journey again for an alias record or NS. So we can do the same trick that these registrars are doing and say actually this part of the domain, you can go and fetch them another server. So those are typically the records. There are more text records and mail records and we don't mean to concern ourselves with that for subdomain hijacking, but we'll cover these records again as we go through. That's what the infrastructure of DNS looks like. So when you purchase a domain and you pay in a registration for each year of ten pounds a year, some nominal fee to nominate or whoever your registrar is, that's because maintaining these TLD servers is expensive. They have to maintain who is records, which are who owns the domains. And then they have to keep this really highly available infrastructure up because if their servers go down, if that co uk DNS server was to break, your website would go off. That's not quite true. It wouldn't be that instant. But if they were down for a long time, then that would happen. So when you purchase a subdomain, you're basically funding that process. And generally these orgs up until recently when the tlds exploded, are nonprofits like nominet, which are public sector owned. So that's the infrastructure behind DNS. So when you purchase these domain, what you're effectively doing by your registrar, whether that's GoDaddy or directly with a domain provider, is you're paying to have your NS record and your details put on TLD server. And then when you create subdomains, so you bought a subdomain test pump, securitycurity Co? Uk and you've decided to create a subdomain of tests. Then you would configure that in your DNS records. That's free. You can have as many of those as you like, but to actually buy a domain to go on co UK you have to pay for. So just to go over that again, root hint servers, no one's got any access to those other than the bodies that manage them. The tlds you do indirectly configure via the registrar. So you go onto your registrar, GoDaddy and say my domain is available on these NS records and you configure that directly generally, so you can configure them, but it's via the registrar. Normally it's 24 hours delay for that to fully propagate. And that's the only real access you get. Whereas the azure layer or wherever you put your DNS servers, you can configure that how you like, really easy, really quick. That's infrastructure behind DNS. And now we're going to look at how the DNS flow goes. So got a laptop here and it wants to go to my website, www. Pumpsecurity. Co. UK. So I type that into the URL or I go on Google and search us and that comes up and then the computer's got this task now of I've got a human friendly name, I need to connect to a server somewhere on the globe that's going to serve me this website. How do I turn a human friendly name into an IP address? An IP address is structured in such a way that given that IP address, the traffic that goes to that services can work its way around the Internet. That's the whole point of IP addresses, they're fairly hierarchical. So given an IP address, a computer can work out where on the planet it needs to get that data to. So we need to turn that human friendly name, which isn't hierarchical, into an address. So at this point, the laptop is connected to a BT home hub, so its DNS records are with BT. BT is maintaining some DNS servers that allow its customers to then use. So this is fairly automatic behind the scenes. Some organizations will have their own way protected. DNS is quite common now where they do like malware filtering at the DNS layer. So you make a DNS request and it says, oh, it's malware. So I'm not going to bother responding or I'll send you to a different page that says that's malware. But typically in a home environment, you're just going to get served whatever your ISP is providing. So in this case, my request goes off to the DNS server at BT. The DNS server at BT says, where is co. UK? So how do I start this journey? So it goes off to those routine servers and says where is co. UK? And then that responds to that NS record we talked about. So back to BT and says if you want to find co UK, you need to go to the nominet services in the NS record. So now we go to the nominet services and we say, where punk Security Co. UK? And that responds with an NS record and says for that part of the domain, you need to go and speak to these servers over in Azure. So then we go to Azure and says where is punk Security Co. UK? And Azure says, I know that one, this is the a record. So this is the IP address. BT then responds and puts that back on your computer. So your computer's now got an answer to that query, it's got an IP address. It then sends traffic to that server and says give me the website. And that all works wonderfully on future requests. What we actually see in DNS is there's lots of layers of caching. So in future when someone says where is punk security co. UK? BT is cached. Punk security UK is over on Azure. So it's not going to go to the TLD, it's not going to go to the routing server, it's just going to go straight to Azure because it's cached it. And that cache is configurable as different lifetimes. Typically it's like an hour it gets cached and DNS is heavily cached because we don't want those routing servers getting hit with every single DNS request. So that is DNS in a nutshell, both infrastructure and how it works on your laptop. So what are subdomains? This topic is obviously all about subdomain hijacking. So subdomains are those parts of the subdomains that you control. So in this instance punk security UK is a domain. So I've got the TLD Co. UK that's sitting over at nominate, I've purchased punk security from them. So Punksecurity Co. UK is the domain and then I can add as many subdomains as I like, the WWW blog docs, there's no cost to those. I just go on to wherever my DNS provider is as your cloudflare AWS and add a new subdomain. I can point it wherever I want a website or SFTP server, it doesn't really matter. So that is what we're talking about with subdomains. We're not going to be taking over the full domain. We're looking at taking over those subdomain records that are provisioned and on this slide they're all green. And what are subdomain takeovers? Well hopefully now it's fairly obvious but essentially we're going to try and take those domains over. So because those domains have got misconfiguration that is detectable we're going to services our own content from them. So in this case on this slide we've got docs punk Security Co. UK and actually this is going to lead into the first demo which is the GitHub pages takeover. So in this scenario that's pointing at GitHub pages, GitHub pages has no idea what docs punk Security Co. UK is and we can then as an attacker detect that, go and provide our own solution via GitHub pages, our own website. And then if someone was to go to punk security Co. UK, they get served our malicious content. So these are what we're talking about with subdomain takeover. So let's dive straight into that GitL pages takeover because it's a really quite simple one to get your head around. So in this case we have punkecuritydocs punksecurity Co. UK. So I couldn't use docs because I burnt it on a previous demo. So on this one, that's the domain. And when we do a ping to it, what happens is that DNS process we just discussed kicks off and we turn it into an ip address. And I've just highlighted that in this part of the output here. So I've pinged it and I've got an IP address. That IP address is a GitHub pages IP address. There's only like four, I think there's two IP version, four ones and two IP version, six addresses that you could get back. So we know that this domain is served by GitHub pages. That's the first step. The next step is to go to these domain. So if we go to the domain, we get a 404 and a page saying there isn't a GitHub site here. So the DNS lookup went through fine, went through that whole process of going to the routing, going to the TLD, going to wherever our DNS was is your AWS or cloudflare. And these that gave us a record to say you need to go to GitHub pages. So that process is end to end complete. When we go to GitHub pages, it knows nothing about that domain. So this is a condition that we can detect. And as an attacker, if we can then convince GitHub to serve our content under that domain, then we can serve content under that domain. So this is a very quick demo of how that works. So I'll press play on this and you can see it. So I've got a repository here, I go into the settings, there's a GitHub pages branch specified which has got a load of web content in there. I add the domain and GitHub now does a quick check and says, right, is that DNS record pointing at GitHub pages? And if it is, it's happy. So as an attacker I've got no reason, there's no reason for GitHub to trust me more than anyone else, but it has done because the DNS flow was complete so now, as you can see, if I refresh the page, I'm now serving the content out of my repository. So as an attacker with no authentication, no method of proving that that domain is mine, I can serve content for it. And that's because GitHub is happy to do the DNS check as proof that you own the subdomain because you've set it up to point it at GitHub pages. So we've seen an attack there where can administrator has set up a domain to point at GitHub pages. And either they haven't done the GitHub pages set up yet, or more likely they have, years ago and they've decided that they want to use it anymore and they've deleted it. So now it's pointing to GitHub pages and it's not actually becoming used. So they've cleaned up the GitHub pages but not the DNS records. So how does DevOps make this worse? And the first thing really is a really interesting quote from Gene Kim. If you follow the DevOps research in academia, there's this whole pull in DevOps to focus on what's core to your product and all the context, stuff like auth et cetera and whole swathes of the app if it's not bespoke to your application. The argument quite often in DevOps now is you shouldn't be devin it. You should not waste developer time and effort reproducing something that you can buy off these shelf. It's almost never going to be as affordable and it's something else that could break. You've got to maintain, maintain dependencies, all that sort of stuff. So there's these huge drive to say let's focus on what's core for your app and anything that's context, go and push it out elsewhere. Form rendering or is a common one. Now let's go and use okta. Let's not bother with or let's use cognito. So when we do that and we shift more and more services to SaaS providers, naturally there's going to be more chance that we point records at SaaS services and then don't use these. So rather than implement a blog on our app, we'll just go and use a blogging service. Or rather than introduce a forum, we'll go and use a forum service. But then when we stop using them, we leave the records there, people can take them over. So these drive to say, actually let's use more and more SaaS services and not host stuff inside ourselves is driving a lot of this. And then also as developers are empowered now to use these SaaS services and also quite often under their own steam. So it's not for the IT person now in central Ops to go and Provision GitHub pages, for instance, or that forum. Maybe the DevOps are doing an enabled team, a highly agile high velocity team. They're developing systems and being able to provision infrastructure themselves. But actually DNS, maybe they can't do that because Ops has still got control over DNS. This is a pattern we see all the time and these debate to that is these ticketing system. So typically a developer will go well, I need to do a GitHub pages thing. So I've looked in the docs and I need to point this DNS record at GitHub pages. GitHub pages won't let me do that at the moment because the DNS record is not pointing at it. So I'll create a ticket and assign it to Ops to say, can you create me this DNS record? So these ops do that and maybe the ticket doesn't come back straight away or it comes back in, it's not in that sprint, that developer is going to do that, or maybe they just lost interest and forgotten about it. This interface of tickets and systems can quite often lead to work being a one week or two week gap between objectives being delivered, even though it's a reasonably trivial thing to implement, and we see that quite a lot. So there's a bit of a race condition here where an attacker can detect and take over a subdomain before the ticket has been completed. So we're going to go on to the other type of attack name, which is NS delegation. So name server delegation. This is why we covered NS records a bit more in detail at the start. So if we look at this DNS configuration here, we're back punk security co. UK. It's sitting on these azure server and we've got a record for the website www. So that's all fine, maybe central ops manage this. What we're seeing now is these agile development teams. They want to be able to manage their own DNS, particularly if you're using services like Netlify or whatever the AWS equivalent is nowadays. You want to provision maybe a web app on a pull request and it has a unique domain, et cetera. So you end up with this situation where because of content security policies and calls and all that sort of stuff, it's really convenient to use a legitimate domain. But equally central ops and security are resistant to say yes you can go and provision your own records on DNS. There's a potential for a huge problem there. If you were to break something, you could bring down all services. So what we see is NS delegation. So in this instance we've punk Security Co. UK and we create an NS record, punk Security Co. UK and we say to the developers, okay, will you go and provision your own DNS server somewhere in AWS, et cetera? And then we'll point dev Punksecurity Co. UK to that server via a name services record exactly like the tlds are doing with us. This is really simple to do. And these now as a developer you've got your own DNS server and anything that comes before dev is under your control. So if you want to create www dot dev or a pull request specific record dev, you can do that straight away in your DNS and root to free and the chain is complete because now it goes rootint. Where is co. UK TLD? Where is punk security next sends you over to Azure. Azure, where is dev Punksuity Co. UK. Oh, that's over on the dev servers and root free Aws. Boom. I'll go and ask those. And that completes the chain. So we can use this exact same trick to delegate parts of DNS control. We haven't got to worry now that the devs might accidentally remove www and break our main website. So this is just to see that pictorial. This is where we were before we had all that, the root hint TLD and the azure server. And now with the NS record we can send it over to a completely different DNS server and it can serve all the same records. There's no difference there. We've just added an extra hop. So what is an NS takeover? It's very similar to what we saw before. DNS now is predominantly provided by SaaS services. So historically you might host your own DNS servers. But DNS is so critical and it needs to be so reliable. Typically now you're going to use cloudflare AWS or your registrars like Godaddy, et cetera. So in this case, maybe because of these ticketing system, maybe because of a typo, maybe because it's not used anymore, we have two NSF code set up, Dev, which is working fine, working beautifully, and these, this punk security co. UK, which is an incorrect NS record. And we'll go into what that looks like in a moment. Basically pointed at a DNS server that has no idea about this subdomain, so much like we did with GitHub pages as an attacker. Typically a lot of these SaaS services, we can just provision our own records onto that server and it's probably going to, if it wants to do a check model, don't anyway. But if it wants to do a check, it's probably going to do a record check and say, actually yes, it's pointing at me. So that's all good. So this is an NS takeover and we're going to do this on AWS route 53. So in this instance we have, I'm going to quickly show you what this looks like to set this up. So we have AWS weekly free here with punk Security Co. UK, top level, the domain that we want to create the delegation for. And this very quick video we're going to see what this looks like. So create a hosted zone in AWS. Click the button, we're going to type in punk Security Co. UK. So it's a completely different zone, completely separate from the main zone. We've got, I'm just going to put like a little note in here. Developers, when we create the zone, it has got there. The DNS records go down there in a minute. So we can see that we created the zone dev Punk security UK. And then under NS records we can see four servers. That's basically AWS has picked up random some servers around the globe and provisioned our hosted zone onto it. So to complete these flow now if we go back to the original infrastructure, look, we need to go back to the top level one and add the NS records to say where the person should go next. And I've just copy and pasted those out of the developer's zone. So I've copied and pasted them in and then now when you go for that flow, you'll get one of those and the path will be complete. So that's how simple it is to do delegation. Now if you noticed in that video, but when I created the zone, I called it punk Security Co. UK, but then when I aimed it to the parent zone, I put developers pump security UK. So at this point the dev zone is working and fully functional and servicing on those AWS name servers, but it's not Internet resolvable because it's not on the parent domain. When you go to the parent domain and say where's punk security Co. UK? It has no idea. Just because they're both in AWS doesn't mean it's going to magically work. If you would go to it and say where's developers punk security UK? It's going to say it's on these name servers. But when you go to the name servers, they have no idea what that is either, because we never created a zone on them. So how can we exploit that? Well, we can just ask AWS to provision as an attacker the developers punk security UK and there's going to be no checks on it. Now I did say that AWS had randomly put those records on servers around the globe. So we have to take that into account. We end up with a slight amount of brute forcing. The services here, even though they're randomly allocated aren't quite as random as you'd expect. And there aren't that many. So brute forcing is possible within sort of five minutes. It's not an exhaustive process. We do bump against AWS rate limiting. We've got a bit of a demo, so you'll see that in a minute. So how can we exploit it? So when we created those records though just then it gave us the NS record. So it told us which servers it put the zone on. And then when we incorrectly set up the NS record pointer, we told it those exact same services. So if I was to do an nslookup now against developers Punk Security UK, I would see these NS records. So as an attacker I can just get these. So what we need to do now is go and ask AWS to provision Us developers Punkycurity Co. UK and see what servers it puts us on. So in this scenario that's exactly what we've done. We've got the target servers we want to get and then AWS has responded and said, I've put them on these and as you can see there's no matches at all. So that is absolutely useless to us. We just basically delete the zone. It comes under AWS free tier. We haven't got to worry about it and we ask them again. In this instance, I'm not sure why AWS does it in pairs, but we've got two or four now this isn't too much of a problem because we can keep this one and then just go again. So if we get two or four and then they get another two or four, and the overlap is that we've got all four, then we've got complete control. Anyway, it doesn't matter that we've scattered it on a couple of extra servers, it makes no odds at all. So in this case that's great, we'll keep that. And then we do another request and we get the other two. So now we've got full control. At this point they're in our AWS account, we can add records, these flow works perfectly fine and we can services up whatever we want from those DNS servers. So in these situation, how is DevOps making it worse? Typically when we see NS takeover attacks it's because of things like terraform and copy and pasting. So provisioning stuff in AWS root these is typically done now with terraform or cloud formation. And what we see is that people just copy and paste these blocks over. And it's not quite obvious on a pull request when you're looking at these sort of NS records that you spot that they're not right. So you might provision a record in AWS and then someone goes in and copies and pastes them into the pull request to update the parent zone, but it's not obvious that those records are correct. And what if we haven't updated them? What if we copy and pasted the block from another delegation we've done and not updated them? So infrastructure as code, as good as it is, and copy and pasting bits of code rather than doing it, click ops, which is, I'm not saying don't do that. I absolutely advocate infrastructure as code, but this is a common cause of these sort of typos making it through and these, these issues occurring. And then as DevOps, with developers being enabled in small focus teams with all the ops and SRE and security support they need, delegation is more rife than ever. People want to be able to spin up web apps on pull requests, devs and Uats and all these different environments and they don't want to be frottled by waiting on ops. So the delegation is obviously huge now that's really becoming. In fact, before I go on to this, I've got a quick demo of the brute forcing, so I'm just going to drag this over. So I've got a quick view here of my AWS account and I've got no hosted zones in it. So this is the attacker and what we're going to do is take those exact servers I've just got on the slide there and try and brute force to get our zone onto them. So it got no zones in there. At the moment I'm going to bring over this terminal with vs code. I've got a very quick python brute force script from a brute force in AWS root these. I haven't released this anywhere, so you can't get it. It's not massively difficult, but we don't tend to release tactile. So at this point every dot is us requesting a zone. So we are, as I said, as aggressive rate limiting on the AWS side, so we try and fraught it a little bit. We do sort of free at a time, so every dot is us requesting a zone. And if that zone then doesn't match any of the target records, we delete it and move on. So we just keep cycling through and then hopefully eventually we will hit one of the servers that we want and this script will just output to the command line and say that we've got that with the zone id and then it will carry on until we get all four. So hopefully we won't wait too long to see that. And these we'll switch back to the AWS console and just see that we've achieved it. As I said, there's nothing going on in AWS land. Now to say that I own punk security Co. UK domain, this is just random AWS account, so there's no checks going on to say that I should be able to do it. So as long as you can imagine that the flow is correct, because we've spotted this condition, we should be fairly happy. This is perfectly possible attack. There are some mitigations. This isn't always possible. So just because you detect this attack doesn't mean it's always possible. I will caveat that. So if you recently had it in AWS and deleted it off, it marks those particular zones, like out of scope. No one can request them. And obviously they don't release the exact details of that. So there won't be like in three months time you can request them or six months time. Or if it's provisioned on so many other servers that it's unavailable that they don't tell you how to circumvent it, essentially. But this demo is going absolutely fantastic because we haven't found a single match yet. But yes, they won't tell you how to circumvent it. You could probably do a little bit of research into it. So sometimes this will work straight away. Sometimes it's a bit of a long brute force. I might see this running. Oh, there we go. Okay, so we finally got the first one. So DNS 99, we have managed to put that zone onto that. So I've just obviously picked a domain there. So that is how you would attack. And then we've also got seven six six now. And if we go back, I move the head out of the way and go back into AWS. We might push against the rate limit in here. Yeah, so we can see the zones it's created. And then of these some of them will have the correct name server records, which is what we're after. So we've brute forced that and now we've managed to take over that NS record. I'm just going to stop this python script. Okay. An attacker can either take over a particular domain or with the NS record, take over all the subdomains beneath it. So what can they do with that? So the first obvious one is credible phishing links. We tell our users and our customers to make sure to check that the links that they get purporting to come from us are legitimate. And that's a huge part of the human layer of defense against phishing and malware. These are legitimate, taking over domains from hacker one. So hacker one is a bug bounty platform and they do a lot of public disclosure. So if someone takes over a subdomain via that platform, they'll get a reward and ask the company if these can disclose. So you can go on there and just go through some of the ones that have been taken over. So these are legitimate ones. So the Uber one I think is really interesting. So signup uber.com, if you got an email from Uber saying you've signed up to Uber and you owe us $50 for sign up now and get $100 free Uber things, et cetera, and it's legitimate URL, there's like no way that you can see that it's not legitimate, then you're probably going to be more susceptible to it. So that's the first thing. Incredible phishing links. When we look at NS takeover, we have a slightly different vector there. So now we've got the ability to send and receive mail from those domains because we can control all the records. So we briefly touched upon different types of records. One's MX for mail here. Again, these are the legitimate URLs taken over. So help at signup uber.com. So maybe we're going to send an email now from signup uber.com saying, oh, you've signed up, here's some money. Was this definitely you sort of thing? You can respond to that email and the attacker can then respond to you. And it's all legitimate and it's not like a weird spoofed email address. So there's obviously a huge amount of power there in what you can do with the takeovers. And these, this last attack vector is the most interesting and it does require almost a second misconfiguration with some cookies on a web app. But again, it's something we see that's relatively common, particularly on microservice apps which span multiple subdomains. So let's briefly cover what are lucid scope cookies and why you should care about that. So this is the punk security website and I've just brought up the cookie tab so you can see what's going on in our cookies. So we use calendarly for some calendar scheduling and Cloudflare have handily added a token, presumably for some traffic steering or something. So we've got free cookies on our website there and you can see that on the domain column there. They all start with a dot, not sure if that's coming out on the video. So it's calendar.com is the domain and then we've got punk security Co. UK and that starts with a dot as well. So these cookies, this is legitimate website, these cookies are loosely scoped. So because that starts with a dot on the domain, any subdomain that a user goes to, so dev Punkcurity Co. UK will receive those cookies. So this is an important issue for security. So if there wasn't a dot there, that cookie which is sent automatically without any user interaction, that cookie would only get sent to people visiting Punkcurity Co. UK. They went to www dot, they wouldn't get it. So if you've got a misconfiguration in your app, or a poor misguided misconfiguration, you might say that an auth session token is required on different parts of your app. It's needed on the forum and the blog. So they go to Orf and they get a session token scoped to app.com, whatever your app is called. And now wherever domain they go to, that cookie goes over and that's login again. That's all just they get the session token and they can consume those services and you know who they are, which sounds idyllic, but actually means that if an attacker takes over any single subdomain, then the session cookies of the user are going to flow that way. So let's just see that visually so we fully understand what's going on there. So as I say, if an attacker was to take over a single subdomain, and these lucid scope cookies are punk Security Co. Uk for sessions that you just logged in, then as an attacker, if I can just trick a person to go into punk Security Co. UK, I can get those cookies and it can be as simple as I'll put an image tag somewhere. So maybe I go on another website and I pop an image tag on there that says go and get this image from Docs punk Security Co. UK it's an image of a cat meme or something, so it renders, the person doesn't really realize what's going on there, but actually their browsers made a web request over to Docs Punecurity Co. UK and when it's done that it's sent all the cookies. So just by having an image tag we can steal their session tokens. So there's a lot of danger to lucid scope cookies when we talk about subdomain takeovers. So let's have a look at what that looks like. So in this demo, which I think we should not play automatically this time, what I've done is I've just spoofed host records, for example. So this is example and these haven't got any cookies. So what we're going to do is we're going to add a cookie. So let's go in here and we'll create a cookie, called it now an orph cookie and give it a value. Now the domain there has been tightly scoped out these box. So as you read that cookie into the dev console it doesn't start with a dot. So it'll only ever go to example. So we put a dot in front of it now to loosely scope it. Just get that done. So we changed it now so that cookie goes to anything example. Then what we've done is we've aimed the host file here, we've just pretended we've got a subdomain takeover in the example DNS space. So see that now we got a quick python web server and all that does is it's going to dump out the headers. We get when people browse that page it's a really trivial thing to do. So we're going to now browse the takeover subdomain site. So here we go, subdomain example. As soon as we do that, I'll highlight it. These on the left you can see the cookie came over of cookie equals secret. So as soon as they browse that we haven't done anything. There's no weird Javascript going on. As soon as you browse that you get the cookie. If I go in here now and remove the dot so the cookie is scoped only to that domain and refresh these page and then just let the terminal run. You see the cookie is gone. So in the case these we've got a Luciscope cookie subdomain attacks become much more problematic because now we can start to leverage a subdomain takeover with the Lucid scope cookie attack and then vulnerability. And now we've got a much bigger attack. We can start stealing session tokens, et cetera, and targeting the app that way. Okay, so that is the two attack vectors that we were looking at, which is taking over a generic SaaS service behind a subdomain and then doing an NS takeover attack. And then we've looked at what an attacker can do with these subdomains once they've got them. So how do we defend against it? So DNS hygiene is really important. So this just typically doesn't happen. DNS is quite often in almost all organizations seen as a set and forget. So you'll go and configure it, but you're never tidied up afterwards. It's just a chore that doesn't happen. It's not seen as an issue. So just auditing DNS and maybe having a removal process is a good place to start bug bounty programs. So as I mentioned earlier, the hacker one program, there are other programs, there are researchers who will be looking for this sort of stuff. So you can get on that program, put a nominal fee reward on there, and people will report it when they see it. Extending pen testing scopes. So this is a real passionate point of mind, particularly coming from the DevOps side. Pen testing is still very much focused on web app big ticket Oauth top ten attacks or infra attacks with vulnerability scanning and those sort of things. We still don't see much traction on pen tests for looking at what's the state of your git repos, what's the state of your file servers, what's the state of your DNS, all these auxiliary services you've got, how are they configured and actually are they open to abuse? So extending pen testing scope is something I hope to see. And then we at punk security have built a tool called DNS Reaper to automate the process of finding these attacks. So when we looked at the GitHub pages tag, for instance, we said, actually there's a few ips that it might be for GitHub pages, and the page has got some fairly static content on there. To say that there's no Gitl pages site here, well, that's obviously dead easy to programmatically check. So we've got around 60 signatures now on DNS Reaper, and that's essentially what it does. Does DNS checks and it does web checks correlate the two to see if there's a potential attack vector that you need to just have a look at. So I'm going to quickly go on to DNS Reaper now. So it's a docker container. It is a python based tool. So you can run it in Python if you want. But we always advocate running in docker. That's what's good for functional testing. I will say DNS, completely open source by the way, so feel free to fork it, extend it, raise issues, there's no paid for model to it, there's no licensing, it's just open source. So yes, so DNS, repeat, you can either give it domains, you can give it a domain in the command line, you can give it a list of domains in a file, or you can have it fetch them. So really the power is in fetching them. So if you run it in AWS, you can just in like an ECS container or something, or an EC two, you can just have it assume a role and it will try and do that actually just out of the box. Or if it's azure Cloudflare, you basically give it API keys, it will go into your environment, it will pull all your DNS records, so you haven't got to really worry about it. You can run on a daily schedule, for instance. So it gets domains, effectively gets all those records and it tests them, as I say, with nearly 60 signatures. And we pattern match the records to say, does it match this criteria for what signature this might be? And then we have a look at the web response. So false positive rate is really, really low. And then it just outputs nicely as a screen to say if you've got any attacks, we'll see that in a second. And you also get a CSV and adjacent output. So if you did want as a pen tester, if you were bringing this into the scope of what you were doing, or you just wanted a one time audit, CSV, open it in excel or Google sheets and you can have a look at that data if you want to be programmatic with it, obviously you've got JSOn there, so you can then pivot the data. So what are the use cases for DNS repo or auditing? DNS configuration typically we see an organization will be carrying a huge amount of debt. So actually a DNS attack might not come back for three months, six months. There's a low likelihood that a service goes through this process or gets decommissioned, but actually they've not been checked for ten years. So can initial audit is generally quite fruitful. You can use it to scan for bounty. People are doing this on bubba platforms, they're using this as a detection engine, start up about 1600 stars. Now on GitHub it's quite a popular tool, about 1500 docker pools and then prevent bad deployment. So it is built to run in these pipeline as well. So what you can do as part of your deployment is you would update AWS rooted free, for instance, get to do the scan, it will file the pipeline. If it detects a detection, detects a takeover opportunity, you can then go nit that in the bud. If you're doing blue green DNS deployments, which we don't see that often, but there's a potential there for really risk conscious organizations with particularly dedicated threat actors. You could do a blue green deployment where you update DNS. DNS Reaper will pull your records in and treat them as if they are the live records. Scan it and you could prevent that switchover of zone. So that's another option. What we also typically see with DNS, just to go back to that, is that when you make a change because of the way DNS caching works, if you add a record, people can access it pretty much straight away. But if you were to remove a record, then that can be quite slow because it's cached, people will still be able to resolve it. So there's a potential that we can catch situations before they turn into attacks. So this is what DNS Reaper looks like. So a bit of ascii art, you can see all the providers there. So we support zone transfer. If you've got traditional DNS server running bind or windows enable zone transfer, whitelist the IP that DNS Reaper is coming from, because that's all what zone transfers need. And we'll just fetch all your records via zone transfer and test them. You can provide a file where we load domains in, you can have it connect to Cloudflare and fetch those AWS exactly the same. Same with digitalocean and azure. So we'll fetch all those records. You can provide a bind file. So if you've got a service like Godaddy or something, and we haven't got a provider for it, but they support bind export, you can export it and feed it into Reaper and we'll scan it that way. There's lots of different ways that you can get Reaper to ingest domains to try and save you a bit of effort when you're doing an audit. And then this is what the output looks like. So we've got these records from AWS. This is actually the attack we demoed, and then we've got the same record reported twice, just because there's one with a potential confidence. So what's happened there is, we've noticed there's a NS record provided and when we connect to that DNS server, DNS server knows nothing about it. So there's a potential that we can take that over. We see quite a lot that when that happens, maybe the DNS server you're pointing at is like an elastic IP or something in someone's infrastructure that no way can attacks is going to be able to control and therefore it's not a real thing. But it could be a SaaS service we haven't got another signature for. So we get a potential finding, there's an ARG switch, you can disable potential findings and then we've got the confirmed one. So actually not only did we notice that that DNS server knew nothing about it, it maps the AWS signature and we know that AWS is a SaaS provider for rooted free DNS and you can take it over. So we've got a confirmed finding. So quite useful to keep potentials on. But if you did want less noise on the output, you could toggle it off. We say yeah, run it with it on, and then the CSV, if there's too much noise you can just say don't do potentials. As you can see, it did that in 1.68 seconds. It is really fast to do this. I've never tested an organization that's taken more than about six or 7 seconds. There's no concern, don't disable potential to save time because it's really fast. So as I say, it's on GitHub, these was taken a few months ago, sits on one and a half thousand stars at this point. All the documentation is on there. So if you want to set it up for AWS or Cloudflare, you go into that docs folder and there'll be a guide for how to set it up. So this is the AWS one. This is basically the minimum permissions you need, which is just to get and list some DNS records. So you can just create the role, you can feed the AWS keys, but as I say, if you run it in AWS in an AWS pipeline or ECS or EC two, you can just assume that role through standard sort of boto free python means you haven't got to worry about providing keys and stuff. So yeah, that's all documented on GitHub. So that is the end of these evening's talk. So what are subdomains, how does DNS work? What are subdomains, how do we take them over? With two different attack methods, a couple of demos for doing those attacks obviously brute forcing rooted free earlier and why you should care and what you can do about it. And hopefully go and have a look at DNS Reaper. Go and have a look at your own DNS. But you save yourself a bit of time with DNS Reaper and hopefully we see less of these attacks as we go forward. There's a bit of a shameless plug as well. Punk security. To celebrate our second birthday this year we're doing a devsecops theme, CTF. So if anyone was up for that, that's on may the fourth. So that's the 4 may this year. So what's that? That is just about these and a half months away now. And yeah, devsecops these. So there'll be subdomain takeovers, attacks, they'll be abusing SaaS services, AWS, abusing access keys and looking to do stuff that way. Kubernetes breakouts. We've got rather than traditional CTF challenges around passwords, we're doing cracking jwts and ansible vaults and traditional these hack. If anyone's ever done a CTF before, they are basically bite sized challenges to get you exposed to technology with a security theme. And in this one we're going to be focusing devsecops. So how to abuse things in git, how to abuse CI CD and all those sort of things. So hopefully it's going to be really good. And yeah, if you can make it, that's may the fourth shameless plug. Our website is down there at the bottom, right? Yeah, you can go over there and get some more it on the CTF as we release it. Thank you very much for attending. Any questions at all, reach out to me on the Discord channel and yeah,