A significant portion of cloud services are coupled with a domain name service (DNS) component. The lifecycle of these cloud services, unfortunately, can sometimes exclude an enforcement of decommissioning checks when such services are no longer in use. DNS records pointing to deleted or expired cloud artifacts – ones not yet purged from name servers – create dangling DNS records. Subdomain takeover vulnerabilities may occur when these artifacts are able to be reclaimed and controlled by nefarious actors through manipulation of DNS entries.
subdomain.example.com CNAME reference.example.com
In this scenario, reference.example.com was deleted or expired. As part of a decommissioning check, the DNS entry for subdomain.example.com was unfortunately not updated so now reference.example.com can be re-registered by anyone. Subdomain.example.com can then be controlled by a nefarious actor that took control of reference.example.com. There are three actors in this particular scenario – domain owner, reference owner, and the DNS record manager.
A subdomain takeover attack may go undetected by a domain owner if the reference owner simply claims the domain and decides to launch a phishing campaign mimicking previously hosted content. Other risks include cookie stealing and public resolver cache poisoning – diverting Internet traffic away from legitimate servers and towards fake ones. Cache poisoning can have a dangerous cascading effect as DNS servers often depend on each other for reconciliation of an entry. It is difficult to detect this attack after it happens unless the organization or domain owner has a monitoring system that checks for abnormalities, including content.
Adobe’s “Project Hijack” is an internal, proactive effort to continuously monitor and identify expired domains to help avoid a subdomain takeover vulnerability. As part of this, we developed a tool codenamed “Jaeger”. Jaeger is able to leverage recognition patterns that were built by studying various publicly disclosed bounty reports. It also provides an efficient watchdog process and helps create feedback loops with teams who are trying to avoid such takeovers.
The tool, written in Python3, implements a monitoring scheme that uses:
- An enumeration of domains and subdomains owned by a system/organization. Eg. <org>.<com|org|in|…>. The tool makes use of the open source “subjack” and “Sublist3r” libraries for discovery in generic scans with a top level domain (TLD) as input.
- Evaluation of DNS query results on these domains and subdomains – CNAME, A, MX and NS. While CNAME references have an industry-observed high volume of subdomain takeover attempts, incomplete CloudOps practices may make NS, A and MX records equally susceptible. This step is also helpful in identifying any dead DNS entries that need to be removed from system records.
- Checks against reference query results for expired cloud artifacts. Cloud providers generally have distinct “not available” signatures associated with their cloud services. This makes it easier to identify expired assets. The tool makes use of the open source library “Can I take over XYZ” for up-to-date signatures. For example, a query to an expired S3 bucket will return “NoSuchBucket” with a “404 Not found” http response.
- Establishment of a follow up process to sanitize dangling records. A scan can be scheduled according to our cloud service lifecycle and reports can be generated in JSON, routed to Splunk, sent as an email, or sent as an alert in Slack.
At Adobe, Jaeger runs constantly using one of our established internal data sources called “Marinus” for domains and generates reports in Splunk.
Mitigation, prevention, and avoidance of a subdomain takeover attack, does need to be coordinated between a domain owner and DNS record manager. DNS entries are known to be particularly fragile, so these steps must be taken manually by an experienced engineer. Once a vulnerable domain or subdomain is discovered, a subdomain takeover may be mitigated by deleting or updating the DNS entry after confirming the state of any associated cloud services.
We are planning to offer Jaeger as an open source tool in the near future. We will provide more information via the Security@Adobe blog once it is released. Please let us know about your interest on Twitter @AdobeSecurity. You can also learn more about this project on our recent webcast with the Cloud Security Alliance.