Как обойти WAF на примере Akamai

В предыдущей статье мы уже рассказывали про обход WAF с помощью SQLmap и Tor. Сегодня продолжим и на примере Akamai, рассмотрим тонкости обхода защитных механизмов WAF. К концу этого урока вы не только получите понимание существующих механизмов защиты, но и приобретете знания и навыки, необходимые для создания собственных полезных нагрузок.

Еще по теме: Обход WAF короткой полезной нагрузкой XSS

Статья в образовательных целях для обучения этичных хакеров. БагБаунти — программа, которую владелец сайта (web-приложения) проводит для привлечения сторонних специалистов к поиску уязвимостей. При участии в программе Bug Bounty нужно действовать этично и придерживаться установленных правил.

Как обойти WAF Akamai

Любой пентест обхода WAF (Web Application Firewall) начинается с поиска точки проникновения — пресловутой трещины в крепостной броне. Так и мое путешествие началось с того, что я наткнулся на конечную точку, где присутствие параметра returnUrl светило как маяк в ночи.

Кнопка Try Again (Повторите попытку) — это место, куда внедряется наша полезная нагрузка

Будучи пентестером, мы всегда автоматически вводим нашу полезную нагрузку javascript:alert(1), но в ответ я получил следующее:

Теперь перейдем к анализу — я удалил все после javascript:, чтобы проверить, есть ли у меня доступ к протоколу JavaScript, и, к счастью, я его получил:

Обнаружив, что alert после javascript: заблокирован, я перешел к проверке блокировки других распространенных функций JavaScript. Я попробовал javascript:prompt(), javascript:console.log() и javascript:eval(), но все попытки закончились неудачей.

Стало очевидно, что меры безопасности веб-приложения эффективно пресекают мои первоначальные попытки.

Не унывая, я решил исследовать более сложные функции JavaScript, чтобы определить, могут ли они обойти защиту. Я протестировал, в частности, функции javascript:atob() и String.fromCharCode(), но все попытки заканчивались одинаково — неудачей.

После долгих попыток я обнаружил, что функция decodeURI() остается незаблокированной, что открывает потенциальный путь для использования уязвимости.

По данным Mozilla. Функция decodeURI() декодирует унифицированный идентификатор ресурса (URI), созданный ранее с помощью encodeURI() или аналогичной процедуры.

Работает это следующим образом: По сути, когда мы используем такую функцию, как javascript:decodeURI("<h1>vita</h1>"), а затем нажимаем на кнопку Try Againg (Попробовать еще раз), мы можем увидеть результат декодированного URI, который будет отображен, как показано ниже:

На скрине выше результат нажатия на кнопку Try Againg.

Теперь оставалось углубиться и вставить в функцию decodeURI полезную нагрузку типа <img src="x" />, чтобы добиться XSS, но и тут я получил результат:

Даже без onerror=alert(1) я все равно столкнулся с той же ошибкой, что говорит о том, что WAF эффективно отфильтровывает вредоносные теги.

Я просмотрел все теги все они были заблокированы кроме одного тега <button></button>.

Поэтому я впервые попробовал использовать <button autofocus="">test</button> и да! Я снова был заблокирован:

WAF продолжал проверять обработчики событий, но я не стал терять времени. Я быстро начал перебор всех обработчиков событий, чтобы определить, какой из них вызвал ответ:

Из всего массива обработчиков событий только onbeforetoggle смог обойти механизм блокировки.

После этого я зашел на PortSwigger и составил список полезных нагрузок, включающих тег <button></button> и обработчик события onbeforetoggle, и обнаружил, что это единственные два доступных варианта:

Я попробовал оба варианта, но ни один из них не увенчался успехом, прежде всего потому, что WAF эффективно блокировал alert(1).

Но как же мне удалось решить эту проблему? По сути, после ‘ javascript:’ есть возможность объявить переменные. Поэтому я применил немного творческого подхода и разделил функцию alert() на три отдельные переменные, примерно так:

Затем я объединил эти переменные в строку внутри функции decodeURI, в результате чего получилась конечная полезная нагрузка, которая выглядела следующим образом:

И вот результат:

Заключение

В заключение хотелось бы отметить, что в результате моего общения с Akamai было выяснено, что данная проблема была оперативно решена и исправлена. Таким образом, полезная нагрузка больше не может быть использована.

ПОЛЕЗНЫЕ ССЫЛКИ:

• Инструменты для определения WAF
• Атака на API веб-приложения Django
• Популярные полезные нагрузки XSS для баг-баунти