
Образовательная демонстрация эксплуатации CVE-2024-12877 для внедрения PHP-объектов в плагин GiveWP для WordPress. Включает анализ первопричины, методы обхода регулярных выражений и безопасные практики эксплуатации.
Неделя 66 | Автор: Ali Soltani (soltanali0)
Добро пожаловать на Неделю 66 серии GO-TO CVE, где мы анализируем уязвимости, изучаем первопричины и демонстрируем практические методы эксплуатации в безопасном учебном контексте.
CVE-2024-12877 — это уязвимость PHP Object Injection в GiveWP, одном из самых популярных плагинов для пожертвований на WordPress. Небезопасное использование unserialize() на вводимых пользователем данных позволяет злоумышленникам вызывать магические методы PHP (например, __wakeup()), что потенциально может привести к:
CVSS: 9.8 Критический | Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
GiveWP используется тысячами сайтов благотворительных организаций, НПО и краудфандинговых платформ. Поскольку он обрабатывает конфиденциальные финансовые данные и данные доноров, уязвимость здесь имеет серьезные последствия. Злоумышленник, эксплуатирующий внедрение объектов, может перейти от единичного плагина к компрометации всей установки WordPress и лежащего в его основе сервера.
Основная причина: unserialize() на ненадежных входных данных.
Магические методы PHP: PHP автоматически вызывает их во время жизненного цикла объектов:
Уязвимость возникает из-за небезопасного использования функции PHP unserialize() на данных, контролируемых пользователем. Хотя unserialize() предназначена для восстановления структур данных PHP, она имеет опасный побочный эффект: при реконструкции объектов PHP автоматически вызывает магические методы.
__wakeup() – вызывается при десериализации объекта
__destruct(), __toString(), __get/__set(), __call/__callStatic() – могут быть использованы для вредоносного выполнения
Регулярные выражения: GiveWP внедрил проверки на основе регулярных выражений для обнаружения сериализованных данных. Хотя новый регекс обнаруживает больше типов данных, регулярные выражения не могут надежно предотвратить внедрение объектов.
С помощью сконструированного сериализованного объекта злоумышленник устанавливает свойства объекта, а PHP самостоятельно выполняет логику злоумышленника, вызывая магические методы.
GiveWP внедрил проверку на основе регулярных выражений, чтобы определить, были ли входные данные сериализованы. Старый регекс (неполный)
• Распознавал только массивы и объекты.
• Другие сериализованные типы (строка, целое число, булево, дробное, null) обходили обнаружение.
• Распознает все типы сериализованных данных PHP.
• Блокирует некоторые тривиальные полезные нагрузки.
• Но основная проблема остается: если unserialize() используется на пользовательских данных, регекс не спасет.
Этот фрагмент был написан для сравнения двух различных реализаций регексов:
• is_serialized_old() → старая версия, которая обнаруживает только массивы и объекты.
• is_serialized_new() → улучшенная версия, которая распознает все типы сериализованных данных PHP (массивы, объекты, строки, целые числа, булевы значения, дробные числа и null).
Мы создаем набор тестовых значений (массив, объект, строка, целое число, булево, дробное, null), сериализуем их, а затем проверяем каждое с помощью обеих функций регексов.
Простыми словами:
И после выполнения этого кода в вашем Docker вы увидите в браузере следующий результат:
Шаг 1
Шаг 2: Создайте уязвимый класс
Этот класс имеет метод __wakeup(), который будет выполняться автоматически при десериализации.
Шаг 3: Сформируйте полезную нагрузку
Шаг 4: Вывод После сохранения файла вы можете увидеть этот эксплойт:
Эксплойт:
• Старый регекс: FALSE → не смог обнаружить полезную нагрузку.
• Новый регекс: TRUE → обнаружил её как сериализованные данные.
• Выполнение: Hello RCE! → Полезная нагрузка была десериализована, и магический метод __wakeup() выполнил контролируемый злоумышленником код.
Предотвращение
• Не используйте unserialize() на ненадежных входных данных. Замените его на json_decode() или другие более безопасные альтернативы.
• Обновляйте GiveWP и все плагины WordPress.
• Разверните межсетевой экран веб-приложений (WAF) для блокировки вредоносных сериализованных полезных нагрузок.
• Следуйте принципу минимальных привилегий: запускайте PHP и учетные записи баз данных с минимально необходимыми разрешениями.
Результаты:
Ключевой вывод: Никогда не полагайтесь на регексы для защиты
unserialize(). Самый безопасный подход — вообще избегать десериализации ненадежных входных данных.
unserialize() на ненадежных входных данных; предпочитайте json_decode() или другие безопасные альтернативы.Я веду два Telegram-канала, посвященных исследованию уязвимостей и эксплуатации:
GO-TO CVE Weekly Episodes: Каждую неделю мы глубоко изучаем новую CVE и делимся подробным анализом, демонстрациями и инсайтами. 🔗 Присоединяйтесь здесь
CVEdb – Архив эксплойтов: Этот канал архивирует однодневные эксплойты и кастомные PoC для CVE. Отличный ресурс для исследователей, желающих увидеть активные методы эксплуатации. 🔗 Присоединяйтесь к CVEdb
Подписывайтесь на каналы, чтобы оставаться в курсе новейших CVE, методов эксплуатации и инсайтов в области безопасности.
Этот репозиторий предназначен строго для образовательных и исследовательских целей. Эксплуатация уязвимостей без разрешения незаконна и неэтична. Автор не несет ответственности за неправомерное использование.