Обнаружена уязвимость, позволяющая совершить MITM-атаку

Обнаружена уязвимость, позволяющая совершить MITM-атаку

Обнаружена уязвимость, позволяющая совершить MITM-атаку

Опубликована информация об уязвимости под кодовым названием 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-приложения через определённый прокси-сервер, передает opennet.ru.

Предположим, что имеется 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 сентября: Минтранс говорит, что всё готово, бизнесу пора шевелиться

До обязательного перехода на электронные перевозочные документы (ЭПД) остаётся чуть больше двух месяцев, и государство уверяет: технически всё готово. А вот бизнесу ещё предстоит серьёзно перестроить свои процессы. Этот вопрос стал одной из главных тем форума «ЭДО. ЭПД», который прошёл в конце мая в Подмосковье.

Представители Минтранса, ФНС, операторов электронного документооборота и транспортных компаний обсудили, насколько рынок готов к цифровой революции, намеченной на 1 сентября 2026 года.

По данным Минтранса, государственная система ГИС ЭПД работает с 2022 года и уже обработала более 38 миллионов документов. Инфраструктура рассчитана на дальнейший рост нагрузки, а уровень её доступности заявлен на уровне 99,5%.

 

Один из главных страхов перевозчиков — потеря связи в дороге. Власти утверждают, что этот сценарий предусмотрен. Если интернет пропал, перевозчик сможет подтвердить это справкой от оператора связи и подписать документы позже. Кроме того, сейчас прорабатываются механизмы офлайн-подписания документов.

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

 

Участники рынка признают, что многие компании ещё не готовы к полноценному электронному документообороту. Нужно перестраивать внутренние регламенты, обучать сотрудников и подключать контрагентов.

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

Представители операторов ЭДО считают, что откладывать внедрение уже поздно. По их мнению, успех реформы будет зависеть не только от государства и технологий, но и от того, насколько быстро участники рынка смогут договориться между собой и отказаться от привычных бумажных схем.

На фоне подготовки к запуску ЭПД Минтранс также развивает платформу «ГосЛог», систему СПОТ для контроля поставок из стран ЕАЭС и отраслевой центр компетенций по кибербезопасности.

Государство считает, что цифровая инфраструктура уже почти готова. Теперь очередь за бизнесом, которому предстоит научиться жить без бумажек.

RSS: Новости на портале Anti-Malware.ru