Podcast
Root Causes 365: What Is Subdomain Hijacking?
Hosted by
Tim Callan
Chief Compliance Officer
Jason Soroko
Fellow
Original broadcast date
February 26, 2024
In this episode we explain subdomain hijacking, including dangling subdomains and how they can constitute vulnerabilities.
Podcast Transcript
Lightly edited for flow and brevity.
Tim CallanToday, we want to define a term. This is I would say something that's emerging in visibility in the security community, and it is subdomain hijacking.
Jason SorokoTim, there's a lot of folks moving stuff into the cloud, right? Various kinds of IT workloads. And you probably have - - if you've ever worked with the public clouds at all, and that's any of them, you've probably set up websites, you've probably done a number of things that actually require IP addresses to be registered against them so that you can get to them on a network, right?
It just makes sense. And let's talk about something very specific, which is, if you have a website, it's very, very common to have a subdomain set up against that website, perhaps many subdomains, and within the DNS operations of your cloud provider, quite often there will be a specific address, an IP address, assigned to some of those subdomains. And here's what's interesting, Tim, is that what we're finding, and this is - - I'm actually surprised we haven't heard a lot more about this, but it is coming about. Basically, if you cause an orphan, let's say, somehow you change your website, and you don't go back and change the DNS settings specifically addressed from your cloud provider. Sometimes those IP addresses are still assigned to that orphaned or non- existing subdomain.
Tim CallanBecause it hasn't been assigned anything else. So it's just sitting whatever it used to be in its last state, essentially.Jason SorokoExactly, Tim. So what's not hard to imagine then is, if that IP address is still assigned to that specific subdomain, a bad guy can come along and discover that condition - and we'll talk about that more about how that discovery happens in a moment - but it basically means that that is a ripe condition for a bad guy to be able to then create a site of their own and have an IP address pointing to their site and actually act as a phony subdomain that you never intended to exist in the first place.Tim CallanRight. Yep.Jason SorokoAnd that's scary, Tim. Right?Tim CallanYeah.Jason SorokoThat's kinda scary.Tim CallanYeah. Because then like, you know, it's whatever it is it's secure dot or store dot, your brand name.com, now somebody can put something on there and it looks like it's the real domain name, right? The thing we all learn and have learned our whole lives is look at that URL and that's one of the main ways you determine if you're talking to the real thing or not. And in this case, the URL is legitimate. It's real.Jason SorokoThat's right. That's right. So you might say to me, Jay, this is, you know, that's something that we haven't heard a lot about except maybe for some news articles, and maybe a blog or two but you can imagine that this has been true since the beginning of the public clouds. And frankly, it's also been true since the dawn of the internet, when you could always have screwed up your DNS settings. Like that was always a problem. It doesn't have to be with the public clouds. It's just, I can see how it could happen. I've set up systems. I've set up subdomains and have not actively gone through and audited my DNS records to make sure that I don't have any dangling DNS records is what you could call it. An orphan subdomain addressing is another thing you could call it. What's happening here - - The reason why you're starting to hear about this now, the reason why we're calling it out is because a group called Certitude and they've got a blog on this - Thousands Of Organizations Vulnerable To Subdomain Hijacking. I invite you guys to read that. Basically, it goes right through everything we just said, but I think what has changed him is I think some of the white hats that are out there have built themselves some tooling to be able to enumerate for this condition. They can find these dangling DNS conditions. That's what's different right now.
Tim CallanYeah. Yeah. And so to play this back, the problem probably has existed, certainly has existed for a long time. There wasn't a lot of awareness of it. And now we are aware of this as a potential vulnerability, but also, this is a thing that actually does get exploited in the real world.Jason SorokoIt certainly has and with very large organizations. And I'm actually not surprised by that because if you're a really small mom and pop operation or if you're just a blog operator, perhaps you're hosting WordPress on AWS, you know, something like that, which is quite common. Your web setup is probably fairly standard, and you might actually have the time to go around and audit your DNS settings and you might as a hobbyist even just do that or have a good practice where you do that. But you can imagine, Tim, when you have thousands and thousands of subdomains, hundreds of websites and thousands of subdomains. Wow, would it ever be easy to make a mistake.Tim CallanYeah. Exactly. And so yeah, you think the complexity would definitely - - this would be directly correlative with complexity. And that also tends to be correlative with high value targets.Jason SorokoTim, I'm just looking right now. So this this group called Certitude, which, you know, we're talking about a group of white hats here, they say right in their article they have taken over blogs hosted on WordPress by the Australian Department of Foreign Affairs and Trade, the UK Meteorological Office, the State of Rhode Island, State of Nebraska, US based Verrill bank, and the list goes on and on and on. And it's almost a who's who of nearly everybody. I think if you run a website of any size at all, and you're hosting it in a public cloud, this might apply to you.Tim CallanYeah. Okay. So what do we do about it?Jason SorokoYou know, I'm anticipating that there's going to be some tooling that will come out to help you to look for these kinds of conditions. In other words, you have a DNS that has been assigned to a specific subdomain, and that subdomain might not have anything being served. In other words, either you've left the service - in other words, you've no longer so are subscribed to your public cloud, that could be a condition - but it could also be a condition of you have a website, you've changed your subdomain, and you've never changed, you never cleaned up your DNS behind it. And so there's really a couple of ways of doing it. I don't have a tool right now to say, hey, just go to this website, and they'll help you to examine this. That's probably out there. I just don't know what to tell you guys right now. But I will tell you is, from a async standpoint, maybe just get a list of all of your assigned DNS records and anything that is pointing to a subdomain, just make sure that subdomain actually exists. Now, that might be a very large job and if it is, you might have to, you know, assign some staff to that. But the homework is quite literally look at all your DNS settings, make sure it's pointing to something that's valid. If you are pointing to something that's an old subdomain that doesn't exist anymore, this problem applies to you.
Tim CallanYeah. And that's where the vulnerability is there for somebody to take that over and stand up their content and you'd really use this in kind of a, some kind of phishing or spear phishing scenario, right? The point is, we'd point you to a page that would look like, you know, I mean, it would have the real domain would make it look like exactly something you would expect and then we make you do something like log in, and we steal your log in credential or things along those lines, right? And that's just very achievable in that kind of scenario especially if there's a domain name, that's the real domain name.Jason SorokoYou got it, Tim. So, you know, this blog posts that I had pointed everybody to here, I think that they give the exact same advice on how to prevent this. However, I think that the extra little bit of labor that you and I want to put on this Tim and put it on this podcast, is with the question of wildcard domain certificates.And, Tim, you can imagine that the whole point of those things is, it's convenient. It's very convenient when you have a lot of subdomains and you might not know which subdomains you're gonna be creating in the future, you get yourself a wildcard domain certificate and what that basically means is, any subdomain you create in the future will be covered by that one certificate. Hurrah. So handy. Very convenient. But guess what? It applies to this problem in spades, as you can imagine, Tim.
Tim CallanYeah. So walk me through this scenario here. Somebody takes over a subdomain, and they are going to put their own content on it. Now, we want that obviously to be SSL certified, or we're going to get all kinds of error messages and things like that are going to happen. So are they able to use the legitimate wildcard that exists for that organization? Does that happen by default?Jason SorokoPotentially. I think that's the correct answer. Is potentially. Because there's a few different ways this attack could happen. And there's a few different ways if - - I mean, really, in very simple terms, if let's say you do have a bad guy that's targeting you, and has compromised your site, and might just create the subdomain anyway, that wildcard cert will be very handy for the bad guy, because they're already covered automatically.Tim CallanSo then are you of the opinion that if you rather than using wildcards just used single domain or multidomain certs, but non-wildcard certs for your infrastructure as a whole, that leads to a more secure situation, because there won't be a cert assigned to that particular deprecated subdomain?Jason SorokoI think it's something you should be thinking about. I would say that I am definitely not sitting here saying nobody should use wildcard certificates. I definitely am saying though, you should know why you're using them. And you should know what is the subdomain setup of my website? What's my risk surface here? If I were to be compromised, or the way that my subdomains are set up, and the way that I have my DNS settings set up, am I making life really easy for the bad guy by using a wildcard cert or a multidomain cert that has a whole lot of subdomains listed within it? I would say that from just perhaps an overly simplistic standpoint, if you have single certificates issued against your known subdomains, then it minimizes what the bad guy can do. Right? They can't just go off willy nilly and create their own subdomain against a compromised site and take advantage of your wildcard. They won't be able to do that. If you use singles, it's you know, it might be perceived as more work but in reality, it's probably going to net you more from a security standpoint.Tim CallanYeah. I think there's still certainly an exploit under those circumstances. Once somebody can control that domain, they can probably still get a DV cert against it. Right?Jason SorokoOh, Tim, I would say - -Tim CallanSo, you get a DV against that subdomain, they would use that.Jason SorokoAll they would have to do, and I hate to say this, I don't want to give lessons for how to do these real bad things but you know, I'll state it. Basically, if not just your website being compromised but if your entire cloud infrastructure, including your DNS settings are compromised, it is not that difficult at that point to have a certificate issued against your domain, in whatever way the bad guy wants. There's no question about that. In which case, having a single domain or a wildcard domain, at that point, you're so hosed it doesn't matter what search you got in the first place.Tim CallanSure. Okay. All right. So this is important. This is something that hasn't really, I think, been on a lot of people's radar but it feels like it's emerging as a viable important attack that we need to pay attention to and do something about and, you know, take steps to mitigate. Like you said, Jason, probably I would imagine that we'll see a lot of advances in tools for exactly this kind of thing as we move forward.Jason SorokoAudit your DNS settings and check out for tooling that's out there for you now, but if you got to do it manually, you got to do it manually. That's the call to arms right now.Tim CallanAll right, there you go. Thank you very much, Jason.Jason SorokoThank you, Tim.Tim CallanThis has been Root Causes.Stay informed with expert insights
Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!
