🔓 Десериализация в PHP: как это эксплуатируют и как защититься
#php #десер #десериализация #deserialization

Десериализация — это процесс преобразования строки обратно в объект. В PHP для этого используются функции serialize() и unserialize(). Однако, если десериализовать данные из ненадёжных источников, это может стать серьёзной уязвимостью.

Как работает атака?
Рассмотрим пример кода, где используется класс с magic method (если и другие) __wakeup() — он автоматически вызывается при десериализации объекта:

<?php
class Injection {
    public $payload;

    function __wakeup() {
        eval($this->payload);
    }
}

if (isset($_REQUEST['data'])) {
    $obj = unserialize($_REQUEST['data']);
    // Дальнейшая работа с $obj
}
?>

Злоумышленник может передать специально сформированный сериализованный объект через параметр data:

O:9:"Injection":1:{s:7:"payload";s:21:"phpinfo(); // payload";}

При десериализации будет выполнена команда phpinfo(), что может открыть доступ к конфиденциальной информации о веб сервере. Более сложные payload'ы могут привести к RCE и другим атакам.

⭐️Как защититься?

➡️Избегайте использования unserialize() для входящих данных.
➡️Для обмена данными используйте более безопасные форматы, такие как JSON.
➡️Ограничьте доступные классы. Начиная с PHP 7, можно указать, какие классы разрешено десериализовать:

data = unserialize($input, ['allowed_classes' => ['SafeClass']]);

➡️Фильтруйте данные. Перед десериализацией проверяйте данные на соответствие ожидаемому формату. Не допускайте наличие кода или неожиданных объектов.
➡️Регулярно обновляйте PHP. Новые версии часто содержат исправления для известных уязвимостей. Используйте актуальную версию PHP.
➡️Проверяйте используемые библиотеки на наличие уязвимостей. К сожалению десер достаточная частая уязвимость, но не часто эксплуатируемая. На скрине вы сами видите сколько было только зарегано CVE с десериализацией. А о скольких мы не знаем?

Ваш опыт?
Сталкивались ли вы с такой багой на проектах? Какие рекомендации давали по защите? Делитесь своим опытом в комментариях)

Дополнительное чтиво
Небезопасная десериализация в PHP: Как создать собственный эксплойт - это статья от моего хорошего знакомого wr3dmast3r
Сериализация и десериализация: что это такое и как это работает - а это базовое чтиво по десеру в пыхе
PayloadsAllTheThings | PHP Deserialization - тут и так понятно что будет)

🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

(PHP) Type Juggling

Этот пост начну с предповествования.
У различных языков программирования разный подход к типизации - то есть к тому, насколько строго ЯП будет относиться к типам переменным (int, float, string и т.д.). Здесь будет идти речь о свободно типизированных языках программирования (eng: loosely typed), а в частности о PHP, как о ЯП, который собрал в себе наиболее интересные штуки, о которых рассказано далее. Данные языки стараются "предугадывать", что имел в виду программист или пользователь и делать внутри неявное преобразование переменных в другие типы. К слову, некоторые подходы могут быть применимы и к другим свободно типизорованным ЯП, например Perl, JavaScript, но у них есть своя специфика, о которой здесь рассказывать не буду.

Итак,

🟪Type Juggling - автоматическая конвертация типов в свободно типизированных языках программирования.

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

🟣Тип:
Programming Language, Web, Server-Side.

Наибольший интерес в данном ключе вызывают операции сравнения. В PHP их два вида:

📝свободное (loose): == или !=
📝строгое (strict): === иди !==

И самые интересные моменты всплывают как раз в первом типе.

🟣Пример уязвимого кода:

if (md5($user_input) == '0e732793752744629114494286417663') { ...

В данном случае если пользователь введет что-то, что при преобразовании в int будет давать 0 (например GTJ3YSmZ в md5 будет 0e{digits...}), то условие будет истинным, так как для PHP обе эти строки будут конвертироваться в 0 (данный синтаксис возводит 0 в огромную степень, что результирует в 0).

Еще один интересный пример 'abc' == 0. Данное условие будет истинным, так как в первой строке PHP будет смотреть на ее начало в поиске цифр, по ненахождению которых он будет считать строку нулем. То есть следующее условие также будет истинным: '23abc' == 23

Больше подобных сравнений я поместил в скрине к посту (источник)

🟣 Влияние:
Такие штуки помогают обходить разные условные конструкции и критичность будет зависеть от расположения подобной проблемы в коде. Один из наиболее базовых и критичных импактов - возможность обходить контроль доступа при авторизации (сравнение хешей паролей) - тут и появилось понятие "магических хешей" (magic hashes).

🟣 Как защититься?
Использовать строгое (`===`) сравнение и использовать функции password_hash(), password_verify() и hash_equals() для работы с хешами и паролями. (Ну и md5 не используйте для этих целей - он уже давно признан старым, оставьте в покое старичка).

На самом деле, в наши дни такое можно встретить только на CTF, где оно используется очень часто. Последние версии PHP умеют элегантно справляться с подобными проблемами и большинством способов обхода защиты, а даже если и используется более старая версия языка, то обнаружить эту проблему без наличия исходных кодов (и явных признаков от самого приложения) крайне сложно. Но тем не менее, знать о существовании этого очень полезно и может пригодиться во многих сферах работы.

#edu #vuln #programming #web #php #php_type_juggling #magic_hashes #type_juggling

RainLoop: от шелла через аттач, до кэша в инбоксе
#bugbounty #bughunter #багбаунти #report #php

🔥 Данная статья интересна тем, что Beget как вендор на bizone bugbounty раскрыл как их поломал багхантер hunter)

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

До этого в течение долгого времени мы предлагали пользователям RainLoop как альтернативный почтовый клиент. Однако после обнаружения уязвимости приняли решение полностью отказаться от его использования и перевели всех активных пользователей на основной, поддерживаемый интерфейс.

Если вы интересуетесь безопасностью PHP-приложений, работой с legacy-софтом или просто любите хорошие багхантерские истории, этот текст определенно для вас.

🔗Читать далее

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK

ReDisclosure. Разбираем инъекции в полнотекстовый поиск на примере MyBB
#mybb #php #sqli #sast #waf

В течение мно­гих лет ата­ки с исполь­зовани­ем SQL-инъ­екций в основном сво­дились к попыт­кам нарушить син­таксис зап­росов. Одна­ко с раз­вити­ем инс­тру­мен­тов акцент смес­тился на соз­дание «кру­тых наг­рузок» и раз­бор пре­дуп­режде­ний SAST, которые мно­гие игно­риру­ют. Я же поп­робовал поис­кать воз­можность инъ­екции без экра­ниро­вания — с мыслью о том, что на это у SAST или WAF не будет пра­вил.

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

🔓 Ксакеп

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч

1C-Bitrix <= 25.100.500 (Translate Module / Модуль Перевод) RCE CVE-2025-67887
Bitrix24 <= 25.100.300 (Translate Module / Модуль Перевод) RCE CVE-2025-67886
#1сbitrix #bitrix #1c #rce #php

Уязвимость находится в Модуль Перевод, который позволяет пользователям загружать и извлекать архивные файлы во временный каталог. Однако приложение не проверяет содержимое этих архивов перед их извлечением. Это может быть использовано злоумышленниками для загрузки и выполнения произвольного PHP-кода путем включения PHP-файла вместе со специально созданным файлом .htaccess в архив.

Для успешного использования этой уязвимости требуется учетная запись с правами SOURCE и WRITE для Модуль Перевод.

🔗PoC CVE-2025-67887 (не тестировал)
🔗PoC CVE-2025-67886 (не тестировал)

🔥 Принцип работы эксплойта
Скрипт автоматизирует процесс эксплуатации уязвимости, который можно разбить на следующие этапы:
1️⃣Аутентификация: Скрипт начинает с попытки аутентификации в системе 1C-Bitrix, используя логин и пароль, которые вы должны предоставить при запуске. Для этого он отправляет POST-запрос на страницу авторизации.
2️⃣Получение CSRF-токена: После успешного входа в систему скрипт извлекает сессионный ключ (bitrix_sessid), который необходим для защиты от межсайтовой подделки запросов (CSRF). Этот токен будет использоваться во всех последующих запросах к защищенным разделам системы.
3️⃣Загрузка вредоносного архива: Далее скрипт создает и загружает на сервер вредоносный архив rce.tar.gz. Этот архив содержит PHP-веб-шелл (shell.php). Загрузка осуществляется через AJAX-метод translate.asset.grabber.upload, который, по всей видимости, не выполняет должных проверок безопасности содержимого загружаемых файлов.
4️⃣Распаковка архива и активация шелла: После загрузки архива скрипт последовательно вызывает два других AJAX-метода: translate.asset.grabber.extract и translate.asset.grabber.apply. Эти действия приводят к распаковке архива во временную директорию на сервере, делая веб-шелл доступным по прямому URL.
5️⃣Интерактивная сессия с сервером: На последнем этапе скрипт определяет путь к загруженному веб-шеллу и входит в бесконечный цикл, предоставляя вам интерактивную командную строку для выполнения произвольных команд на целевом сервере. Каждая введенная вами команда кодируется в Base64, отправляется на веб-шелл через специальный HTTP-заголовок, выполняется на сервере, и результат возвращается вам в консоль.

p.s. Пришла 1С Битрикс и попросили написать, что они не подтверждают этой уязвимости

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч

CVE-2025-66039 (CVSS 9.3) — обход аутентификации в FreePBX Endpoint Manager
#CVE #FreePBX #AuthBypass #PHP

В модуле Endpoint Manager обнаружилась логическая ошибка при обработке аутентификации, позволяющая получить админа без пароля. Система некорректно верифицирует входящие запросы если в настройках выбран тип аутентификации webserver.

ℹ️Техническая суть

Когда FreePBX настроен с AUTHTYPE=webserver, система слепо доверяет заголовку Authorization: Basic — достаточно указать валидное имя пользователя (например, admin) с любым паролем.

Пример уязвимого запроса:

GET /admin/config.php?display=epm_advanced&view=settings HTTP/1.1
Host: target-freepbx.com
User-Agent: Mozilla/5.0...
Authorization: Basic YWRtaW46YWRtaW4=
Content-Type: application/x-www-form-urlencoded
Connection: close

❗️Защита

Обновить модуль Endpoint Manager до версий 16.0.44 / 17.0.23 или выше или, как временная мера, отключить webserver, если он не требуется.

🪲 Инструменты для детекта (nuclei правило чекает просто версию)

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч