Как сломать сервер без обновления PHP. НА Пальцах

Содержание статьи

Привет! Я Григорий Мельников, создатель KillBot. Сегодня расставлю акценты, чтобы тебе стало понятно, как злоумышленник может взломать твой сервер через уже известные уязвимости PHP2Shell (CVE-2026-109618 и CVE-2026-109619).

Принцип работы этих уязвимостей уже раскрыт в других статьях на Хабре, например тут.

ЛЮБОЙ PHP код атакующего будет выполнен внутри процесса PHP на твоем сервере, еще ДО того, как начнёт выполняться твой код. То есть сначала сработает код злоумышленника, а уже потом — твои валидаторы, проверки и прочая защита на уровне приложения.

Какие есть ограничения?

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

Если PHP работает с правами администратора системы — то, «да простится тебе эта ошибка!». Но обычно на Ubuntu с Apache и mod_php используется пользователь www-data.

Хакер, это тот же пользователь www-data, который прямо сейчас обрабатывает процессы твоего сайта. Хакер сможет делать всё, что разрешено этому пользователю.

А теперь давай посмотрим, что обычно разрешено процессу PHP на твоём сайте:

Читать исходники сайта? Конечно!
Читать конфигурационный файл с паролем MySQL? Естественно!
Записывать файлы в каталог сайта? У многих — ДА!
Запускать системные команды? Если отдельно не ограничивал — тоже ДА!

С этим мы живем, и это отличная возможность хакеру обнулить тебя.

И для этого ему не потребовался ни пароль администратора к сайту, ни доступ по SSH.

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

ПРИМЕР: как можно обнулить сайт практически на ЛЮБОЙ CMS через PHP2Shell!

Допустим, твой сайт работает под управлением CMS под названием BEST-CMS-IN-THE-WORLD. Исходники этой CMS открыты, и все знают, что конфигурационный файл лежит по пути:

$config = ‘/var/www/html/site.ru/config.php’;

А в этом файлике находится стандартная конфигурация подключения к базе данных:

<?php $db_host = ‘127.0.0.1’; $db_name = ‘website’; $db_user = ‘website_user’; $db_password = ‘PASSWORD’;

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

А если пользователь базы данных website_user у тебя с правами ROOT, то атакующий просто создаст своего пользователя — и это будет огромный BACK DOOR внутрь твоего сайта. Опять же про это читайте в другой статье.

Например, последовательность действий злоумышленника может выглядеть так:

Убедится, что может выполнять свой код внутри PHP.
Найти конфигурационный файл.
Прочитать параметры подключения к MySQL.
Подключиться к базе данных от имени пользователя CMS.
Проверить доступные привилегии.
Использовать разрешённые операции для получения доступа к твоему серверу.

А ЕСЛИ PHP МОЖЕТ ЗАПИСЫВАТЬ ФАЙЛЫ В КАТАЛОГ САЙТА?

Если твой PHP процесс позволяет создавать файлы в папку с сайтом, то атакующий просто сделает так:

<?php //создаем файл, который позволит выполнять любые команды через url file_put_contents(«/var/www/html/site.ru/hack.php», ‘<?php echo shell_exec($_GET[«c»]); ?>’);

После этого запроc типа https://site.ru/hack.php?c=”rm /var/www/html/*” сможет полностью удалить папку с твоим сайтом.

Т.е. порядок действий примерно такой:

Атакующий получил выполнение PHP-кода.
Ищет каталог куда можно писать файлы.
Создаёт исполняемый PHP-файл.
Имеет возможность бесконечного обращения к файлу через HTTP.

ВАЖНО! Если ты установил патч закрывающий PHP дыру, проверь что у тебя на сервере нет левых файлов которые злоумышленник оставил до этого на особый случай.

А если у меня все сделано грамотно, и сайт по максимому защищен так:

Исходники сайта принадлежат отдельному пользователю и недоступны PHP на запись.
Каталоги загрузок не выполняют PHP.
Опасные функции запуска процессов отключены.
open_basedir ограничивает доступ PHP к файловым путям.
Пользователь MySQL имеет минимальные привилегии.
Каждый сайт работает под отдельным системным пользователем.

То тогда

Злоумышленник всё ещё сможет выполнять код внутри твоего PHP (если php патч не установлен).
Он сможет обращаться к данным, которые доступны php, читать разрешённые файлы и выполнять допустимые операции в базе.

Возможности закрепиться на сервере у атакующего или не будет или щанс на это существенно снизится. А это уже серьёзное ограничение ущерба.

А если у меня старый PHP и я технически НЕ могу его обновить ???

Выход один — вынести приём и фильтрацию интернет-трафика на отдельный защищённый прокси-сервер. Тут есть такие варианты:

Самое простое — перед сайтом поставить свой прокси сервер с уже закрытой PHP уязвимостью.
Использовать сторонний сервер Cloudflare, Килбот или любой другой.

ВАЖНО! Нужно запретить трафик на свой старый не защищенный сервер в обход нового прокси сервера который ты поставил перед своим сайтом!

Нужно прямо в фаерволе запретить приём трафика c любого другого IP кроме как с IP твоего прокси сервера.

ЕСЛИ не запретить приём трафика со всех IP кроме разрешенного, то атакующий сделает так:

curl -k -H «Host: example.com» https://93.184.216 # или curl -k —resolve example.com:443:93.184.216.34 https://example.com/

И запрос пойдет именно на твой реальный сервер, даже если в ДНС А записях ты прописал IP защищенного прокси сервера. Злоумышленник сам узнает реальный IP твоего сайта, даже если ты его нигде не светишь.

ЧТО НУЖНО СДЕЛАТЬ ПРЯМО СЕГОДНЯ

Обновить PHP до исправленной версии.
Запретить запись в исходники сайта пользователю PHP. Разрешать запись только для тех папок, где она действительно необходима.
Запретить выполнение PHP в каталогах загрузок. Никакие фотографии, документы и временные файлы не должны превращаться в исполняемые PHP-скрипты.
Проверить disable_functions в php.ini. Пустая disable_functions в сочетании с разрешением писать файлы — путь к безграничному доступу к твоему серверу.
Проверить права MySQL. Никаких root, CREATE USER, GRANT OPTION и других лишних административных прав у обычного сайта.
Разнести сайты по отдельным системным пользователям. Чтобы компрометация одного сайта не означала автоматический доступ к файлам соседнего.
Если обновить PHP пока невозможно — поставить перед сервером защищённый reverse proxy. И через iptables запретить весь прямой входящий веб-трафик, кроме доверенных IP защитного прокси.
Проверить, не взломан ли сервер уже сейчас. Пройдитесь поиском на наличие новых файлов которые могли появиться за две недели до этого момента. Атакующий не действует сразу!

Обнови сервак сейчас, если не сделал ранее. ИЛИ завтра твой сайт будет лежать.