Как защитить ваш сервер от уязвимости HTTPoxy

Что такое HTTPoxy?

18 июля 2016 года была обнаружена уязвимость приложения CGI, называемая HTTPoxy. Злоумышленник может использовать уязвимые развертывания, передавая заголовок HTTP + Proxy + со своим запросом, который изменит URL-адрес, используемый приложением при обращении к вспомогательным службам. Это может быть использовано для утечки учетных данных, изменения ответов на приложение и т. Д.

Уязвимость вызвана конфликтом имен между переменной окружения + HTTP_PROXY +, часто используемой для указания местоположения серверной прокси-службы, и HTTP-заголовком клиента + Proxy +. Https://tools.ietf.org/html/rfc3875#section-4.1.18[CGI спецификация] вызывает передачу предоставляемых клиентом заголовков в среду с префиксом + HTTP_ + для пространства имен. Это искажение конфликтует с переменными конфигурации, такими как + HTTP_PROXY +, которые также начинаются с + HTTP_ +. Если приложение CGI или библиотека используют эту переменную без дополнительной обработки, она может в конечном итоге использовать значение, предоставленное клиентом при попытке подключения к прокси-службе.

Поскольку эта уязвимость влияет на различные CGI-подобные реализации, был создан ряд идентификаторов уязвимостей безопасности: CVE- 2016-5386, CVE-2016-5386, http: //www.cve.mitre. org / cgi-bin / cvename.cgi? name = CVE-2016-5387 [CVE-2016-5387], http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016 -5388 [CVE-2016-5388], CVE-2016-1000109 и http: // www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000110[CVE-2016-1000110] (На момент написания статьи они зарезервированы, но не заполнены).

Уязвимость HTTPoxy известна в некоторых формах с 2001 года, но до недавнего времени никогда не признавалась широко распространенной проблемой. Хотя это может повлиять на многие развертывания, смягчение последствий является довольно простым и понятным.

Уязвимые серверы и приложения

HTTPoxy - это общая уязвимость, обнаруживаемая многими реализациями CGI. Приложение или сервер могут правильно реализовать спецификацию CGI и при этом оставаться уязвимыми.

Чтобы развертывание было уязвимым, оно должно:

  • * Используйте переменную окружения + HTTP_PROXY + для настройки прокси-соединений *: либо в самом коде приложения, либо в любых библиотеках, которые используются. Это довольно стандартный метод настройки прокси-серверов с использованием среды.

  • * Делать запросы к внутренним службам, используя HTTP *: поскольку конфликт имен связан с префиксом + HTTP_ +, будут затронуты только запросы, сделанные приложением, использующим HTTP. Запросы с использованием HTTPS или любых других протоколов не являются уязвимыми.

  • * Работа в CGI или CGI-подобной среде. * Развертывания, в которых заголовки клиентов переводятся в переменные среды с префиксом «+ HTTP_ +», уязвимы. Любая совместимая реализация CGI или связанных протоколов, таких как FastCGI, сделает это.

Как видите, комбинация факторов, связанных с развертыванием и приложением, необходима для уязвимости развертывания. Чтобы проверить, влияет ли ваше развертывание, Luke Rehmann создал простой site для проверки общедоступных сайтов на уязвимость.

Информация о языке

В частности, PHP-приложения должны подвергаться аудиту, поскольку CGI-подобные развертывания гораздо более распространены в экосистеме PHP, чем в других языках. Кроме того, широкое использование метода + getenv + в популярных библиотеках усугубляет эту проблему, так как не сразу ясно, что это будет возвращать неанизированный пользовательский ввод, а не только переменные конфигурации. Конкретные библиотеки, которые в настоящее время подвержены уязвимости, это Guzzle (версия 4.0.0rc2 и выше), Artax и класс StreamContextBuilder Composer.

Другими языками, которые были признаны уязвимыми при развертывании с использованием CGI, были Python и Go. Эти языки чаще развертываются с использованием других, не уязвимых методов. Однако, если используется CGI, библиотеки, которые наивно читают переменную + HTTP_PROXY + без изменения своего поведения, уязвимы.

Как победить уязвимость

К счастью, HTTPoxy относительно просто исправить. Уязвимость может быть устранена на уровне веб-сервера или в приложении или библиотеке:

  • Приложения или библиотеки могут игнорировать переменную + HTTP_PROXY +, когда они находятся в среде CGI.

  • Приложения или библиотеки могут использовать другую переменную среды для настройки прокси-соединений

  • Веб-серверы или прокси могут отменить заголовок + Proxy +, полученный в клиентских запросах

Если вы используете уязвимую библиотеку, вы должны смягчать угрозу на стороне сервера, пока не появятся исправления для устранения проблемы. Если вы являетесь автором библиотеки или приложения и ваш проект использует переменную + HTTP_PROXY + для настройки прокси-сервера, рассмотрите возможность использования альтернативной переменной, которая не будет конфликтовать при работе в среде, подобной CGI. Ruby и некоторые другие проекты используют + CGI_HTTP_PROXY + для этой цели.

Поскольку заголовок + Proxy + не является стандартным заголовком HTTP, его можно безопасно игнорировать почти во всех случаях. Это можно сделать на веб-сервере или в балансировщике нагрузки, используемом для направления запросов к самому приложению. Поскольку HTTP-заголовок + Proxy + не имеет какой-либо стандартной законной цели, его почти всегда можно отбросить.

Любой распространенный веб-сервер, балансировщик нагрузки или прокси-сервер могут сбрасывать соответствующие заголовки.

Удаление HTTP-заголовка прокси с помощью Apache

Если вы используете веб-сервер Apache HTTP, модуль + mod_headers + может использоваться для сброса заголовка для всех запросов.

Серверы Ubuntu и Debian

Чтобы включить + mod_headers + на серверах Ubuntu или Debian, введите:

sudo a2enmod headers

После этого откройте файл глобальной конфигурации:

sudo nano /etc/apache2/apache2.conf

Внизу добавьте:

файл /etc/apache2/apache2.conf

. . .
RequestHeader unset Proxy early

Сохраните и закройте файл.

Проверьте конфигурацию на наличие синтаксических ошибок:

sudo apache2ctl configtest

Перезапустите службу, если нет сообщений о синтаксических ошибках:

sudo service apache2 restart

Серверы CentOS и Fedora

Модуль + mod_headers + должен быть включен по умолчанию для обычных установок. Чтобы удалить заголовок + Proxy +, откройте файл глобальной конфигурации:

sudo nano /etc/httpd/conf/httpd.conf

Внизу добавьте:

/etc/httpd/conf/httpd.conf

. . .
RequestHeader unset Proxy early

Сохраните и закройте файл, когда вы закончите.

Проверьте наличие синтаксических ошибок, набрав:

sudo apachectl configtest

Если нет сообщений о синтаксических ошибках, перезапустите службу, набрав:

sudo service httpd restart

Удаление заголовка прокси HTTP с помощью Nginx

В Nginx смягчение аналогично тривиально. Вы можете легко дезинфицировать среду для любой CGI-подобной среды, работающей на сервере или выше по потоку.

Серверы Ubuntu и Debian

На серверах Ubuntu и Debian параметры FastCGI обычно включаются из файлов + fastcgi_params + или + fastcgi.conf + при настройке прокси-сервера FastCGI. Вы можете удалить заголовок + HTTP_PROXY + в обоих этих файлах:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

Если вы не используете один из файлов при настройке прокси-серверов FastCGI, обязательно включите эту же строку в расположение прокси-сервера:

/etc/nginx/sites-enabled/some_site.conf

. . .
   location ~ \.php$ {
       . . .

       . . .
   }
}

Если вы используете Nginx для обычного HTTP-прокси, вы должны также очистить заголовок HTTP + Proxy +. Заголовки HTTP-прокси устанавливаются в файле + / etc / nginx / proxy_params +. Вы можете добавить правило, чтобы удалить заголовок + Proxy + для этого файла, набрав:

echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params

Опять же, если вы не используете этот файл из конфигурации блока вашего сервера, вам придется добавить его в расположение прокси-сервера:

/etc/nginx/sites-enabled/some_site.conf

. . .
   location /application/ {
       . . .
       proxy_pass http://127.0.0.1;

       . . .
   }
}

Проверьте наличие синтаксических ошибок, набрав:

sudo nginx -t

Если об ошибках не сообщается, перезапустите службу:

sudo service nginx restart

Серверы CentOS и Fedora

Nginx в CentOS и Fedora также использует те же файлы + fastcgi_params + и + fastcgi.conf + для настройки прокси FastCGI. Удалите заголовок + HTTP_PROXY + в обоих этих файлах, набрав:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

Если вы не используете один из этих файлов при настройке прокси-серверов FastCGI, обязательно добавьте эту же строку в само расположение прокси:

/etc/nginx/nginx.conf

. . .
   location ~ \.php$ {
       . . .

       . . .
   }
}

Если вы используете Nginx для обычного HTTP-прокси, вы должны также очистить заголовок HTTP + Proxy +. Вам просто нужно добавить правило для отмены заголовка + Proxy в любом месте, где вы выполняете` + proxy_pass`. Если вы не уверены, где используется + proxy_pass +, вы можете легко найти каталог вашей конфигурации:

grep -r "proxy_pass" /etc/nginx
Output/etc/nginx/nginx.conf.default:        #    proxy_pass   http://127.0.0.1;

Любые результаты, которые не закомментированы (как в примере выше), должны быть отредактированы так, чтобы они включали + proxy_set_header Proxy" "; +:

/etc/nginx/nginx.conf

. . .
   location /application/ {
       . . .
       proxy_pass http://127.0.0.1;

       . . .
   }
}

Проверьте наличие синтаксических ошибок, набрав:

sudo nginx -t

Если об ошибках не сообщается, перезапустите службу:

sudo service nginx restart

Удаление заголовка прокси HTTP с помощью HAProxy

Если вы используете HAProxy для направления трафика на серверы приложений, вы можете удалить заголовок + Proxy + перед пересылкой трафика.

Откройте файл + / etc / haproxy / haproxy.cfg + для редактирования:

sudo nano /etc/haproxy/haproxy.cfg

Вы можете установить директиву + http-request + в разделах + frontend +, + backend + или + listen + вашей конфигурации.

/etc/haproxy/haproxy.cfg

frontend www

   . . .

backend web-backend

   . . .

listen appname 0.0.0.0:80

   . . .

Их не нужно устанавливать в каждом из разделов, но не мешало бы их включить. Сохраните и закройте файл, когда вы закончите.

Проверьте синтаксис, набрав:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Если проблем не обнаружено, перезапустите службу, набрав:

sudo service haproxy restart

Заключение

Уязвимость HTTPoxy давно не используется и может затронуть большой набор приложений, развернутых в Интернете. К счастью, это легко исправить, используя возможности изменения заголовка, свойственные любому веб-серверу.

Related