 |
Адрес в интернете: https://news.hostdb.ru/index/show/id/4888 |
Уязвимость в Apache открывает двери к внутренним ресурсам на другой стороне обратного прокси
В http-сервере Apache обнаружена заслуживающая внимания уязвимость, проявляющаяся при работе в режиме обратного прокси. При наличии определенных rewrite-правил в конфигурации сервера, уявзимость позволяет отправить запрос из внешней сети к внутренним серверам в демилитаризованной зоне (DMZ) за границей межсетевого экрана. Проблеме подвержены все версии Apache 1.3.x и Apache 2.x. Разработчики Apache уже выпустили уведомление о наличии уязвимости и патч для устранения проблемы в Apache 2.2.21.
Проблема проявляется только в Apache, настроенном для работы в режиме обратного прокси (reverse proxy), т.е. который принимает внешние запросы и транслирует их на один или несколько внутренних ресурсов, напрямую недоступных из вне и, как правило, находящихся во внутренней сети предприятия.
Для формирования правил проброса запросов для определенного вида контента часто используется директива RewriteRule или ProxyPassMatch с типичными правилами преобразования запроса. Например:
RewriteRule (.*).(jpg|gif|png) http://images.example.com$1.$2 [P">
ProxyPassMatch (.*).(jpg|gif|png) http://images.example.com$1.$2
При наличии подобных правил атакующий может отправить запрос "GET @other.example.com/something.png HTTP/1.1", что приведет не к обращению к серверу images.example.com, как того требуют правила трансляции, а к соединению с другим внутренним сервером other.example.com. При этом начальная часть "images.example.com@" будет воспринята и передана как часть URL с параметрами аутентификации (http://логин:пароль@хост:порт/путь?параметры). Зная примерно какая внутренняя подсеть используется в сети предприятия, просканировать наличие внутренних http-серверов в локальной сети можно через перебор внутренних IP-адресов, используя примерно такие запросы "GET @10.0.0.1 HTTP/1.0" или с явным указанием номера порта "GET :@10.0.0.1:8080 HTTP/1.0".
В качестве других примеров, можно привести следующие правила преобразования:
RewriteRule ^(.*) http://internalserver$1 [P">
RewriteRule ^(.*) http://internalserver:80$1 [P">
Rewriterule ^/images(.*) http://InternalImageServer$1
RewriteRule ^(.*) http://internalserver$1
для данных правил атакующий может передать следующие запросы:
GET @server2/console HTTP/1.0
GET 80/console HTTP/1.0
GET /images@server2/console HTTP/1.0
GET :@localhost:8080 HTTP/1.0
и получить в итоге преобразования переход по таким URL:
http://internalserver@server2/console
http://internalserver:8080/console
http://InternalImageServer@server2/console
http://InternalImageServer:@localhost:8080/console
Проблема может быть решена при помощи патча, который запрещает передачу URI, начинающегося с символа "@" ("@other.example.com/something.png"), так как такой запрос не соответствует спецификации HTTP. Другой вариант решения проблемы - использование символа "/" в правилах преобразования запросов, т.е. указание "http://images.example.com/$1.$2" вместо "http://images.example.com$1.$2" или "http://internalserver/$1" вместо "http://internalserver$1", не позволит совершить атаку.
Распечатано с HostDB.ru.