Monitor your DNS Delegations with Red-X
Sometimes I wonder if I work in a strange environment. Sometimes I wonder if other folks struggle with the same problems we do. Sometimes I wonder if other folks find my proposed solutions to said problems useful.
Nowhere is that more true than with Red-X.
In our organization, there is a huge drive for empowering each service team with the tools required to do their jobs in the most self-service manner possible. We have thoroughly embraced Cloud technologies as a means for service teams to own the entire lifecycle of their software. This includes, among other things, delegating them their own subdomains of one of our organization's domains for their own use.
Generally, it looks like this.
- We manage
organization.tldin Route53 with the excellent dnscontrol.
- Teams request delegation of
team.organization.tldto their own Route53 Hosted Zone, Google DNS Zone, or similar.
- Teams manage their own zones themselves and can create
service.team.organization.tldfor their own applications.
Route 53 Zone Hijacking
Empowering developers with self-service tools and allowing them to own their infrastructure is great, but it is fraught with danger.
The below is true for several managed, shared DNS services. At least the ones that don't support DNSSEC. I'm going to focus on Route53 so I don't need to test and enumerate all of them. And also because Red-X integrates with Route53.
You have an organization with the web address
organization.tld. You have a portal for members at
members.organization.tld. This application is controlled entirely by a small service team in your organization. As such, you delegate that domain to its own hosted zone that the developers have control over.
Later, that team moves on to V2 of the product and rebrands it as
my.organization.tld. You delegate this new zone to them as well. After a longer-than-they-think-is-reasonable sunset period, the team finally turns off V1 and they stop using
They delete their hosted zone from Route 53. Done and done. Right?
Well, if you didn't revoke your NS delegation in
organization.tld, control of the
members subdomain is still delegated to Route 53. This means that a threat actor can come along and hijack all traffic bound for that subdomain. Particularly clever attackers may even set up a phishing site to try to steal your members' credentials.
If a threat actor sees that
members.organization.tld has NS records pointing to Route53, but can't respond to any queries for itself, this is a pretty good signifier of an attack vector.
They can brute-force create Hosted Zones in Route 53 in their own AWS account until they get at least one of the four nameservers that have the delegation. Once this happens, all queries will be directed to that one matching server (as none of the other 3 will be able to answer queries for the zone) and the attacker will have full control over DNS for
Detection and Remediation
This is relatively easy to detect. Query your local DNS server to see if there are any NS records for
members.organization.tld. Then, if so, repeat that query against each of those returned nameservers.
If none of the nameservers have a result, this is a strong indication of an abandoned delegation.
If you delegate control of subdomains to teams across your organization, you'll need to put a policy in place that they inform you when they stop using it (or give them the power to revoke the delegations themselves).
Obviously, relying on manual detection and remediation is prone to error. Good news, through! I've written a Lambda function that can detect orphaned delegations within a Route 53 zone. It's called Red-X.
Simply deploy it into the same account as your
organization.tld domain, run the configuration script, and it'll start watching all of your delegations. It can alert you via email or GitLab issues if any of your delegations become abandoned or appear to be misconfigured.
Check out the project's README for more information and let us know if you encounter any bugs or have feature requests.