CVE-2024-38475
Apache mod_rewrite: запрос может попасть к неожиданному файлу
В Apache HTTP Server до 2.4.60 некоторые правила преобразования адресов могли открыть путь к файлам, которые не планировали публиковать по этим адресам. Проверьте правила уровня сервера и обновление Apache, не отключая защиту ради совместимости.
Кому нужно проверить
Администраторам Apache и разработчикам сайтов со сложной маршрутизацией, виртуальными хостами и подстановкой частей адреса. На управляемом хостинге проверку серверных правил должен выполнить провайдер. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Правило перенаправления внутри сервера похоже на указатель: по адресу страницы оно выбирает, какой файл обработать. Если начало пути строится из недоверенного значения, указатель может привести к неожиданному месту. Apache подтверждает раскрытие исходного кода или выполнение кода при подходящих настройках. При этом речь идёт о местах файловой системы, которые разрешено обслуживать серверу: ошибка не означает безусловного чтения любого файла операционной системы. Ограничения доступа и способ запуска скриптов остаются существенными условиями.
Затронутые версии
Apache HTTP Server 2.4.0–2.4.59 включительно с затронутыми правилами mod_rewrite. Advisory выделяет подстановки в контексте сервера, у которых первый сегмент начинается с переменной или обратной ссылки — значения, захваченного из совпавшей части адреса. Получившийся путь может совпасть с расположением файла, который серверу разрешено обслуживать, но к которому не предполагался прямой доступ через URL. Не всякое правило RewriteRule и не любой сайт с Apache автоматически затронуты.
Исправленные версии
Первое upstream-исправление включено в Apache HTTP Server 2.4.60. Выбирайте актуальное поддерживаемое обновление поставщика, поскольку исторический релиз 2.4.60 не является общей гарантией безопасности. Для системного пакета проверьте backport по уведомлению ОС. После исправления часть прежних правил может перестать работать; это требует пересмотра правил, а не автоматического добавления UnsafePrefixStat.
Что сделать
- 1Узнайте версию установленного Apache и статус исправления у поставщика. Определите, какие серверные и виртуальные конфигурации реально используются, включая подключаемые файлы. Не ограничивайтесь .htaccess: advisory описывает серверный контекст.
- 2На локальной копии конфигурации найдите RewriteRule, где подстановка начинается с переменной или захваченного значения. Разберите, какие значения доступны посетителю и может ли результат стать неожиданным путём к файлу. Универсальная строка поиска не доказывает безопасность: порядок правил и контекст должен проверить администратор.
- 3До обновления по возможности отключите только затронутый маршрут или ограничьте к нему доступ доверенными пользователями. Сначала проверьте влияние на сайт. Это временная изоляция, а не исправление; фильтр отдельных подозрительных адресов не доказывает, что обход невозможен.
- 4Сохраните конфигурацию, данные сайта и проверенный способ восстановления. На отдельной тестовой среде установите поддерживаемый исправленный пакет и проверьте каталог, поиск, личный кабинет и другие обычные адреса. Для проверки отказов используйте только свои тестовые файлы без секретов, а не рабочие конфигурации или исходники с паролями.
- 5Если правило перестало работать, исправьте его так, чтобы допустимые назначения были ограничены заранее. Не добавляйте UnsafePrefixStat вслепую: этот флаг возвращает поведение, требующее самостоятельной проверки безопасности подстановки. Согласуйте новое правило с разработчиком и документацией Apache.
- 6После проверки синтаксиса примените обновление штатным способом вашего сервера. Подготовьте откат пакета и конфигурации; если приходится вернуть уязвимую сборку, оставьте спорный маршрут закрытым. Проверьте версию работающего сервиса, доступность штатных страниц и ошибки маршрутизации.
- 7Просмотрите журналы обращений и изменения файлов за период риска. Не делайте вывод о взломе по одному необычному адресу: сопоставляйте его с ответом сервера и доступным в тот момент правилом. При признаках раскрытия секретов переходите к их замене и расследованию.
Как адрес превращается в путь к файлу
Посетитель задаёт часть адреса. Права и обработчик определяют, будет ли файл раскрыт или выполнен.
- 1Посетитель задаёт часть адреса.
- 2Правило помещает это значение в начало подстановки.
- 3Результат совпадает с неожиданным путём файловой системы.
- 4Права и обработчик определяют, будет ли файл раскрыт или выполнен.
Примеры конфигурации и проверки
httpd -vПример для Unix-подобной системы, где исполняемый файл обслуживающего сайт Apache называется httpd и доступен в PATH. Запускайте на своём сервере обычным пользователем, без sudo. Ожидается Server version; команда не перезапускает службу и не меняет конфигурацию, откат не нужен. Если поставщик использует другое имя или путь, возьмите его из документации пакета, не устанавливайте второй Apache ради этой команды. Результат не подтверждает набор backport-патчей, активные правила или версию уже работающего процесса.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.