The OpenNET Project / Index page

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

Уязвимость, позволяющая совершить MITM-атаку через манипуляцию с HTTP-заголовком Proxy

19.07.2016 09:55

Опубликована информация об уязвимости под кодовым названием Httpoxy, которая охватывает достаточно большой пласт http-серверов, но может применяться для ограниченного набора серверных web-приложений, осуществляющих обращение к внешним Web API. Уязвимость вызвана дублированием назначения переменной окружения HTTP_PROXY, которая может быть выставлена как для определения системных настроек прокси-сервера, так и на основе трансляции переданного клиентом HTTP-заголовка "Proxy:" в соответствии с требованиями RFC 3875.

Создание системной переменной окружения HTTP_PROXY является достаточно простым способом для организации работы http-клиентов через прокси. Суть проблемы в том, что существует пласт полагающихся на переменную окружения HTTP_PROXY библиотек, которые могут использоваться в работающих на стороне сервера web-приложениях для обращения к внешним ресурсам, например, для отправки запросов к различным Web API, загрузки файлов или выполнения проверок (проверка наличия введённого URL, обращение к внешним службам аутентификации и т.п.). В случае передачи HTTP-заголовка "Proxy:" http-сервер также создаст переменную окружения HTTP_PROXY, но уже на основании данных пользователя, что позволяет направить все сетевые запросы уязвимого web-приложения через определённый прокси-сервер.

Предположим, что имеется CGI-скрипт, отправляющий запрос к внешнему Web API для проверки параметров аутентификации клиента и использующий для отправки этого запроса библиотеку, распознающую переменную окружения HTTP_PROXY. Обращение к этому скрипту с подставным HTTP-заголовком "Proxy:" приведёт к установке переменной окружения HTTP_PROXY и запрос будет сделан не напрямую, а через IP, указанный атакующим через заголовок "Proxy:". Направив таким способом скрипт на фиктивный обработчик API, атакующий может симулировать успешную проверку или подсмотреть приватные данные, отправляемые в составе внутреннего запроса к API.

Проблема касается только web-приложений, выполняющих внешние запросы и использующих для отправки запроса проблемные HTTP-клиенты. Например, уязвимость проявляется в программах на PHP (php-fpm, mod_php - CVE-2016-5385), использующих библиотеки Guzzle 4+ и Artax, в CGI-скриптах на Python (wsgiref.handlers.CGIHandler, twisted.web.twcgi.CGIScript - CVE-2016-1000110), использующих библиотеку Requests, в Apache Tomcat (CVE-2016-5388) и в программах на языке Go (net/http/cgi - CVE-2016-5386), применяющих модуль net/http. В Curl и Perl (libwww-perl) проблема была устранена ещё в 2001 году. В Ruby аналогичная уязвимость в Net::HTTP была исправлена в 2012 году.

Наиболее простым способом устранения уязвимости является блокирование обработки HTTP-заголовка Proxy на стороне http-сервера. Например, в Apache httpd достаточно воспользоваться модулем mod_headers.so и добавить директиву "RequestHeader unset Proxy early", а в nginx принудительно очистить переменную HTTP_PROXY директивой "fastcgi_param HTTP_PROXY ''".

  1. Главная ссылка к новости (http://openwall.com/lists/oss-...)
  2. OpenNews: Уязвимость в Apache открывает двери к внутренним ресурсам на другой стороне обратного прокси
  3. OpenNews: Новый метод атаки на обратный прокси Apache
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/44809-proxy
Ключевые слова: proxy, http
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Alex_K (??), 10:51, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Каким образом mod_php уязвим?
     
     
  • 2.3, Аноним (-), 11:05, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В mod_php эмулируется установка переменных окружения CGI.
     
     
  • 3.31, Аноним (-), 23:07, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Неправда.
     

  • 1.2, Аноним11677 (ok), 10:54, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Все существующие технологии IT, библиотеки, программы — это одно большее решето и свалка. Начиная от самих процессоров, которые уже исполняют не точно необходимый для выполнения конкретной задачи код, а черте что, месиво из инструкций, порожденных абстракциями на абстракциях (как с вебом с его песочницами), так, что никаких гигагерц не хватает.

    Вот так и здесь, кто-то когда-то, в лохматых бородатых годах добавил какую-то сиюминутную фичу, не оттестировав/не продумав до конца — и она живёт и ждет своего часа, чтобы взорваться, потому что КОД НИКТО НЕ ЧИТАЕТ (как бы не заверяли в обратном особо ярые сторонники OSS).

     
     
  • 2.5, Аноним (-), 11:12, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вообще-то теми кто читает код проблема была исправлена ещё 15 лет назад.

    Проблема не в аудите кода, а в том, одни умники назвали переменную окружения одинаково с CGI-переменной, уже до этого определённой в RFС, а другие не подумав добавили поддержку этой переменной окружения в свои библиотеки. В библиотеках вообще через переменные окружения ничего не должно настраиваться, это изначально огромная потенциальная дыра.

     
     
  • 3.9, fdsa (ok), 11:25, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    С каких пор RFC стал спецификацией ?
     
     
  • 4.17, Sw00p aka Jerom (?), 12:27, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    )) вот почему все протоколы в Ж?
     
  • 4.36, XoRe (ok), 23:45, 20/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > С каких пор RFC стал спецификацией ?

    Уже лет 20-25 как.

     
  • 2.7, Аноним (-), 11:20, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ну покажете свой, недырявый уже 30 лет, добротный код - мы тут все поаплодируем!
     
     
  • 3.12, Аноним (-), 11:45, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    клоун: программы продаются не за аплодисменты.

    И почему 30 лет? Ты сам то используешь хоть одну программу 30-летней давности?

     
     
  • 4.19, pkdr (ok), 13:02, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты как обычно тупой бот от мелкомягких демонстрируешь своё отвратительное качество, то что твои криворукие создатели-индусы ничего не умеют, кроме того, чтобы щёлкать мышкой ещё не значит, что здоровые люди не пользуются таким софтом.

    Навскидку, ls, grep, ed, sed, vi, dd, cp, rm, cat ... десятки их, а то и сотни.

     
     
  • 5.32, Аноним (-), 07:16, 20/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >ls, grep, ed, sed, vi, dd, cp, rm, cat

    Примеры не канают. Это, если угодно, элементы кровеносной системы ОС, выполняющие свои **маленькие узкие** (привет юникс вей) обязанности, пускай и очень важные. Даже говоря о гнутых binutils/coreutils, эти существуют чёрти знает сколько времени, а помножив на размер кода, они должны быть не просто отшлифованы, а отполированы до ослепительного блеска.

     
  • 4.20, Andrey Mitrofanov (?), 13:04, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Ты сам то используешь хоть одну программу 30-летней давности?

    GNU Emacs.

    А ты?

     
     
  • 5.22, Аноним (-), 14:12, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А он MS DOS :-))
     
  • 2.15, Аноним (-), 12:02, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Согласен. Хотелось бы как в математике. Сейчас полный разброд, шатание и костыли в этом IT. До сих пор есть разные ОС, компьютерные ресурсы не объединены, нет единых стандартов..
     
  • 2.18, Sw00p aka Jerom (?), 12:33, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    соглашусь только с этим КОД НИКТО НЕ ЧИТАЕТ.

    пс: по сей день используем бородатый код.

     
     
  • 3.23, _ (??), 16:20, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >соглашусь только с этим КОД НИКТО НЕ ЧИТАЕТ.

    Ну и ты, скорее уже съешь этих хрустяших французких булок!
    Ведь как только ТЫ прочьтешь код всё наладится! Да?

    >пс: по сей день используем бородатый код.

    И снова - скорее уже съешь этих хрустяших французких булок!
    Бородатый код это СКАЛА! А где ты видел скалы без трещинок? :)
    Впрочем желаю тебе пользовать только новодел ... это изощрённая китайская  пытка :)

     
     
  • 4.27, Sw00p aka Jerom (?), 17:04, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>Ведь как только ТЫ прочьтешь код всё наладится! Да?

    как бы выразиться правильнее, как только Я читаю код (имеется ввиду гитхабный опенсорс), повеситься хочется!!! (не принимайте это предложение как инструкция к самоубийству).

    Качество КОДа за последние 10 лет опустилось ниже плинтуса.

    >>Бородатый код это СКАЛА! А где ты видел скалы без трещинок? :)

    А вот и нет, по мне это асм.

    >>Впрочем желаю тебе пользовать только новодел

    что есть новодел, уточните!

     
  • 3.24, _ (??), 16:27, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >пс: по сей день используем бородатый код.

    Я думаю с одного раза до тебя не дойдёт. Поэтому:
    Бородатый Перл - пофиксили в 2001 году.
    Рябе - через ___11___ лет :)
    Пых - смотри новость, но его невозможно пофиксить, место проклятое :)

     

  • 1.4, Володя (??), 11:10, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В guzzle уже пофиксили https://github.com/guzzle/guzzle/commit/9d521b23146cb6cedd772770a2617fd6cbdb15
     
     
  • 2.6, Аноним (-), 11:14, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это называется исправили?

    +        if (php_sapi_name() == 'cli' && getenv('HTTP_PROXY')) {
    +            $defaults['proxy']['http'] = getenv('HTTP_PROXY');

    Убрали проявление дыры при работе через mod_php, но оставили при запуске в режиме CGI.

     
     
  • 3.8, Володя (??), 11:24, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Будь так добр, отправь им PR!
     
  • 3.16, пох (?), 12:11, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это называется исправили?

    учитывая невозможность оторвать руки изобретателям env var HTTP_PROXY (где дерьмово все - начиная от самой идеи и заканчивая названием) - да, исправили единственным доступным способом.

    > Убрали проявление дыры при работе через mod_php, но оставили при запуске в режиме CGI.

    малыш, иди обратно в песочницу лепить куличики.

    Взрослый человек сперва бы подумал, что такое php_sapi_name()

     

  • 1.11, Аноним (-), 11:43, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я что-то не понял каким образом это можно в Go проэксплуатировать. Если запустить приложение с переменной окружения HTTP_PROXY=192.168.0.1:3128, то оно будет обращаться к адресу через proxy. Если же в go приложение передать заголовок curl -H "Proxy: 192.168.0.1:3128" http://mygoapp, то оно огнорирует заголовок.
     
     
  • 2.13, Аноним (-), 11:48, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже не всё так страшно. https://golang.org/src/net/http/transport.go#L212
     
  • 2.14, Сиромант (?), 11:51, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя Go запускается как классическое приложение CGI, по процессу на запрос (если так кто-то ещё делает, конечно), то веб-сервер может помещать в переменную среды HTTP_PROXY содержимое заголовка Proxy.
     

  • 1.21, непонятно (?), 13:57, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > В Curl и Perl (libwww-perl) проблема была устранена ещё в 2001 году.

    Ахахах, олдскул vs хипсторы — 1:0

    :D

     
     
  • 2.30, DimasiQ (?), 20:06, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А при чем тут хипстеры?
    Что-то не вижу в списке уязвимых node.js.
     
     
  • 3.33, Аноним (-), 08:07, 20/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не мешай алтфакам воевать с воображаемыми хипсторами.
     

  • 1.25, Аноним (-), 16:35, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    И в чём беда? Прокси пользователя ничем не лучше и не хуже любого друго хоста на пути трафика.
    Хотите безопасности - https.
    Можно разве что сделать сервер недоступным (в рамках сессии одного пользователя) и тем самым обойти какую-нибудь проверку по чёрному списку.
    Но ведь в этом слуае отсутствие ответа не должно восприниматься как пустой ответ. Иначе при недоступности сервера все пройдут проверку.
     
     
  • 2.26, Andrey Mitrofanov (?), 16:39, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И в чём беда? Прокси пользователя ничем не лучше и не хуже
    > любого друго хоста на пути трафика.

    Вы не поняли, пытайтесь.

    > Хотите безопасности - https.

    Адресочек для трененровки паранойи подсказать, или тебе не надо, ты здоров?

    > ответ. Иначе при недоступности сервера все пройдут проверку.

     
     
  • 3.29, Аноним (-), 18:53, 19/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> И в чём беда? Прокси пользователя ничем не лучше и не хуже
    >> любого друго хоста на пути трафика.
    > Вы не поняли, пытайтесь.

    Тот самый крайне редкий случай, когда Митрофанов относительно адекватен.

     
     
  • 4.34, Andrey Mitrofanov (?), 10:05, 20/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>> И в чём беда? Прокси пользователя ничем не лучше и не хуже
    >>> любого друго хоста на пути трафика.
    >> Вы не поняли, пытайтесь.
    > Тот самый крайне редкий случай, когда Митрофанов относительно адекватен.

    //На такое оскорбленеие я не могу не ответить

    Может, он имел в виду того МИТМ-атакера под "пользователем прокси"? Тогда, да, ошибочка -- он точно не хуже, не лучше других.

     

  • 1.28, Ilya Indigo (ok), 17:34, 19/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >php-fpm, mod_php

    А в php-fastcgi проблема отсутствует?

     
  • 1.35, Аноним (-), 23:19, 20/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Для nginx лучше закрываться на уровне хттп, а не фастцги.

    В контексте server:

    if ( $http_proxy ) { return 403 ; }

     
  • 1.37, Володя (??), 18:39, 21/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В PHP оперативненько пофиксили https://bugs.php.net/bug.php?id=72573
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



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

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