The Name Game was a fun challenge that required players to combine code injection and some basic SQL commands.

Being fond of databases myself, I really enjoyed this challenge.  It demonstrated the importance of having your persistent data secured appropriately.  If someone gains access to a back-end database, they could potentially extract confidential, sensitive, and even proprietary information about an organization, its employees, or its customers.

Accessing the Challenge

Upon accessing the challenge, you're prompted with a terminal.  Speaking to the Minty Candycane NPC reveals that the application was built in PowerShell.  The terminal displays the following message that gives some insight into the challenge:

We just hired this new worker,
Californian or New Yorker?
Think he's making some new toy bag...
My job is to make his name tag.

Golly gee, I'm glad that you came,
I recall naught but his last name!
Use our system or your own plan,
Find the first name of our guy "Chan!"

-Bushy Evergreen

To solve this challenge, determine the new worker's first name and submit to runtoanswer.

You're then given 3 options to choose from:

Press 1 to start the onboard process.
Press 2 to verify the system.
Press q to quit.

So our goal for this challenge is to find Chan's first name.

Inspecting the Application

First, I took a look at the various options of the application.  Option 1 starts the onboard process which has you input your information.  I tried performing some light fuzzing when prompted for inputs thinking that the application might be vulnerable to SQL Injection.  I wasn't successful here, so I moved on to option 2.

Option 2 displayed a screen for validating the data store for employee onboard information; it also prompted me to enter the server address.  Entering localhost, I found that the application would ping the given server and then revealed a SQLite3 database file named onboard.db.

Dumping the Database vs. Using SQL

Talking with the Minty Candycane NPC revealed a hint in the form of a URL link for dumping a SQLite database.  This hint would indicate that you can dump the database.  Because I'm not a fan of grepping databases, I actually wanted to find the information using SQL like a real boy.  For the sake of my readers, I'll show both methods for solving this challenge.

Solving the Challenge the SQL Way

Keeping in mind what the NPC said about the application being built in PowerShell, I went back to option 2 and gave it localhost again.  This time, I also appended an ampersand (&) and followed up with the sqlite3 command to have it open the onboard.db file.

The command returned the ping results and then dropped me into a sqlite shell. From here, I was able to inspect the database to help me figure out the query I wanted to craft.

I used the .tables command to view tables in the database.  Only result came up: onboard.  Now that I had the table, I needed the table's schema so that I knew which fields to reference in my SQL query.  I accomplished this using the following command:

sqlite> PRAGMA table_info(onboard);

Now that I had the table's field (column) names, I could craft my query to get Chan's first name.  Here's the query that I used:

sqlite> SELECT * FROM onboard WHERE lname = "Chan";

The result came up as "Scott".

Solving the Challenge the Other Way

As I mentioned earlier, there is another way to solve this challenge (possibly the way the challenge designers meant for it to be solved given the hint about database dumps).  We can dump the contents of the database and grep them for "Chan".

As we've already seen, we can append to the localhost input by adding an ampersand and throwing another command behind it.  In this case, I used a SQLite command to dump the contents of the database to a file I named db.bak.

Validating data store for employee onboard information.
Enter address of server: localhost & sqlite3 onboard.db .dump > db.bak

The application will return the ping results, and then cease displaying any new information.  If you press Enter, you will return to the options display.  As long as you don't exit the challenge, your db.bak file will still be on the system.

From here, I selected option 2 again and appended a grep command to find "Chan" in db.bak.

The result shows us the INSERT command that created Chan's record in the database.

Conclusion

This challenge was a lot of fun! I always enjoy challenges that involve SQL or accessing stores of data - because that's typically where a lot of sensitive information is kept (things like passwords, social security numbers, credit card information, etc.).

While the challenge can be solved by dumping the database or using SQL, I think the better option is to use SQL.  Grepping the file in this manner won't reveal the column names and it has the potential of returning unneeded results (e.g. "Channing" or "Chandler" would also show up in the results).  It works for this challenge because it was designed to work, but you could potentially run into databases where the results are not as cut and dry using grep.