URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 80662
[ Назад ]

Исходное сообщение
"Уязвимость в Apache открывает двери к внутренним ресурсам на..."

Отправлено opennews , 06-Окт-11 11:00 
В http-сервере Apache обнаружена (http://www.contextis.com/research/blog/reverseproxybypass/) заслуживающая внимания уязвимость, проявляющаяся при работе в режиме обратного прокси.  При наличии определенных rewrite-правил в конфигурации сервера, уявзимость позволяет отправить запрос из внешней сети к внутренним серверам в демилитаризованной зоне (DMZ) за границей межсетевого экрана. Проблеме подвержены все версии Apache 1.3.x и Apache 2.x. Разработчики Apache уже выпустили уведомление (http://mail-archives.apache.org/mod_mbox/httpd-announce/2011...) о наличии уязвимости и патч (http://www.apache.org/dist/httpd/patches/apply_to_2.2.21/) для устранения проблемы в Apache 2.2.21.
<center><img src="https://www.opennet.ru/opennews/pics_base/31960_1317882374.png " style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>


Проблема проявляется только в Apache, настроенном для работы в режиме обратного прок...

URL: http://mail-archives.apache.org/mod_mbox/httpd-announce/2011...
Новость: https://www.opennet.ru/opennews/art.shtml?num=31960


Содержание

Сообщения в этом обсуждении
"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 11:05 
Кто-то использует апач как reverse прокси?! О_о

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено koloboid , 06-Окт-11 11:07 
да, бывает.

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено фклфт , 06-Окт-11 14:51 
> да, бывает.

ха ха ха, бывает
я еще года полтора назад в логах нечто подобное замечал а пясатели кодеры только только выпустили паТч


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 16:15 
и чего не зафайлил баг?
заметил - пости на багзиллу. чего ждать, пока другие заметят (не факт, что порядочные)

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено фклфт , 07-Окт-11 07:43 
> и чего не зафайлил баг?
> заметил - пости на багзиллу. чего ждать, пока другие заметят (не факт,
> что порядочные)

Да я даже и не предполагал что такое возможно
ну заметил в логах фаера что идут посторонние запросы с внутренних хост машин на другие компы/сервера
Ктож знал что это не баг такой а фттча от АНБ и ЦРУ


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено koloboid , 06-Окт-11 20:46 
>я еще года полтора назад в логах нечто подобное замечал а пясатели кодеры только только выпустили паТч

ну самому-то патч или баг запилить - серого вещества не достаточно, видимо. только на "ха ха ха" и хватает...


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено XoRe , 06-Окт-11 11:18 
> Кто-то использует апач как reverse прокси?! О_о

Apache + серверная java - сплошь и рядом.


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено koloboid , 06-Окт-11 11:06 
блин. ждем в debian stable.

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено klalafuda , 06-Окт-11 11:20 
А что, кто-то использует апач а не nginx как реверс? Ну тогда мы идем к вам :)

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 11:36 
Представляешь, не только nginx используют как реверсивный кэш-прокси (веб-акселератор). И апач, и memcache, и Calipso - тысячи их.

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 22:43 
> Представляешь, не только nginx используют как реверсивный кэш-прокси (веб-акселератор).
> И апач, и memcache, и Calipso - тысячи их.

Из апача конечно такой акселератор...


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено 66 , 06-Окт-11 11:59 
А умеет ли nginx ajp?
а умеет ли nginx проксировать на https?

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено klalafuda , 06-Окт-11 12:40 
> а умеет ли nginx проксировать на https?

Эээ.. А хбз. А что, ему и правда нельзя прописать в качестве бакенда HTTPS?


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено 66 , 06-Окт-11 13:12 
>> а умеет ли nginx проксировать на https?
> Эээ.. А хбз. А что, ему и правда нельзя прописать в качестве
> бакенда HTTPS?

Похоже я наврал вам, эта инфа устарела.


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено prokoudine , 06-Окт-11 11:43 
День открытых дверей в Apache? :)

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено terr0rist , 06-Окт-11 13:12 
А не проблема ли это криворуких одминов? Думая башкой, не написал бы
RewriteRule ^(.*) http://internalserver$1 [P]
а написал бы
RewriteBase /
RewriteRule ^(.*) http://internalserver/$1 [P]
и не будет никаких проблем!
А то... Если одмин забыл пароль рута поставить или закрыть ssh доступ руту, это тоже ssh виноват?

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено terr0rist , 06-Окт-11 13:20 
Пардон, просмотрел, в конце статьи это упомянуто.

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено 66 , 06-Окт-11 13:22 
> А не проблема ли это криворуких одминов? Думая башкой, не написал бы
> RewriteRule ^(.*) http://internalserver$1
> а написал бы
> RewriteBase /
> RewriteRule ^(.*) http://internalserver/$1
> и не будет никаких проблем!

Подтверждаю. Всё было изначально нормально настроено и проблема не каснулась


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 14:45 
Дело даже не в кривых rewrite-правилах, а в том простом факте, что сервер, смотрящий наружу, должен быть жестко изолирован от внутренних серверов фаерволами. Это же основы построения DMZ.

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено AlexAT , 06-Окт-11 14:46 
> Дело даже не в кривых rewrite-правилах, а в том простом факте, что
> сервер, смотрящий наружу, должен быть жестко изолирован от внутренних серверов фаерволами.
> Это же основы построения DMZ.

Ээээ. Как вам файрволы помогут в случае, если балансировщик настроен криво, и позволяет пройти сквозь него в DMZ?


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 14:51 
>Ээээ. Как вам файрволы помогут в случае, если балансировщик настроен криво, и позволяет пройти сквозь него в DMZ?

Балансировщик должен иметь доступ к сугубо внутренним серверам сети? Нет. Так зачем его разрешать?


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено AlexAT , 06-Окт-11 15:16 
> Балансировщик должен иметь доступ к сугубо внутренним серверам сети? Нет. Так зачем
> его разрешать?

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

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


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 18:22 
Заголовок - хоть сейчас в какой-нибудь псевдонаучно-фантастический сериал!
Попробуйте вслух прочитать!

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 21:55 
... на другой стороне Луны  :)

"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Аноним , 06-Окт-11 22:44 
> Заголовок - хоть сейчас в какой-нибудь псевдонаучно-фантастический сериал!
> Попробуйте вслух прочитать!

Ну, разобраться что к чему - можно. А что еще надо то?


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Xasd , 07-Окт-11 14:37 
> Заголовок - хоть сейчас в какой-нибудь псевдонаучно-фантастический сериал!
> Попробуйте вслух прочитать!

+1 .. репортёры канала РЭН-ТВ молча завидуюут :-D


"Уязвимость в Apache открывает двери к внутренним ресурсам на..."
Отправлено Xasd , 07-Окт-11 00:30 
> Проблема может быть решена при помощи патча, который запрещает передачу URI, начинающегося с символа "@" ("@other.example.com/something.png"), так как такой запрос не соответствует спецификации HTTP

пусть разрешать использовть чтобы первый знак был ТОЛЬКО "/"... или "http://" "https://"!

без всяких там ("@" первым нельзя, а остальное можно)