Разработчики подобных фильтров обещают наиболее простое и дешевое решение "от всех проблем", а администраторы (в очередной раз) искренне верят в неприступность собственных систем. Но как будет рассказано на выступлении, WAF - это не долгожданная "серебряная пуля". Как и все, что создано человеком WAF имеет недостатки, которые позволяют воспользоваться уязвимостями даже на самых защищенных серверах.
Презентация с выступления на Chaos Constructions 2009:
Методы обхода Web Application Firewall
View more presentations from Dmitry Evteev.
Дмитрий, спасибо за презентацию. Материал довольно интересный. Но Вы, как я понял, основной акцент делаете на сигнатурных (black-list) механизмах работы WAF (или я невнимательно читал?)
ОтветитьУдалитьВместе с тем, современные (коммерческие) WAF в большей степени ориентированы на работу по принципу white-list, или rule-based. Я имею ввиду решения таких вендоров как Imperva, F5, возможно IBM, Citrix и т.п. (с последними пока не доводилось работать). У Вас был опыт обхода подобных решений (уже настроенных на защиту КОНКРЕТНОГО приложения?)
Да, и была упомянута такая уязвимость WAF, как отсутствие контроля возвращаемых сервером ответов. Насколько мне известно, в упомянутых решениях (возможно не во всех) такая возможность имеется.
>> Но Вы, как я понял, основной акцент делаете на сигнатурных (black-list) механизмах работы WAF (или я невнимательно читал?)
ОтветитьУдалитьВ большей степени – да, так оно и есть.
>> Вместе с тем, современные (коммерческие) WAF в большей степени ориентированы на работу по принципу white-list, или rule-based.
rule-based waf подвержены аналогичным проблемам т.к. в конечном итоге используются регулярные выражения. Балансирование между минимизацией блокирования «хорошего» трафика в логике сложного приложения и отражением «реальных атак», позволяет провести ряд атак. Кроме того, фундаментальные проблемы waf также тут работают.
Кастомизация и тюнинг waf под конкретное
приложение со сложной логикой, может потребовать достаточно много ресурсов. И эти затраты не всегда себя оправдывают. Приведу пример. Предположим, существует некое web-приложение. Мы потратили пару месяцев (или чуть больше) и контролируем весь поток данных, который приходит «к» и «из» этого приложения. При этом наши действия промышленного тестирования вызывали сбои в работе простых пользователей этой системы (косвенные финансовые потери). Далее, выходит обновление к этому приложению, в котором разработчики поменяли некоторые функции, добавили новые.... Процесс повторяется. Вывод, подобный подход может использоваться, однако для бизнес-приложений (написанных в бизнес ориентированные сроки, бизнес ориентированным кодером и т.п.), такой подход не всегда приемлем. Приходиться, чем-то жертвовать...
>> Я имею ввиду решения таких вендоров как Imperva, F5, возможно IBM, Citrix и т.п. (с последними пока не доводилось работать). У Вас был опыт обхода подобных решений (уже настроенных на защиту КОНКРЕТНОГО приложения?)
Нет, опыта обхода Imperva и F5 не было. IBM waf у меня сейчас на руках, потому обязательно покопаю в его сторону...
В светлом будущем планируем (команда PT) сделать свой cheat sheet по обходу различных waf. (постараемся охватить, как можно больше коммерческих и open source waf)
>> и была упомянута такая уязвимость WAF, как отсутствие контроля возвращаемых сервером ответов. Насколько мне известно, в упомянутых решениях (возможно не во всех) такая возможность имеется.
Безусловно, многие WAF умеют обрабатывать обратный трафик. Но, когда я рассуждал об этой проблеме, то в первую очередь я подразумевал неспособность WAF противостоять уязвимости Information Leakage (механизм есть, но его легко обойти, например, шифрованием возвращаемых данных или их абфускацией).
Добрый день. Меня зовут d0znp :) WAF я обошел вроде бы двумя может тремя способами. Напишите мне на почту, пожалуйста, я уже два письма скинул. Есть подозрение, что ваш фильтр их в спам кидает.
ОтветитьУдалитьD0znp, приветствую! Вы заняли первое место по обходу Bitrix WAF. Поздравляю! :) И в зачет два вектора атаки, в том числе, вектор атаки с обходом фильтра IE 8 xss filter. Если бы предупредили пораньше, что будите на фестивале, то подарки бы Вам вручили именно там. Ну, а так мы разминулись, и подарки уехали обратно в Москву... :) На самом деле, в ближайшее время с Вами свяжутся маркетологи Битрикса и предложат наиболее удобные способы получения подарков. А почта работает... (для связи со мной используйте devteev@ptsecurity.ru т.к. тот ящик использовался исключительно на фестивале)
ОтветитьУдалитьА Вы посмотрели работу по реальной XSS в боевом Битриксе (хак-видео №2 на СС)? Туда как раз можно применить вектор условно названный '\HEX' и под IE получить выполнение кода. А потом применить JS хитрость и обойти фильтрацию document.cookie, затем получить личные данные
ОтветитьУдалитьда. уже фиксят.
ОтветитьУдалитьобход sql фильтра типа /*union*/union/*select*/select
ОтветитьУдалитьделал но к сожелению всё уже было пофиксено
пс: в хек видео я чёто не понял про мемори ликинг
это разе был мемори ликинг ?
как я знаю мемори ликинг это не высвобождённая память (которая будет невысвобожденной пока ваще не перезапустишь сервер) а не пожераемая как показанно было в хек видео
>> делал но к сожелению всё уже было пофиксено
ОтветитьУдалитьпочему к сожалению? :-) ...мы ведь тоже работаем;)
>> в хек видео я чёто не понял про мемори ликинг
честно говоря краем полусонного глаза видел только на СС. после возвращения, так и не нашел времени, чтобы посмотреть это видео. потому ни чего сказать по этому поводу не могу...
Ну да, в общем-то... там был показан реквест который сильно нагружает апач (под завязку собственно, а не сильно) при этом непрерывно выделяется память. Соответственно во время обработки такого реквеста сервер не отвечает (в пределах допустимых выч. мощностей). Реквест будет обрабатываться сколько в конфиге зашито (по таймауту или по памяти). Вот собственно и все. Можете все сами проверить на битриксе, который вроде еще на сайте доступен (кстати, завтра его вроде бы заменят). На видео не смотрите, что CPU usage на httpd 20-30% - у меня на слабой машине все остальное занимал SnagIt которым записывалось это все ;)
ОтветитьУдалитьТак что комментарий уместен. Если придумаешь как назвать такой прожорливый реквест - так оно и будет ;)
в терминологии WASC - это просто DoS. Если такой простой термин не нравится, можно найти что-нибудь более экзотическое, например, тут http://cwe.mitre.org/data/slices/2000.html
ОтветитьУдалитьНу в общем в выводе я и написал результат - DoS. Придерживаясь спецификациям cwe.mitre.org это "Dead Code". Был не прав, признаю....
ОтветитьУдалить