Asset: Private Program [fig.example.com]
I began with enumerating subdomains using Sublist3r when I stumbled upon interesting subdomain
fig.example.com(I have no idea why it was interesting but it was).
http://fig.example.com/ on the browser It showed nothing but a blank page with empty HTML code, So I decided to brute force directories using Dirsearch. when I found
http://fig.example.com/includes/directory with directory listing enabled.
Then I decided to look for similar issues with affecting other subdomains. Soon after, I found two other subdomains
goose.example.com with the same issue. How did I figured it out? It’s simple it was redirecting to a totally different site.
Then I checked DNS records for
github.example.com maybe it will help me identify other subdomains with same issue.
When I realized what they all have in common “Amazon Web Service”.
At this point I decided to filter subdomains based on CNAME records, I used this tool which I have created with Python. Now let’s check for similar issue, After spending some time, I had no luck. I had to take some timeout. Then I realized what I have missed, Port scanning dah!
Asset: Private Program [emu.example.com]
Now I know that this program has serious issue with dangling DNS records.
Asset: Private Program [rev.example.com]
Now I have a list of subdomain with possible dangling DNS records with no way to make sure it’s really is. What can we do?
Let’s check SSL certificate data for
pilot.example.com And this turned out very helpful as I found SSL certificate issued for totally different Org.
2. Let’s check Shodan for archived data (SSL certificates - HTML) for
henry.example.com, And again SSL certificate issued for totally different Org.
3. Let’s use Google or Bing dorks
ip:184.108.40.206 And check for crawled data.
4. Maybe all you have to do is asking.
Asset: Private Program [ipa01.example.com]
After monitor subdomains and confirming that every subdomain has a dangling DNS record before reporting, Program asked me to supply every possible dangling record and they will confirm it all at once.
Turned out they all had a dangling DNS records, Yay!!
It’s all started on Oct 7, 2015 when Matt Bryant blogged "Fishing the AWS IP Pool for Dangling Domains" about AWS IP pool.
“What happened to that IP tied to that EC2 instance that you just killed? Well, when you terminate an instance, that IP address isn’t put to waste. Instead, it’s reused by other AWS customers. There is a massive pool of IP addresses that are constantly being recycled and trusted by various organizations and people.”
The issue happens when company use EC2 instance public DNS as
A record, without using elastic IP. If the EC2 instance is killed or terminated and the DNS not updated this will lead to creating a dangling DNS record for the subdomain. Then EC2 IP will be released to AWS IP pool, This mean it’s possible to assign the IP to new EC2 instance.
Ensure that subdomain has dangling DNS before reporting to avoid
N/A, As mentioned before. Avoid managed bug bounty programs as they required a PoC file.
Asset: Amazon (Ironically, Amazon had a similar issue)
Asset: Private Programs
Don’t ignore old researches, It might be old but not dead.
Building trust with security teams is great and it’s a two-way street.