Czym jest HTTPoxy?
W dniu 18 lipca 2016 roku została ujawniona luka w zabezpieczeniach aplikacji CGI, która ma nazwę HTTPoxy. Osoby atakujące mogą wykorzystać wrażliwe wdrożenia przekazując nagłówek HTTP Proxy z ich żądania, który będzie zmieniał adres URL używany przez aplikację, kontaktując się z działem usług pomocniczych. To może być wykorzystane do wycieku danych logowania, zmiany aplikacji itp.
Luka ta jest spowodowana przez zderzenie między nazwą HTTP_PROXY, zmiennej środowiskowej często używanej do określenia lokalizacji usługi backend proxy, oraz Proxy nagłówka HTTP klienta. To powoduje starcie zmiennych konfiguracyjnych, takich jak HTTP_PROXY, które również zaczynają się HTTP_.
Ponieważ luka ta dotyczy różnych CGI wdrożeń, zostały stworzone przez szereg identyfikatorów luki w zabezpieczeniach: CVE-2016-5386, CVE-2016-5386, CVE-2016-5387, CVE-2016-5388, CVE-2016-1000109, oraz CVE-2016-1000110 (w momencie pisania tego artykułu one są zarezerwowane ale nie wypełnione).
Luka HTTPoxy była znana w niektórych formach od 2001 roku, ale nigdy nie rozpoznana jako powszechny problem aż do niedawna.
Wrażliwe serwery i aplikacje
HTTPoxy jest ogólna luka znaleziona w wielu implementacjach CGI. Aplikacja lub serwer może poprawnie wdrożyć specyfikacji CGI i nadal być zagrożone.
Co powoduje wdrożenie narażenia:
- Użycie zmiennej środowiskowej HTTP_PROXY dla konfiguracji połączenia proxy albo w samej aplikacji lub jakichkolwiek bibliotek, które są wykorzystywane. Jest to dość standardowy sposób konfigurowania serwerów proxy za pomocą środowiska.
- Zwracanie się do usług wewnętrznych za pomocą protokołu HTTP: ponieważ “zderzenie” jest nazwą specyficzną dla HTTP_ prefiksu, tylko polecenia wykonane przez aplikacje za pomocą protokołu HTTP zostaną naruszone. Polecenia z wykorzystaniem protokołu HTTPS lub jakiekolwiek inne protokoły nie są zagrożone.
- Praca w CGI lub CGI środowisku: są narażone drożenia, gdzie klient nagłówki są tłumaczone na odpowiedni HTTP_ prefiksy zmiennych środowiskowych. Każde wdrożenie CGI lub związane protokoły FastCGI będą to robić.
Jak widać, połączenie deployment- i zastosowania poszczególnych czynników są niezbędne dla wdrożenia być zagrożone. Aby sprawdzić, czy wdrożenie ma wpływ, Luke Rehmann stworzył prostą stronę, by sprawdzić publicznie dostępne miejsca dla wrażliwości.
Specyficzny język informacji
Aplikacje PHP w szczególności powinny być sprawdzone, ponieważ CGI wdrożenia są bardziej powszechne w ekosystemie PHP niż w innych językach. Ponadto, powszechne korzystanie z getenv metody w popularnych bibliotekach wzmacnia ten problem, ponieważ nie od razu wiadomo, że to zwróci niesprawdzone dane wejściowe użytkownika, a nie tylko zmienne konfiguracyjne. Konkretne biblioteki, które są obecnie dotknięte to Guzzle (wersja 4.0.0rc2 i wyżej), ARTAX i klasa kompozytora StreamContextBuilder.
Inne języki, które były narażone podczas wdrażania za pomocą CGI były Python i Go. Języki te są powszechnie stosowane przy użyciu innych nie narażonych metod. Jednak, jeśli jest stosowany CGI, wtedy biblioteki które naiwnie czytają HTTP_PROXY, bez zmiany są zagrożone.
Jak pokonać lukę
Na szczęście HTTPoxy jest stosunkowo prosta do naprawienia. Luka może być skierowana z warstwy serwera WWW, aplikacji lub biblioteki:
- Aplikacji lub biblioteki mogą ignorować HTTP_PROXY, gdy są one w środowisku CGI.
- Aplikacji lub biblioteki mogą korzystać z innej zmiennej środowiskowej do konfigurowania połączeń proxy.
- Serwery WWW lub serwery proxy mogą nie ustawiać Proxy w nagłówkach, uzyskanych od klientów.
Jeżeli używasz zagrożonej biblioteki, należy ograniczyć zagrożenie po stronie serwera, dopóki nie będą dostępne poprawki w celu rozwiązania problemu.
Jeżeli biblioteki, aplikacja lub projekt opierają się na HTTP_PROXY, aby skonfigurować backend proxy, należy rozważyć zastosowanie alternatywnych zmiennych, które nie będą kolidować podczas pracy w środowisku CGI. Ruby i kilka innych projektów wykorzystuje CGI_HTTP_PROXY do tego celu.
Ponieważ Proxy nagłówek nie jest standardowym nagłówkiem HTTP, można go zignorować w prawie wszystkich przypadkach. Można to zrobić dla równoważenia obciążenia serwerów WWW lub dla bezpośrednich wniosków do samej aplikacji. Ponieważ Proxy nagłówek HTTP nie ma standardowego uzasadnionego celu, może być prawie zawsze usunięty.
Każdy serwer WWW może równoważyć obciążenia lub proxy serwer może zresetować odpowiednie nagłówki.
Usunięcie nagłówka HTTP proxy z Apache
Jeśli używasz serwera WWW Apache HTTP, moduł mod_headers może być użyty do anulowania nagłówka.
Ubuntu i serwery Debian
Aby włączyć mod_headers na serwerach Ubuntu lub Debian, należy wpisać polecenie:
sudo a2enmod headers
Następnie otwórz plik konfiguracyjny:
sudo nano /etc/apache2/apache2.conf
Na końcu dodać:
. . . RequestHeader unset Proxy early
Zapisz i zamknij plik.
Sprawdź konfigurację pod kątem błędów składni:
sudo apache2ctl configtest
Uruchom ponownie usługę, w przypadku braku błędów:
sudo service apache2 restart
CentOS i serwery Fedora
Moduł mod_headers powinien być domyślnie włączony dla zwykłych urządzeń. Aby anulować Proxy nagłówek, należy otworzyć plik konfiguracyjny:
sudo nano /etc/httpd/conf/httpd.conf
Na końcu dodać:
. . . RequestHeader unset Proxy early
Zapisz i zamknij plik po zakończeniu.
Sprawdź błędy składni, wpisując:
sudo apachectl configtest
Uruchom ponownie usługę, w przypadku braku błędów:
sudo service httpd restart
Usunięcie nagłówka HTTP Proxy z Nginx
W Nginx usunięcie nagłówka jest również banalne. Można łatwo zdezynfekować środowisko dla każdego środowiska CGI, działającym na serwerze.
Ubuntu i serwery Debian
Na serwerach Ubuntu i Debian, parametry FastCGI są zazwyczaj zawarte zarówno w fastcgi_params lub fastcgi.conf pliki podczas konfigurowania serwera proxy FastCGI. Można usunąć HTTP_PROXY nagłówek w obu tych plikach:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
Jeżeli nie pozyskiwałeś jednego z plików podczas konfigurowania proxy serwerów FastCGI, należy włączyć tą linię w miejscu samego proxy:
. . .
location ~ \.php$ {
. . .
fastcgi_param HTTP_PROXY "";
. . .
}
}
Jeśli używasz Nginx dla zwykłego HTTP proxy, należy również wyczyścić HTTP Proxy nagłówek. Nagłówki HTTP proxy są ustawione w /etc/nginx/proxy_params pliku. Możesz dodać regułę dla usunięcia Proxy nagłówka do tego pliku, wpisując:
echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params
Jeżeli nie pozyskiwałeś tego pliku podczas konfigurowania proxy serwerów FastCGI, należy włączyć tą linię w miejscu samego proxy:
. . .
location /application/ {
. . .
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
. . .
}
}
Sprawdź błędy składni, wpisując:
sudo nginx –t
Uruchom ponownie usługę, w przypadku braku błędów:
sudo service nginx restart
CentOS i serwery Fedora
Nginx na CentOS i Fedora wykorzystuje również te same fastcgi_params oraz fastcgi.conf pliki do konfiguracji FastCGI proxy. Aby usunąć HTTP_PROXY nagłówek w obu tych plików, wpisz:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
Jeżeli nie pozyskiwałeś jednego z plików podczas konfigurowania proxy serwerów FastCGI, należy włączyć tą linię w miejscu samego proxy:
. . .
location ~ \.php$ {
. . .
fastcgi_param HTTP_PROXY "";
. . .
}
}
Jeśli używasz Nginx dla zwykłego HTTP proxy, należy również wyczyścić HTTP Proxy nagłówek. Wystarczy dodać regułę, aby usunąć Proxy nagłówek w każdym miejscu, w którym jest wykonywany proxy_pass. Jeśli nie masz pewności, gdzie proxy_pass jest używany, można łatwo wyszukać katalog konfiguracji:
grep -r "proxy_pass" /etc/nginx
/etc/nginx/nginx.conf.default: # proxy_pass http://127.0.0.1;
Wszelkie wyniki, które nie są komentowane (jak powyższym przykładzie) powinny być edytowane zawierać proxy_set_header Proxy “”; :
. . .
location /application/ {
. . .
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
. . .
}
}
Sprawdź błędy składni, wpisując:
sudo nginx –t
Uruchom ponownie usługę, w przypadku braku błędów:
sudo service nginx restart
Usunięcie nagłówka HTTP Proxy z HAProxy
Jeśli używasz HAProxy do kierowania ruchu do serwerów aplikacyjnych, można upuścić Proxy nagłówek przed przekazaniem ruchu.
Otworz plik /etc/haproxy/haproxy.cfg do edycji:
sudo nano /etc/haproxy/haproxy.cfg
Można ustawić http-request dyrektywę w frontend, backend lub listen sekcji konfiguracji.
frontend www
http-request del-header Proxy
. . .
backend web-backend
http-request del-header Proxy
. . .
listen appname 0.0.0.0:80
http-request del-header Proxy
. . .
Te nie musi być ustawione w każdym z odcinków, ale nie zaszkodzi je dołączyć. Zapisz i zamknij plik po zakończeniu.
Sprawdź składnię wpisując:
sudo haproxy -c -f /etc/haproxy/haproxy.cfg
Uruchom ponownie usługę, w przypadku braku błędów:
sudo service haproxy restart
Wniosek
Luka HTTPoxy została otwierana przez dość długi czas i może mieć wpływ na duży zestaw aplikacji wdrożonych w sieci. Na szczęście, to jest łatwo naprawić za pomocą funkcji header-altering która używana na dowolnym serwerze WWW.