[ON] Уязвимость в Apache открывает двери к внутренним ресурсам на другой стороне обратного прокси

Сообщение **rssbot** » 06.10.2011 08:34

В 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", не позволит совершить атаку.

Источник: http://www.opennet.ru/opennews/art.shtml?num=31960

оригинал на opennet.ru