SQL injection/Blind/Extraction

Expert: Automated Single-byte exfiltration

There are multiple types of single byte exfiltration attacks:

• Timing based
• Pre-computation based

The only three things that all of these methods have in common is:

• These attacks are all limited in some fashion because of local environment and latency or remote environment and dataset.
• The target environment must not filter or otherwise restrict the use of commas (,); regular expressions will not work here because injected queries are selecting rather than comparing the value of a single byte.
• You must not be afraid of programming.

Timing-based single-byte exfiltration

If not on a LAN when this technique is utilized, buggy and unpredictable results will be attained.

This testing is ideal when:

• It is taking place on a relatively low latency network
• There is access to a consistent latency and the remote page has a consistent load time (may not vary by more than 0.5 seconds)

Single byte exfiltration takes less queries to perform the same results, and leaves a smaller log footprint.

• A timer will need to be used to see how long it takes the remote server to serve the page.

Examples of timing-based single-byte exfiltration:

• Exfiltrating the first character of the database name in a single request:

AND sleep(ascii(SUBSTRING(@@DATABASE,1,1))) -- MySQL AND pg_sleep(ascii(SUBSTRING(current_database,1,1))) IS NULL -- PostgreSQL

By timing these (in seconds) the integer value of the ascii code of the first character of the database will be attained.

The comparative precomputation attack

This attack relies heavily on the remote dataset for successful exploitation and is thus less reliable than other methods. This significantly differs from previously discovered single-byte exfiltration techniques because:

It is based on precomputation It is not a timing attack

Requirements: The query which is being injecting into must have at least 254 rows The precomputation attack is compatible with all database backends.

Precomputation is done for performance reasons. At the very least, a comparative test will be required. The more complex a remote site is (random content generation, etc), the more difficult this type of attack becomes to automate.

Examining the following query: $query = "select * from articles where id=$input"; And the following uri: /articles.php?id=1 Testing can be used to see if there are 255 articles by visiting: /articles.php?id=255 Follow the next steps for automation (and sanity's) sake: Choose a language supporting something similar to array_flip() for programming the automation tool. Write a loop to download each article In the loop, populate an array (using integer indexes) with checksum hashes as values Flip the array Almost done! Then the following visit can take place: /articles.php?id=ascii(substr(user(),1,1)) Checksum the output Now accessing the checksums array using the checksum of the output as the key: $ascii_code = $checksums[$output_checksum]; And the value of a byte has been determined. Protip: This attack can be extended by: Using arithmetic operators to get sequential id's offset from 0-255 (e.g. /articles.php?id=(select ascii(substr(user(),1,1))+67) Using MySQL field operators and a static query that returns id's to bypass the requirement for the id's to be sequential