Ekoparty 2017: Silk Road

CTF: EKOPARTY 2017
Points: 496
Category: Web

Description

“We will never make the same mistakes again, we challenge you to read our messages and earn some BTCs!” – DPR

https://silkroadzpvwzxxv.onion/

In this web challenge we’re presented with a website in TOR network. To access it we can use Tor Browser and torify for command line tools like curl:

The website consists of two pages:

1) Login panel:

2) Registration panel at /register that turns out to be disabled…

Testing for common vulnerabilities like SQL Injection does not provide anything useful.
Let’s take a look at headers:

The interesting thing here is the PHP version, let’s try to find some vulnerabilities.
Searching for php 7.0.8 vulnerability in google leads us to something very interesting:
http://www.securiteam.com/securitynews/5YP321PJQC.html

More about this vulnerability:
https://httpoxy.org/

Quick test:

Excellent! We crashed the application!

Now let’s setup amazon instance with Tinyproxy and set it to redirect traffic to local Apache server. The requests are made with HTTPS, so we’ll also need a domain (free from No-IP) and SSL certificate (also free from Let’s Encrypt)

After successfully setting up our server let’s see what requests are being sent:

Now we can take a look at /var/log/apache2/access.log on our server and see:

/d90cdc7988b15060c1896126cee2eae9/hiddenservice_ws.php is a valid path in challenge website, but when called with GET it only returns an empty page. Let’s now create a file /d90cdc7988b15060c1896126cee2eae9/hiddenservice_ws.php in our webserver and see what requests are coming from challenge’s server:

After making request with Proxy header once again we can see the contents of request in request.log:

Turns out hiddenservice_ws.php serves SOAP API, and the query itself is used to generate captcha word. Fun fact – the original Silk Road was tracked down by leaky captcha (at least FBI claims so…), more about it: https://krebsonsecurity.com/2014/09/dread-pirate-sunk-by-leaky-captcha/ – nice try Ekoparty ;).
Now with our proxy hack we can:

• See server queries,
• Send valid queries to real API,
• Respond with our own, changed response.

Knowing this we can try to login to the service. Sending the above request to real hiddenservice_ws.php returns the following output:

Let’s now change our script to pretend to be a server and make it send this response back:

Next request we got:

Again – we send it to the real server and check the response:

Let’s change it a little – replace

with

so that we always pass captcha validation and put it in our fake SOAP server:

The next request our fake server received from web server:

That’s the request for public key – seems like some encryption will take place. Let’s download the key from the real SOAP server and save it for later use:

Now let’s generate our own key pair for forged communication with webpage:

Let’s proceed and create fake response to getPublicKey, this time with our own key and proceed with authentication process:

Next request:

Those strings are base64 encoded and after decoding they look like some random data – let’s try to decrypt it with our private key:

Sending the query to SOAP api shows us the correct response format:

We assume that the data is encrypted using SOAP API’s private key, and the webpage uses public key it received from API to decrypt. Let’s give it a try and write our response in the format we received above, then encrypt it using our private key:

We have constructed another correct response to our fake SOAP server, let’s add it to our script:

Next request our fake API gets:

Nice – seems like we passed the authentication. Sending the query to the real API with username encrypted with server’s public key shows us another correct response format:

Decrypting the message with server’s public key gives:

It’s some structure containing user details serialized using standard PHP serialize method

Again – let’s encrypt it with our private key and add another condition to our fake SOAP script. One last request and…