Июл 19, 2016 - 0 Comments - Интересно -

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

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

Опубликована информация об уязвимости под кодовым названием 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
Тип: Проблемы безопасности
Ключевые слова: proxy, http
При перепечатке указание ссылки на opennet.ru обязательно

 
 
 
 
+2 +/
Ты как обычно тупой бот от мелкомягких демонстрируешь своё отвратительное качество, то что твои криворукие создатели-индусы ничего не умеют, кроме того, чтобы щёлкать мышкой ещё не значит, что здоровые люди не пользуются таким софтом.

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

 
 
+/
>соглашусь только с этим КОД НИКТО НЕ ЧИТАЕТ.

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

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

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

 
 
+/
>>Ведь как только ТЫ прочьтешь код всё наладится! Да?

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

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

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

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

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

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

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

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

 
 
 
–1 +/
> Это называется исправили?

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

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

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

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

 
 
+/
Если у тебя Go запускается как классическое приложение CGI, по процессу на запрос (если так кто-то ещё делает, конечно), то веб-сервер может помещать в переменную среды HTTP_PROXY содержимое заголовка Proxy.
 
 
+/
> И в чём беда? Прокси пользователя ничем не лучше и не хуже
> любого друго хоста на пути трафика.

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

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

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

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

 

 Добавить комментарий

Навигация

Let’s block ads! (Why?)


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Человек ? *