This is part 4 of the Intro to Hacking series. Check our Parts 1 and 2 for interesting hacker stories, and Part 3 for an introduction to how passwords are stored.

We established in Part 3 that user passwords are stored in a database, but they are hashed – meaning they are stored as gobbledygook which you can’t possibly translate into the original password. Before I proceed to tell you about techniques for transforming the gobbledygook back to the password, I think it is important to establish how a hacker would obtain a hashed passwords from the database.

The most common technique is called a SQL Injection Attack. First, a little background on what SQL is. It’s a querying language for databases. Think of a database as a huge Excel document – you have rows and columns, and can potentially many different sheets all within the same Excel document. Databases have rows and columns, the sheets are called tables, and the Excel document itself is called a database. But databases are typically much larger than Excel documents – with millions of rows in some tables and potentially hundreds or thousands of tables.

The querying language allows you to navigate these behemoths and find the information you are looking for. Imagine we have a table (sheet in Excel) called — USERS with columns — USER_ID, NAME, EMAIL, and PASSWORD. A simple query would be “show me all users with the first name Brian.” A little more complex “show me all users with the first name Brian and a gmail address.” This example is still simple because all the information is stored in one table – but often the information is completely spread out and you have to navigate the web of tables to find it.

In addition to the — USERS table you might have MENU, INGREDIENTS, ORDER_HISTORY, ORDER_DETAIL and ORDER_DETAIL_INGREDIENTS tables. I’m thinking of Chipotle’s online ordering system here because honestly, when am I not thinking about Chipotle? MENU has rows like burrito, medium soda, and salad. INGREDIENTS has cheese, guac, black beans, etc. ORDER_HISTORY has the user that ordered, their price, and time. ORDER_DETAIL has the menu items part of a particular order. And ORDER_DETAIL_INGREDIENTS has the individual ingredients that went into each menu item of a particular order. With all of this information you can build some pretty complex queries: “give me all the people with gmail addresses that have used Chipotle’s online ordering system 5 times in the last 3 months, with at least one order over $20, who have ordered guac on at least one item every time, and never pinto beans.”

What does this have to do with hacking? You have to know the basics of SQL databases to understand SQL injection. This hacking technique involves injecting the hacker’s own SQL code to run against the database. How? Any form, input, or search box on the website is a place where you can type an input that gets translated into SQL. Let’s take that search box in the upper right as an example. Whatever gets entered in that search box is used in the query that searches the database. For example, here is a theoretical search in Pedantic Posts for “plantains”:

SELECT p.ID, p.Title
FROM Posts p
WHERE p.Body LIKE ‘%plantains%’

But you are mischievous. Instead of typing in plantains, you type “‘ UNION SELECT TABLE_CATALOG,
TABLE_NAME, FROM INFORMATION_SCHEMA.Tables –“. Now the query that gets run against the database is entirely different:

SELECT p.ID, p.Title
FROM Posts p
WHERE p.Body LIKE ‘%’ UNION SELECT TABLE_CATALOG,
TABLE_NAME, FROM INFORMATION_SCHEMA.Tables –%’

This in theory would return all the posts as well as all the table names in the database. Once the hacker has the table names, they could easily return a list of all the hashed passwords or even start making changes to the data (defacing the website).

Fortunately WordPress (running this site) is one step ahead of the hackerz and knows to watch out for any funny business whenever accepting query inputs from a user (there are simple ways to protect against SQL injection attacks). But not every website follows the best practices and goes through the necessary safeguards. If you use the same password on just one of these less advanced sites, your password could be hacked, and the secure site compromised as well.
 

---

 

• A bunch of links on SQL injection.
• A story of SQL injection on the ConnectU site (the Harvard rowing guys weren’t so great at security). No one at Stanford used the password “password”!

Photo: James Lee