The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

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

  1. Главная ссылка к новости (http://mail-archives.apache.or...)
  2. OpenNews: Релиз http-сервера Apache 2.2.21
  3. OpenNews: Релиз http-сервера Apache 2.2.20 с устранением DoS-уязвимости
  4. OpenNews: Найден способ обхода методов защиты от DoS-уязвимости в HTTP-сервере Apache
  5. OpenNews: Легко эксплуатируемая DoS-уязвимость в HTTP-сервере Apache (дополнено)
  6. OpenNews: Несколько локальных уязвимостей в Apache suexec
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/31960-apache
Ключевые слова: apache, http, proxy, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (-), 11:05, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кто-то использует апач как reverse прокси?! О_о
     
     
  • 2.4, koloboid (ok), 11:07, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да, бывает.
     
     
  • 3.21, фклфт (ok), 14:51, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > да, бывает.

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

     
     
  • 4.25, Аноним (-), 16:15, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и чего не зафайлил баг?
    заметил - пости на багзиллу. чего ждать, пока другие заметят (не факт, что порядочные)
     
     
  • 5.33, фклфт (ok), 07:43, 07/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > и чего не зафайлил баг?
    > заметил - пости на багзиллу. чего ждать, пока другие заметят (не факт,
    > что порядочные)

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

     
  • 4.28, koloboid (ok), 20:46, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >я еще года полтора назад в логах нечто подобное замечал а пясатели кодеры только только выпустили паТч

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

     
  • 2.5, XoRe (ok), 11:18, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кто-то использует апач как reverse прокси?! О_о

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

     

  • 1.3, koloboid (ok), 11:06, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    блин. ждем в debian stable.
     
  • 1.6, klalafuda (?), 11:20, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    А что, кто-то использует апач а не nginx как реверс? Ну тогда мы идем к вам :)
     
     
  • 2.7, Аноним (-), 11:36, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Представляешь, не только nginx используют как реверсивный кэш-прокси (веб-акселератор). И апач, и memcache, и Calipso - тысячи их.
     
     
  • 3.30, Аноним (-), 22:43, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Представляешь, не только nginx используют как реверсивный кэш-прокси (веб-акселератор).
    > И апач, и memcache, и Calipso - тысячи их.

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

     
  • 2.9, 66 (?), 11:59, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А умеет ли nginx ajp?
    а умеет ли nginx проксировать на https?
     
     
  • 3.11, klalafuda (?), 12:40, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > а умеет ли nginx проксировать на https?

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

     
     
  • 4.13, 66 (?), 13:12, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> а умеет ли nginx проксировать на https?
    > Эээ.. А хбз. А что, ему и правда нельзя прописать в качестве
    > бакенда HTTPS?

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

     

  • 1.8, prokoudine (??), 11:43, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    День открытых дверей в Apache? :)
     
  • 1.14, terr0rist (ok), 13:12, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А не проблема ли это криворуких одминов? Думая башкой, не написал бы
    RewriteRule ^(.*) http://internalserver$1 [P]
    а написал бы
    RewriteBase /
    RewriteRule ^(.*) http://internalserver/$1 [P]
    и не будет никаких проблем!
    А то... Если одмин забыл пароль рута поставить или закрыть ssh доступ руту, это тоже ssh виноват?
     
     
  • 2.15, terr0rist (ok), 13:20, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Пардон, просмотрел, в конце статьи это упомянуто.
     
  • 2.16, 66 (?), 13:22, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А не проблема ли это криворуких одминов? Думая башкой, не написал бы
    > RewriteRule ^(.*) http://internalserver$1
    > а написал бы
    > RewriteBase /
    > RewriteRule ^(.*) http://internalserver/$1
    > и не будет никаких проблем!

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

     

  • 1.18, Аноним (-), 14:45, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дело даже не в кривых rewrite-правилах, а в том простом факте, что сервер, смотрящий наружу, должен быть жестко изолирован от внутренних серверов фаерволами. Это же основы построения DMZ.
     
     
  • 2.19, AlexAT (ok), 14:46, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Дело даже не в кривых rewrite-правилах, а в том простом факте, что
    > сервер, смотрящий наружу, должен быть жестко изолирован от внутренних серверов фаерволами.
    > Это же основы построения DMZ.

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

     
     
  • 3.20, Аноним (-), 14:51, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ээээ. Как вам файрволы помогут в случае, если балансировщик настроен криво, и позволяет пройти сквозь него в DMZ?

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

     
     
  • 4.23, AlexAT (ok), 15:16, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Балансировщик должен иметь доступ к сугубо внутренним серверам сети? Нет. Так зачем
    > его разрешать?

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

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

     

  • 1.26, Аноним (-), 18:22, 06/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Заголовок - хоть сейчас в какой-нибудь псевдонаучно-фантастический сериал!
    Попробуйте вслух прочитать!
     
     
  • 2.29, Аноним (-), 21:55, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ... на другой стороне Луны  :)
     
  • 2.31, Аноним (-), 22:44, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Заголовок - хоть сейчас в какой-нибудь псевдонаучно-фантастический сериал!
    > Попробуйте вслух прочитать!

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

     
  • 2.34, Xasd (ok), 14:37, 07/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Заголовок - хоть сейчас в какой-нибудь псевдонаучно-фантастический сериал!
    > Попробуйте вслух прочитать!

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

     

  • 1.32, Xasd (ok), 00:30, 07/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Проблема может быть решена при помощи патча, который запрещает передачу URI, начинающегося с символа "@" ("@other.example.com/something.png"), так как такой запрос не соответствует спецификации HTTP

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

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру