Subdomain Hijacking in the EverSec CTF (BSides Raleigh ’17)

Just in time for CarolinaCon, here is my subdomain hijacking write-up for the EverSec CTF at BSides Raleigh 2017.

Subdomain Hijacking – Introduction

Per one of the hints in the CTF, there was a possible subdomain to hijack.

The Legion of Gloom claims we have a subdomain susceptible to takeover..

While we're pretty sure they're lying, the first consultant that's able to find and take control of it before they do (or anyone else), will be handsomly rewarded!

Finding the Domain(s)

First, I attempted to use fierce to enumerate all possible subdomains of eversec.rocks. Unfortunately, either my wordlist or the tool wasn’t working properly.

That said, I finally got to give Gobuster a try during a CTF.

root@kali:~# gobuster -m dns -u eversec.rocks -w dnslist.txt 

Gobuster v1.2                OJ Reeves (@TheColonial)
=====================================================
[+] Mode         : dns
[+] Url/Domain   : eversec.rocks
[+] Threads      : 10
[+] Wordlist     : /usr/share/wordlists/dnsmap.txt
=====================================================
Found: app.eversec.rocks
=====================================================

Taking a look at the domains, it looked like Amazon S3 was hosting them.

root@kali:~# dig app.eversec.rocks

; <<>> DiG 9.10.3-P4-Debian <<>> app.eversec.rocks
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29031
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;app.eversec.rocks.		IN	A

;; ANSWER SECTION:
app.eversec.rocks.	0	IN	CNAME	app.eversec.rocks.s3.amazonaws.com.
app.eversec.rocks.s3.amazonaws.com. 0 IN CNAME	s3-directional-w.amazonaws.com.
s3-directional-w.amazonaws.com.	0 IN	CNAME	s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com.	4	IN	A	52.216.227.168

;; AUTHORITY SECTION:
s3-1-w.amazonaws.com.	1770	IN	NS	ns-1735.awsdns-24.co.uk.
s3-1-w.amazonaws.com.	1770	IN	NS	ns-294.awsdns-36.com.
s3-1-w.amazonaws.com.	1770	IN	NS	ns-978.awsdns-58.net.
s3-1-w.amazonaws.com.	1770	IN	NS	ns-1035.awsdns-01.org.

;; ADDITIONAL SECTION:
ns-294.awsdns-36.com.	67407	IN	A	205.251.193.38
ns-294.awsdns-36.com.	60138	IN	AAAA	2600:9000:5301:2600::1
ns-978.awsdns-58.net.	67249	IN	A	205.251.195.210
ns-1035.awsdns-01.org.	67550	IN	A	205.251.196.11
ns-1035.awsdns-01.org.	60433	IN	AAAA	2600:9000:5304:b00::1
ns-1735.awsdns-24.co.uk. 67249	IN	A	205.251.198.199

;; Query time: 305 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Thu Oct 26 15:09:13 EDT 2017
;; MSG SIZE  rcvd: 419

When I went to visit app.eversec.rocks, I was presented with an S3 bucket error.

CloudFront Hijack Attempt

Since I've never actually performed a subdomain hijack before, I went about this the wrong way.

The only technique that I was familiar with offhand was a CloudFront hijack. This, combined with the fact that I didn't really read the error message, led me down the wrong path.

First, I configured my AWS Console account.

Next, I registered for a CloudFront account.

I then configured my new CloudFront domain to have app.eversec.rocks point to doyler.net.

When I went to check on the new DNS entries, I also found another possible subdomain!

root@kali:~# dig blog.eversec.rocks

; <<>> DiG 9.10.3-P4-Debian <<>> blog.eversec.rocks
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2893
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;blog.eversec.rocks.		IN	A

;; ANSWER SECTION:
blog.eversec.rocks.	0	IN	CNAME	blog.eversec.rocks.s3.amazonaws.com.
blog.eversec.rocks.s3.amazonaws.com. 0 IN CNAME	s3-directional-w.amazonaws.com.
s3-directional-w.amazonaws.com.	0 IN	CNAME	s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com.	5	IN	A	52.216.97.235

;; AUTHORITY SECTION:
s3-1-w.amazonaws.com.	988	IN	NS	ns-1035.awsdns-01.org.
s3-1-w.amazonaws.com.	988	IN	NS	ns-1735.awsdns-24.co.uk.
s3-1-w.amazonaws.com.	988	IN	NS	ns-294.awsdns-36.com.
s3-1-w.amazonaws.com.	988	IN	NS	ns-978.awsdns-58.net.

;; ADDITIONAL SECTION:
ns-294.awsdns-36.com.	66625	IN	A	205.251.193.38
ns-978.awsdns-58.net.	66467	IN	A	205.251.195.210
ns-978.awsdns-58.net.	59356	IN	AAAA	2600:9000:5303:d200::1
ns-1035.awsdns-01.org.	66768	IN	A	205.251.196.11
ns-1035.awsdns-01.org.	59651	IN	AAAA	2600:9000:5304:b00::1
ns-1735.awsdns-24.co.uk. 66467	IN	A	205.251.198.199

;; Query time: 436 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Thu Oct 26 15:22:15 EDT 2017
;; MSG SIZE  rcvd: 421

Checking this, it also appeared vulnerable to a hijack.

I setup both domains to point to this blog, and began my (premature) celebration.

http://d19e46exm7yhn9.cloudfront.net -> https://www.doyler.net

http://dre6j5x03ea9n.cloudfront.net -> https://www.doyler.net

Finally, I setup an invalidation to make sure that the servers weren't caching anything.

Unfortunately, and obviously, none of this worked. The reason for this is that these weren't CloudFront domains, they were just missing S3 buckets. Once I realized that, it was time to start my process over.

S3 Hijack (For real this time)

Once I figured out what was really going on, I went and created a proper Amazon S3 account.

First, I went to my buckets page.

Then, I created a bucket for app.eversec.rocks.

First, I tried to set up a static website that redirected all requests. That didn't seem to work properly, plus didn't have the awesome "hacker" effect.

Next, I configured the bucket to host a website, and pointed it at an index.html page.

Finally, I configured the security properties on my index.html page (this took a long time, as I need some more AWS experience).

Final Payload

Due to some insistence from Gabe, I decided to make a better payload than the first one I had.

My final index.html page is below, and hopefully it is meme-filled enough for everybody.

<!DOCTYPE html>
<html>
<head>
    <title>ShadowBrokers thanks doylersec hacker</title>
</head>
<body>
    <h1>American corporate overlords have been hacked</h1>

    ShadowBrokers would like to thank @doylersec of the BSides Raleigh conference meeting for the hacking of
the EverSec subdomains. app.eversec.rocks and blog.eversec.rocks be configured by terrible developers and
hijacked by the ShadowBrokers. If EverSec for wish to have their domain back, they must work for the release
of the Legion of Gloom from the American capitalist prisons and also for to give @doylersec a prize of grand
value.

<img src="https://img.washingtonpost.com/news/the-intersect/wp-content/uploads/sites/32/2015/04/putin-
meme.jpg">
</body>
</html>

Once users visited either page, they saw my hijacked version!

Subdomain Hijacking - Conclusion

This was a really fun challenge, and I'm glad that I got to do it. That said, I wish a regular participant would have solved this one, since it was so neat.

As it turns out, blog wasn't even an intended vector, but something left over from an earlier CTF.

I know that I need more AWS experience, but subdomain hijacking is definitely an awesome attack vector.

If anyone has any tips for ways to speed up the attack (or hosting) process, then please let me know.

Be sure to compete in your next EverSec CTF, and see you at CarolinaCon!