Hacking Xmas
Days 4+5

jakec / dec 2020

Were you at the beach on an old laptop tethered to a phone on Day 4? Bereft at the absence of your 43” 4K monitor (*slaps screen* this bad boy can fit so many terminal windows in it) you might not have taken any screenshots of your progress either. But that’s okay, because we’re gonna whip through it anyway. Day 4 is another brute-forcing challenge, specifically “fuzzing” — a type of brute-forcing where the objective isn’t just to guess the right thing, but maybe cause an error that we can turn into something. If brute-forcing in general is like running at a brick wall until you break through it, fuzzing is also slapping it around and calling it names. Today’s software, Gobuster and wfuzz, work very similarly to the brute-forcing we did with Burp Suite: we set up an attack by giving the software a target and then specify some parameters that we want it to try a million different words on.

Maybe you should watch the video and see if you can get it on your own.

Day 5, on the other hand, gave a lot of people trouble. One of them was me. Let’s talk about SQL Injection.


To make a website, you need a few things: a machine (physical or virtual) to hold all the files that make up the website (images, text, videos etc); software to handle serving the pages (you can think of this like a waiter if you want, handling the relationship between you/your browser and what’s happening in the back-end by bringing you the piping hot #content you’ve ordered); a database (something that organises all the website data and tells the server how it’s related, e.g. that your password is related to your username, and not someone else’s) and a language to tell the database how to organise that data.

The most popular language for working with databases is called SQL, the Structured Query Language. You use it every day without knowing. When you register an account on a website, for example, you tell a form that you want your username to be “cavillStan520” and your password to be “tossACo1n2urWitcher”. To store this information, the form then assigns “cavillStan520” to a variable like “$user” and “tossACo1n2urWitcher” to a variable like “$password” and inserts it into a SQL statement which is sent to the database that looks something like:

INSERT INTO users (username, password) VALUES ($user, $password);

(You’ll typically also get a unique ID that automatically increments, e.g. if you’re the fifth person to sign up, your ID might be 5.)

Now, the website’s database will look like this:

Table name: users
id username password
5 cavillStan520 tossACo1n2urWitcher

When you want to retrieve data, you’d write something like this:

SELECT * FROM users WHERE username = “cavillStan520”;

And that’d retrieve the whole row of information about your user for you to work with.

If you made your website right, a user will never have to know what the SQL that talks to your database looks like. It should all be set up by the developers in such a way that you type some information into a pretty form and get straight to whatever you wanted to do on the site. But as we’ve talked about, it’s very easy to get it wrong — the web wasn’t set up to do things securely, only to do things. So sometimes, when you see a web form, you can actually manipulate what the SQL is doing. This is called SQL Injection.

I’ll paraphrase Swafox’s explanation on THM because I think it’s pretty succinct.

Say we have a login form and the SQL query that makes it work is:

SELECT username, password FROM users WHERE username=’$username’ and password=’$password’.

When you type in your username ($username) and password ($password), it’ll check the database for a row that matches both in its “username” and “password” columns like above. e.g. SELECT username, password FROM users WHERE username=”cavillStan520” and password=”tosssACo1n2urWitcher”.

But if, instead of our username, we type:

‘ or true —

into the username box, the SQL query will end up like this instead:

SELECT username, password FROM users WHERE username = ‘’ or true — and password = ‘’;

In SQL, to write a comment (i.e. something that won’t be executed as code, but just a note inside the code for developers to read) you type “--” before a statement. So in my SQL script, I could write “-- This line inserts the username and password into the database.” But we can use it here to comment out anything in the SQL query after it. So the above query will instead be processed as:

SELECT username, password FROM users WHERE username = ‘’ or true;

In other words, if the username is blank, or true = true, show me the username and password. Well, unlike in philosophy, in programming, true always = true. So we should get a list of all the usernames and passwords in the users table.

Let’s go to our vulnerable website and try it for ourselves. The first step is to bypass the login.

Okay, that was easy.

Here’s Santa’s database of all the children and what they want for Christmas. Let’s try a quick and dirty manual SQL injection to get the whole table, rather than trying to guess the names of any of the kids in there.

Okay, that was easy too. Right off the bat we can answer some of the challenge questions: How many entries are in the gift database? 22. What did Paul ask for? GitHub ownership. But to get the flag and the admin password, let’s get automated.

We open Burp Suite, turn on our proxy so it will intercept everything we do on the web, and then do a search in the gift database again. Burp gets our request, so we export it to a file. And then we open SQLMap, a program that will try what we did manually but in many different ways, very quickly.

We tell SQLMap to look at our file (burpsanta3), that the database software is “sqlite” (I found this out from an earlier scan; there are many different kinds of databases but don’t worry about this too much), and that we want to dump everything it finds into the terminal window for us to read.

After a minute, it starts giving us useful info from the database. For example, there’s a hidden table (called hidden_table…) with a column called “flag” and the value “thmfox{All_I_Want_for_Christmas_Is_You}. Awwwwww.

There’s also a table called “sequels” which has all the children and what they want for Christmas.

And a table called “users” with one row: username “admin” and password “EhCNSWzzFP6sc7gB”. Nice.

That answers all the questions for today’s challenge. Now you should have an idea of how important it is to secure your database; just by using the tools designed for it (e.g. particular SQL queries, including the comment syntax) attackers can access a lot of information, including usernames and passwords. Explaining all the ways you can secure a SQL database would take a whole other piece. Fortunately, Positive Technologies have written a wonderful one here.