Методы обхода Web Application Firewall

Бесспорно, использование WAF вызвано желанием снизить существующие угрозы со стороны атак, направленных на эксплуатацию уязвимостей в Web-приложениях.

Разработчики подобных фильтров обещают наиболее простое и дешевое решение "от всех проблем", а администраторы (в очередной раз) искренне верят в неприступность собственных систем. Но как будет рассказано на выступлении, WAF - это не долгожданная "серебряная пуля". Как и все, что создано человеком WAF имеет недостатки, которые позволяют воспользоваться уязвимостями даже на самых защищенных серверах.


Презентация с выступления на Chaos Constructions 2009:

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

  1. Дмитрий, спасибо за презентацию. Материал довольно интересный. Но Вы, как я понял, основной акцент делаете на сигнатурных (black-list) механизмах работы WAF (или я невнимательно читал?)
    Вместе с тем, современные (коммерческие) WAF в большей степени ориентированы на работу по принципу white-list, или rule-based. Я имею ввиду решения таких вендоров как Imperva, F5, возможно IBM, Citrix и т.п. (с последними пока не доводилось работать). У Вас был опыт обхода подобных решений (уже настроенных на защиту КОНКРЕТНОГО приложения?)
    Да, и была упомянута такая уязвимость WAF, как отсутствие контроля возвращаемых сервером ответов. Насколько мне известно, в упомянутых решениях (возможно не во всех) такая возможность имеется.

    ОтветитьУдалить
  2. >> Но Вы, как я понял, основной акцент делаете на сигнатурных (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 (механизм есть, но его легко обойти, например, шифрованием возвращаемых данных или их абфускацией).

    ОтветитьУдалить
  3. Добрый день. Меня зовут d0znp :) WAF я обошел вроде бы двумя может тремя способами. Напишите мне на почту, пожалуйста, я уже два письма скинул. Есть подозрение, что ваш фильтр их в спам кидает.

    ОтветитьУдалить
  4. D0znp, приветствую! Вы заняли первое место по обходу Bitrix WAF. Поздравляю! :) И в зачет два вектора атаки, в том числе, вектор атаки с обходом фильтра IE 8 xss filter. Если бы предупредили пораньше, что будите на фестивале, то подарки бы Вам вручили именно там. Ну, а так мы разминулись, и подарки уехали обратно в Москву... :) На самом деле, в ближайшее время с Вами свяжутся маркетологи Битрикса и предложат наиболее удобные способы получения подарков. А почта работает... (для связи со мной используйте devteev@ptsecurity.ru т.к. тот ящик использовался исключительно на фестивале)

    ОтветитьУдалить
  5. А Вы посмотрели работу по реальной XSS в боевом Битриксе (хак-видео №2 на СС)? Туда как раз можно применить вектор условно названный '\HEX' и под IE получить выполнение кода. А потом применить JS хитрость и обойти фильтрацию document.cookie, затем получить личные данные

    ОтветитьУдалить
  6. обход sql фильтра типа /*union*/union/*select*/select

    делал но к сожелению всё уже было пофиксено

    пс: в хек видео я чёто не понял про мемори ликинг

    это разе был мемори ликинг ?
    как я знаю мемори ликинг это не высвобождённая память (которая будет невысвобожденной пока ваще не перезапустишь сервер) а не пожераемая как показанно было в хек видео

    ОтветитьУдалить
  7. >> делал но к сожелению всё уже было пофиксено
    почему к сожалению? :-) ...мы ведь тоже работаем;)

    >> в хек видео я чёто не понял про мемори ликинг
    честно говоря краем полусонного глаза видел только на СС. после возвращения, так и не нашел времени, чтобы посмотреть это видео. потому ни чего сказать по этому поводу не могу...

    ОтветитьУдалить
  8. Ну да, в общем-то... там был показан реквест который сильно нагружает апач (под завязку собственно, а не сильно) при этом непрерывно выделяется память. Соответственно во время обработки такого реквеста сервер не отвечает (в пределах допустимых выч. мощностей). Реквест будет обрабатываться сколько в конфиге зашито (по таймауту или по памяти). Вот собственно и все. Можете все сами проверить на битриксе, который вроде еще на сайте доступен (кстати, завтра его вроде бы заменят). На видео не смотрите, что CPU usage на httpd 20-30% - у меня на слабой машине все остальное занимал SnagIt которым записывалось это все ;)
    Так что комментарий уместен. Если придумаешь как назвать такой прожорливый реквест - так оно и будет ;)

    ОтветитьУдалить
  9. в терминологии WASC - это просто DoS. Если такой простой термин не нравится, можно найти что-нибудь более экзотическое, например, тут http://cwe.mitre.org/data/slices/2000.html

    ОтветитьУдалить
  10. Ну в общем в выводе я и написал результат - DoS. Придерживаясь спецификациям cwe.mitre.org это "Dead Code". Был не прав, признаю....

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