Застрял на одной CTF-задаче (речь о легальных соревнованиях Capture The Flag) и нужна помощь сообщества, чтобы двигаться дальше. Речь идет о реверс-инжиниринге небольшой самописной программы на C++, которая использует кастомный алгоритм шифрования.

Что я уже сделал: Декомпилировал бинарник с помощью Ghidra. Выделил ключевые функции, отвечающие за кодирование и проверку флага. Попытался проанализировать логику алгоритма — похоже, он использует XOR с динамически генерируемой ключевой последовательностью, основанной на текущем индексе символа. Логика генерации ключа запутанная. Кажется, там используется псевдослучайный генератор с состоянием, которое обновляется после каждого символа. Мой брутфорс по пространству ключей ни к чему не привел.

Есть ли у кого-нибудь опыт анализа подобных "кастомных" криптосистем?

Какие инструменты или методы, кроме статического анализа в Ghidra, могут быть полезны? Может, стоит попробовать динамический анализ с gdb с скриптами для дампа состояния памяти?

Может, я упускаю что-то очевидное в арифметических операциях?

Буду рад если кто поможет.

Проблемы получили идентификаторы CVE-2025-48827 и CVE-2025-48828, и обе получили 9 баллов из 10 возможных по шкале оценки уязвимостей CVSS. Уязвимости связаны с возможностью произвольно вызывать методы через API и удаленно выполнять произвольный код за счет эксплуатации движка шаблонов.

Баги затрагивают vBulletin версий от 5.0.0 до 5.7.5, а также от 6.0.0 до 6.0.3, если платформа работает на PHP 8.1 или более поздней версии.

Судя по всему, обе проблемы были тихо устранены еще в прошлом году, с выпуском Patch Level 1 для всех версий ветки 6.*, а также в Patch Level 3 для версии 5.7.5. Однако многие сайты по-прежнему остаются уязвимыми, так как на них не устанавливали обновления.

Обе уязвимости обнаружил и описал независимый ИБ-исследователь Эгидио Романо (Egidio Romano), также известный под ником EgiX. Специалист продемонстрировал, что корень проблемы заключается в некорректном использовании vBulletin PHP Reflection API, который позволяет вызывать защищенные методы без явного изменения их уровня доступа (после изменений, появившихся в PHP 8.1).

Эксплуатация уязвимостей строится вокруг возможности вызова защищенных методов через специально созданные URL-адреса, а также ошибок при обработке шаблонов.

Используя уязвимый метод replaceAdTemplate, атакующий может внедрять специально сформированный код шаблона. При этом он может обойти фильтры unsafe function, например, с помощью вызова функций через переменные в PHP. В результате это приведет к удаленному выполнению кода на сервере, по сути, предоставив хакеру шелл-доступ.

На прошлой неделе ИБ-специалист Райан Дьюхерст (Ryan Dewhurst) сообщил о первых попытках атак на CVE-2025-48827. Логи ханипота показали запросы к уязвимому эндпоинту ajax/api/ad/replaceAdTemplate.  Дьюхерст пишет, что сумел отследить одного из злоумышленников до Польши. Этот хакер пытался установить PHP-бэкдоры, чтобы иметь возможность выполнять системные команды.

Исследователь отмечает, что атакующие используют эксплоит, опубликованный Романо, хотя шаблоны Nuclei для этих проблем тоже уже доступны. При этом пока нет признаков того, что хакерам уже удалось построить на базе CVE-2025-48827 полную RCE-цепочку.

🔥 Топ-5 уязвимостей, которые всё ещё работают (и приносят бабло)

1. Insecure Direct Object References (IDOR)

Что это: Доступ к чужим данным через подмену ID в запросе (например, ?user_id=123 → ?user_id=124).
Где искать: API, мобильные приложения, личные кабинеты.
Эксплуатация:

GET /api/v1/profile?user_id=1337 HTTP/1.1  
Host: target.com  
Authorization: Bearer <токен_жертвы>  

Защита: Валидация прав доступа на сервере.

2. Server-Side Request Forgery (SSRF)

Что это: Заставить сервер делать запросы во внутреннюю сеть (например, к AWS Metadata API).
Где искать: Функции импорта URL, webhooks, PDF-генераторы.
Эксплуатация:

POST /generate-pdf HTTP/1.1  
Host: target.com  
Content-Type: application/json  

{"url": "http://169.254.169.254/latest/meta-data/"}  

Защита: Блокировка внутренних IP, использование allow-листов.

3. GraphQL Injection

Что это: Уязвимости в GraphQL-API (интроспекция, DOS через глубокие вложенные запросы).
Где искать: Современные SPA, мобильные приложения.
Эксплуатация:

query {  
  __schema {  
    types { name }  
  }  
}  

Защита: Отключение интроспекции в продакшене, лимит глубины запросов.

4. JWT Misconfiguration

Что это: Подделка токенов из-за слабого алгоритма (например, "alg": "none").
Где искать: Веб-приложения с авторизацией.
Эксплуатация:

1. Меняем HS256 на none в заголовке.

2. Удаляем подпись.

3. Profit.
   Защита: Использовать только RS256, проверять алгоритм на сервере.

5. OAuth Misconfiguration

Что это: Кража токенов через открытые редиректы или поддельные callback-URL.
Где искать: Вход через Google/Facebook/GitHub.
Эксплуатация:

https://oauth.target.com/auth?response_type=token&redirect_uri=https://evil.com/callback  

Защита: Фиксированный allow-list для redirect_uri.

🔧 Инструменты для автоматического поиска

• Burp Suite (ручной аудит)

• OWASP ZAP (автосканер)

• GraphQLmap (для GraphQL-инъекций)

• JWT_Tool (для взлома JWT)

• SSRF Sheriff (поиск SSRF)

💡 Советы по пентесту

✅ Всегда проверяй новые API — там часто забывают про безопасность.
✅ Ищи неочевидные параметры (например, ?debug=true).
✅ Тестируй мобильные приложения — их API часто уязвимы.
✅ Используй автоматизацию, но не доверяй ей слепо — ручной анализ важнее.

⚠️ Legal Disclaimer

Этот гайд только для образовательных целей и легального тестирования. Взлом без разрешения уголовное преступление.

ШАГ 1: "Фикс" файловых инклюдов
Заменил все include($_GET) на красивый switch-case с белым списком. Тест работает! Но забыл, что в 300-й строке есть ещё один include, который тянет файлы через file_get_contents()...

ШАГ 2: Борьба с SQLi
Поставил везде PDO, но в одном месте остался старый запрос вида:

$query = "SELECT * FROM users WHERE id=" . $_POST; // "а тут и так сойдёт"

Решил "временно" заменить на intval()... и конечно, через неделю этот костыль задеплоили в прод.

ШАГ 3: Эпик фейл
А потом пришёл пентестер (читай злобный коллега) и за 5 минут вынес весь сервис: Через file_get_contents() прочитал /etc/passwd (путь не фильтровался). В том самом "исправленном" SQL нашёл SECOND-ORDER инъекцию оказалось, id позже пишется в кэш и снова подставляется в запрос. А backup.php? А он таки принимал shell-команды через параметр ?action=rm -rf /var/www/*

Развязка:

• Полчаса даунтайма

• Восстановление из бэкапа (спасибо девопсам!)

• Позор на весь отдел

• И главный урок: НЕ ПЫТАЙТЕСЬ ЧИНИТЬ БЕЗОПАСНОСТЬ НА ЖИВУЮ

Советы от бывалого: Тестируйте фиксы локально даже если "оно же очевидно работает!". Ставьте WAF хотя бы для логирования атак (потом будете рыдать над логами). Если код выглядит как "лажа, но работает" лучше перепишите, а не латайте. Всегда держите под рукой алкоголь. Серьёзно.