Dangling DNS: Amazon EC2 IPs (Current State)
Inspired by Matt Bryant's research on AWS dangling domains in 2015, I was able to revisit the research and apply the technique to bug bounty programs during my bug bounty journey.
Note
Shortly after writing my last blog post, I kept getting messages about creating Proof-of-concept (PoC) for this kind of issue, And I thought that I had covered most of the cases, but it turned out I was wrong. So in the post, I’ll try to tear down the technical details for this issue from a bug hunter perspective and then work on automating the process so that bug hunter can apply on a scale.
The IP address
3.5.140.229
will be used as an example during this blog post.Most of the scripts are written in Python or Bash.
EC2-Based Subdomain Takeover
Let’s start with how EC2-based subdomain takeover differs from common subdomain takeover issues (If subdomain takeover is a new term for you, I recommend Patrik Hudak Blog).
In standard subdomain takeover, we hunt. CNAME
, MX
or NS
records, while in EC2-based subdomain takeover, we hunt A
record.
Fingerprinting Phase
So how we detect if the subdomain is EC2-based? There is three possible ways for fingerprinting part:
Subdomain has
CNAME
record which match one of the following regex
If you are a fan of Nuclei templates like me, I have built a template for fingerprinting EC2-based subdomains using CNAME
records
2. Subdomain has A
record and with reverse IP lookup we get hostname which matches previous regex. We can use host
command to perform reverse lookup or using Python.
3. Subdomain has A
record which falls within Amazon IP range ip_prefix
which can be found here.
Tools which I have used to automate this step anew, httpie, mapcidr to generate file which contains all possible Amazon IPs and check if IP in file
I found this code that checks a list of IPs against a list of CIDRs and prints out IPs which fall within the range.
At this point, we have identified subdomains and IPs, which are EC2-Based. Let’s check for issues.
After completing fingerprinting phase, we found a subdomain that is EC2-Based. Now what?
Passive or Third-Party Takeover Phase
Objective:
Finding proof that our subdomain is currently taken over or had been taken over in the past by a third party.
HTTP Method
Open
http://sub.example.com/
on your browser and check for:Weird content which can't belong to
example.com
Redirection for a website that doesn't belong to
example.com
(Location header)Directories using brute force In case the response contains a blank HTML page.
Frans Rosén mentioned this technique during a talk "DNS hijacking using cloud providers" in 2017
HTTPS Method
Open
https://sub.example.com/
on your browser and check for:Weird content which can't belong to
example.com
Redirection for a website that doesn't belong to
example.com
(location header)Directories using brute force In case of the response contains a blank HTML page
Open SSL certificate data from the browser and check for (Certificate Warning by the browser):
Organization name (Org) which doesn't own
example.com
Common Name (CN) which doesn't match or belong to
example.com
Subject Alternative Name (DNS Name) which doesn't match or belong to
example.com
Archived Passive Data
We can use passive data collected by search engines like
Google
,Bing
,Shodan
andSpyse
I'll be usingShodan
in the next part.
Open
https://www.shodan.io
and search with the following querynet:ip1,ip2, ..
For our target, we will use
net:3.5.140.229
Check HTTP and SSL certificate data collected before to confirm that our subdomain was under third-party control.
We can use the Internet archive WaybackMachine to collect old snapshots for our subdomain and apply previous techniques.
We can scan ports on our target
sub.example.com
and check open ports for data to confirm the owner of the current IP.We can contact the security team to inquire about ownership of IP, but this is not possible with every company or program.
Passive detection requires creativity, OSINT skills, and monitoring. Chances for a false positive are relatively high.
You can find your method to detect vulnerable subdomains. Personally, I use previous techniques, so feel free to suggest other techniques, and I'll add them.
Active Takeover Phase
Objective:
Take over subdomain IP and assign It to EC2 Instance network interface.
First, we should know how Amazon assigns new IPs to Its customers from the IP pool so that we get our desired IP address 3.5.140.229
How does Amazon allow acquiring new IPs?
Every time EC2 Instance stops and starts, Amazon will assign a new IP address to your EC2 Instance.
Amazon allows acquiring public IP addresses using Elastic IP.
Start-Stop Method
This method was mentioned before in this blog post, so I wrote a quick script to take over3.5.140.229
, which falls within the region ap-southeast-1
. We can take over this IP and serve our content on the EC2 server to create our PoC.
This technique has a medium probability of success and can take an enormous amount of time
I found this repository very helpful with automating this method using a bash script and awscli command line.
Elastic-IP Method
This technique is more practical and faster than the stop-start method. This method has been reported before on HackerOne report. The following script is used to automate this process. Amazon allows up to 5 Elastic IPs for each account per region, so this script can be optimized using multi-threading.
If you have a limited budget on an Amazon account, you should probably keep an eye on the billing section for extra charges.
I found some GitHub repositories which automate active EC2 takeover:
Proof-of-Concept Phase
In this part, I'll explain how to create PoC for EC2-Based subdomain takeover.
Passive Takeover PoC
In this type of takeover, we don't create a traditional PoC. The only kind of PoC we attach when writing a report is the proof, which we found during Passive Phase. If we have not found proof, we monitor the subdomain for changes.
Active Takeover PoC
After successfully acquiring the IP address, we attach that IP to EC2 Instance, if it wasn't already. Then we SSH into Instance and create our takeover.html
PoC on the web server path /var/www/html/
Now when we visit http://sub.example.com/takeover.html
we should see our PoC live. If you can not access your HTTP server, ensure network access is allowed, as mentioned here.
Report Phase
At this point, you're ready to find a vulnerable EC2-Based subdomain takeover and submit a report.
If you decide to depend on Passive Takeover, You should avoid managed programs, as they still tend to ask for traditional PoC files.
Disclosed Reports
Last updated