MySQL Injection: Manual Enumeration

Friday, August 30, 2013

Let's build on last week's post and go over some manual My SQL injection techniques. After reading and trying out some combinations of manual SQLi I believe these are a good bunch to use.

If you want practice with manual SQLi I recommend loading some vulnerable web applications such as bricks, webgoat, or dvwa. You can also check out our friends at for pre-built VMs.

Although tools like SQLmap make our life easier, it is still good to know how to manually test a database.

Please remember, this is solely for educational purposes. 
The techniques mentioned below are not to be used for malicious purposes outside of a controlled research environment.

Our goal in this scenario is to use a UNION SELECT query but in order use it one must first know the number of columns in the database. Let's dive into it!

Number of Columns

Detecting the number of columns can be done in two ways. The first method is using ORDER BY clauses and increment the number of columns till an error is depicted. 

The second method is using a UNION SELECT query and incrementing NULL values.

Vulnerable Columns

Great so we determined how many columns are contained in the database, but now let's see which columns are the ones depicted by the web application on our screen. To do this we provide a false query and the UNION SELECT query.

Go Enumeration

Now that we know the number of the columns being depicted on the screen we can use those to enumerate the database. In this scenario column 1,2 and 3 are being depicted so we can use any of those to query the database and see the results.

Working Directory

Database Name

Table Name

Column Name

The first number in LIMIT is the column number (i.e. LIMIT ,1) . Increase that number to see the different columns within the database.

Pulling Column Data

We now have the database name, table name, and column names. Let's pull some data from columns named 'username' and 'password'.

Hidden Bonus: Congrats! You found a hidden bonus. Use 'file_priv from mysql.user' and 'load_file('x')' to check for LFI vulnerabilities. Remember to use this in a controlled research environment and not for malicious intentions!
 That's it! There might be some modifications one might do depending on the web app (e.g. adding quotes, comments). The mitigations to this are the same as our previous post on MS SQL injection.

MS SQL Injection: Manual Enumeration

Thursday, August 22, 2013

The following post is meant to serve as a quick reference for basic database enumeration through SQL Injection (SQLi). This syntax is
for MS SQL but with some modifications it can also be applied to MySQL.

Please remember, this is solely for educational purposes. None of the techniques mentioned should be used for malicious purposes outside of a controlled research environment. 

Most of the snippets below use provide a false query followed by the OR keyword and a true statement. The true statement will contain the SQLi. Note: One may also accomplish the same by providing two truth statements.

Database Version

Database Name

Database Username

The snippet below depicts how to obtain the username that the database is being run under.

Database Table Names 

The snippet below will provide an error message showing the first table name.

One can then use the NOT IN keyword in subsequent requests to view the rest of the tables within the database.

Database Column Names 

The snippet below will provide an error message showing the first column name.

One can then use the NOT IN keyword in subsequent requests to view the rest of the columns within the database.

Column Information

The above snippets provide one with the column names for a table and while that's great what one really wants is the information inside these columns. The following snippets depict how to obtain the information within the database. Note: The userID variable is the column name.

Go Mitigation!

The snippets above show how to successfully inject sql statements into a query. This is due to the application not implementing sufficient security checks before sending it off to the database for processing. Let us explore some ways to protect against these sort of attacks.
  • Implement a check for any SQL keywords  (e.g. SELECT, UNION, NOT IN) and bad characters (e.g. !#$%&'*+-/=?^_`{|}~@[]). If the request contains any bad keywords/characters then do not proceed with the request. Note: This is to be done on the application side before the requests get to the database.
  • Use stored procedures or prepared statements. This will ensure the attacker will not modify the intention of the query. 
  • Disable features and services which are unnecessary for operations.
  • Run the database and any applications querying the database with the lowest possible privileges.
  • Stay up to date with vendor patches after they have been thoroughly tested within your environment.

Additional Reading

  • SQLi Prevention Cheat Sheet
  • Hidden Bonus: Congrats! You found a hidden bonus. As a pentester sometimes you won't often find machines showing error messages so one would have to perform Blind SQLi. One can use the substring method to assist with this. Here's a quick example: substring(user_name(),1,5) = 'admin'.
Special thanks to uSploit on Top Hat Sec forums for a great tutorial. Be sure to check it out his blog at

Forensics with SIFT-Workstation: How to mount and build a super timeline

Sunday, August 4, 2013

 The Sift Workstation is at its core a Ubuntu Linux distribution with pre-compiled forensic tools. Although SANS does not release new versions of the operating system frequently it is still an attractive option (especially to beginners) due to its ease of use (i.e. not having to worry about installing any software).  However, it is recommended to obtain a Linux distribution of one's choosing (I prefer Ubuntu) and install/compile the tools oneself. One would have the ability to keep tools up to date and not have to worry about incompatibilities or errors due to dependency issues. Note: If you decide to go the second route I recommend using log2timeline-SIFT over the regular log2timeline as it saves a lot of time.

This post is meant as a quick reference reminding one of how to mount and build a super-timeline using the SIFT-Workstation. There are many great tutorials posted by SANS on their forensics blog, be sure to check those out too.

Mounting an Image

Mounting an image allows forensicators to view the files within an image. The mount command is available on most if not all linux distros by default and even on apple operating systems. The following commands will mount the image under /mnt/windows_mount as read only.

Mounting a physical disk image

Use mmls on the disk image to determine the offset of the desired partition you wish to mount. In most NTFS cases this will be 32256.

Mounting a logical partition image

No offsets need to be calculated since this is a logical image.

Building the Super Timeline

The super timeline consists of combining the access, creation, or modified times for the registry, event logs and the file system. SIFT has made it easier for forensicators to create a super timeline by modifying the log2timeline command and creating the log2timeline-SIFT

It is not needed to mount a physical disk image to build a super timeline as log2timeline-SIFT will mount it for you (if not previously mounted). Note: Forensicators must first mount a logical partition image before using this command.

This will create a text file under the /cases/timeline-output-folder. The next step is to use l2t_process and build a csv file allowing one to easily sort and traverse through the entries.

Forensicators can also limit the entries by a date range as shown in the following example:

That's it! Happy Investigating!