PHP2Shell: Обновите PHP перед следующим запросом

XFI Bot

Проверенные
Сообщения
1,018
Реакции
1,792
Баллы
28,930

PHP2Shell: Обновите PHP перед следующим запросом​

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

Уязвимости имеют идентификаторы и . Обе имеют оценку CVSS 4.0 равную 9,2, и их эксплуатация может произойти до того, как обычный код приложения успеет принять меры защиты.

Это проблема среды выполнения PHP. Обновление WordPress, Magento, Laravel или плагинов - всегда разумный шаг, но он не устраняет эти уязвимости. Даже прекрасно поддерживаемая CMS, построенная на уязвимом PHP, по-прежнему использует уязвимый PHP.

Что произошло​

Эти две уязвимости затрагивают разные части обработки запросов в PHP. Одна из них может привести к повреждению памяти, когда состояние «не хватает памяти» прерывает инициализацию внутренних данных запроса. Другая может оставить состояние, связанное с запросом, доступным после освобождения памяти, что позволяет последующему запросу, обрабатываемому тем же рабочим процессом, использовать устаревшие данные.

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

Проект PHP предупреждает, что под угрозой находятся системы, обслуживающие веб-запросы через PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Был продемонстрирован полноценный эксплойт без аутентификации, направленный против типичных конфигураций mod_php, а уязвимые пути также существуют в средах PHP-FPM.

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

Установите исправленную версию PHP​

Проект PHP выпустил следующие исправленные версии:
  • PHP 8.2.35
  • PHP 8.3.36
  • PHP 8.4.27
  • PHP 8.5.12
Установите исправленные пакеты, предоставленные репозиторием или поставщиком операционной системы, которую вы фактически используете. Это различие имеет значение. Debian, Ubuntu, AlmaLinux, CloudLinux, Remi, поставщики панелей управления, производители NAS и платформы управляемого хостинга могут переносить исправления, сохраняя при этом собственную схему версий пакетов. Проверьте уведомление о безопасности от поставщика, а не делайте выводы о безопасности сервера, основываясь только на первых двух цифрах в команде php -v.

После установки обновления перезапустите Apache, PHP-FPM, контейнеры или другие долго работающие PHP-процессы. Новые пакеты на диске не исправляют старые процессы, уже находящиеся в памяти.

Затем проверьте версию, используемую самим веб-сайтом. Бинарник PHP для командной строки, модуль веб-сервера, пул FPM и образ контейнера могут быть установлены по-разному. Удивительно легко обновить «вежливый» бинарник PHP, отвечающий в вашем терминале, в то время как общедоступный веб-сайт продолжает взаимодействовать со своим более старым «собратом».

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

Старым версиям PHP требуется нечто большее, чем просто оптимизм​

PHP 8.1 и более старые ветки больше не поддерживаются проектом PHP. Разработчики предоставили минимальные бэкпорты на уровне исходного кода для PHP 7.4, 8.0 и 8.1, чтобы помочь поставщикам, использующим эти версии, но это не новые поддерживаемые выпуски PHP и не являются веским поводом для бесконечного использования устаревшего стека.

Анализ Cloudflare показывает, что уязвимое поведение прослеживается вплоть до PHP 5.4. Поэтому администраторам старых приложений следует проверить, предоставляет ли их дистрибутив или коммерческий поставщик с долгосрочной поддержкой исправленный пакет. Если нет, переход на поддерживаемую версию PHP является частью мер по устранению уязвимости.

Старая версия PHP может скрываться за сайтом, который бесперебойно работал в течение многих лет. К сожалению, "он по-прежнему выдает страницы" и "он по-прежнему получает исправления безопасности" - это две совершенно разные проверки работоспособности.

Если вы не можете выполнить обновление немедленно​

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

Самым безопасным временным решением является предотвращение поступления запросов в PHP. Остановите уязвимый PHP-сервис или веб-сервис либо заблокируйте публичный доступ на уровне балансировщика нагрузки, обратного прокси-сервера или брандмауэра. Страница технического обслуживания WordPress или Magento — это не то же самое: для её отображения PHP всё равно выполняется. Перевод приложения в режим «только для чтения» также сам по себе недостаточен, поскольку уязвимая обработка происходит внутри среды выполнения, а не только при записи данных приложением.

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

В также рекомендуются временные меры по укреплению безопасности:
  • Отключите отображение прогресса загрузки в сессии с помощью session.upload_progress.enabled=0, а затем перезапустите все PHP-рабочие процессы. Установите этот параметр в файле php.ini, пуле PHP-FPM или другой конфигурации на уровне сервера, загружаемой до анализа запроса. Установка этого параметра через код приложения или файл .user.ini для этой цели будет слишком запоздалой.
  • Уменьшите значения post_max_size и upload_max_filesize до минимальных значений, необходимых приложению. Если загрузка файлов не требуется, отклоняйте многочастные запросы на веб-сервере или обратном прокси.
  • Применяйте ограничения на размер тела запроса на прокси или веб-сервере, в том числе для запросов без пригодного заголовка Content-Length.
  • В PHP 8.5 установите fatal_error_backtraces=0 и перезапустите рабочие процессы.
Эти меры ограничивают подтвержденные пути атаки, но уязвимости образуют цепочку с несколькими маршрутами. Не существует какого-либо «волшебного» параметра конфигурации, который сделал бы уязвимую сборку PHP эквивалентной исправленной.

В одном из ранних электронных писем отрасли также предлагалось включить параметр session.use_only_cookies. Это по-прежнему является разумной мерой безопасности для сеансов, но окончательные рекомендации по PHP конкретно сосредоточены на отключении возможности загрузки файлов в рамках сеанса. Ни один из этих параметров не должен задерживать обновление.

Проверьте, что происходило до установки патча​

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

Если есть признаки взлома, изолируйте сервер. Сохраните информацию, необходимую для расследования, восстановите систему из исходного кода, о котором известно, что он исправен, и смените учетные данные и секретные ключи, к которым мог получить доступ злоумышленник. Недостаточно просто сменить один пароль, если на сервере хранились учетные данные для баз данных, токены API, ключи развертывания или данные доступа к другим системам.

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

Наконец, составьте перечень ресурсов. Проверьте производственную среду, тестовую среду, среду разработки, забытые субдомены, старые проекты клиентов, CI-раннеры, аппаратные устройства и контейнеры. Интернет-сканеры не знают, какой сервер должен был быть временным, и не славятся тем, что уважают комментарии типа "TODO".

Сначала установите исправление, потом проводите расследование - ни то, ни другое не откладывайте​

Уязвимости CVE-2026-109618 и CVE-2026-109619 затрагивают уровень, лежащий в основе огромного количества веб-сайтов и приложений. Они относятся к категории критических, исправления уже доступны, а вредоносные запросы уже циркулируют в сети.

Обновитесь до исправленной сборки PHP, перезапустите все рабочие процессы и проверьте, какая версия фактически обслуживает веб-трафик. Если немедленное обновление действительно невозможно, ограничьте публичный доступ к сервису или установите перед ним временные средства защиты на время проведения технического обслуживания. Страница с уведомлением о техническом обслуживании и благие намерения не являются мерами безопасности.
​
 
О да, я как раз одна из жертв такого взлома у хостера своего. Он даже обозначил это так: Уровень уязвимости - Князь тьмы.😁 И ведь лучше не назвать, дыра очень серьёзная и притом касается абсолютно всех.
 
Последнее редактирование:
Современный облачный хостинг провайдер | Aéza
Назад
Сверху Снизу