HTTPoxy: come la falla di sicurezza mette in pericolo le applicazioni CGI

Innumerevoli progetti web ricorrono per motivi di sicurezza e performance ai server proxy. Questi pratici programmi svolgono la funzione di interfaccia di comunicazione tra client e sito e alleggeriscono il carico del web server, accogliendo, elaborando, inoltrando e rispondendo alle richieste HTTP. Per via di una falla di sicurezza, conosciuta come HTTPoxy, questa tecnica può essere sfruttata indebitamente dagli hacker per rubare i dati personali. Ad essere coinvolte sono le applicazioni che si appoggiano allo standard CGI (Common Gateway Interface) e che portano così con sé le variabili configurabili, chiamate variabili di ambiente. Alcuni programmi possono ricavare dalle variabili coinvolte anche le loro configurazioni proxy e ciò si trasforma velocemente in un problema, se sono i criminali a manipolare queste impostazioni.

Che cos’è l’HTTPoxy?

Quando un web server comunica tramite Common Gateway Interface con il client di un utente, lo standard RFC 3875 prevede che gli header di tutte le richieste HTTP inviate vengano salvati come variabili di ambiente. La denominazione di queste variabili è formata dal prefisso “HTTP_” e dal nome dell’header in lettere maiuscole. Nel caso esposto qui si tratta dell’header “proxy” che genera automaticamente la variabile HTTP_PROXY, che è prevista solitamente per la configurazione delle impostazioni del proxy. Se una richiesta che comprende l’HTTP_PROXY raggiunge quindi l’applicazione CGI o l’applicazione stessa ne esegue una simile, la richiesta viene reindirizzata dal server proxy corrispondente.

Le condizioni riportate consentono ad un hacker di far entrare in azione il suo server proxy e di farlo arrivare in questo modo ad informazioni confidenziali. A questo scopo l’hacker invia una richiesta HTTP con l’header proxy e un valore corrispondente (ad esempio l’indirizzo IP del proxy), di modo che le future richieste degli utenti, in entrata o in uscita, vengano inoltrate a questo server. A seconda dello scenario scelto, il cyber criminale può poi rispondere a piacimento rimandando indietro dei propri dati o carpire con metodi diretti i dati immessi dagli utenti.

Una falla di sicurezza senza fine?

Questa vulnerabilità (il nome scelto non ha nessun significato particolare) è comparsa per la prima volta a marzo 2001, quando il programmatore Randal L. Schwartz scoprì HTTPoxy nella libreria Perl libwww-perl e fece presente la cosa a Gisle Aas, lo sviluppatore della libreria, che risolse immediatamente la falla di sicurezza con l’update 5.5.1, facendo in modo che i nomi delle variabili potessero venir controllate tramite la configurazione proxy, modificata in CGI_HTTP_PROXY.

Nello stesso anno è stata individuata la vulnerabilità anche nel programma di trasferimento dati curl per cui, in seguito, lo sviluppatore Daniel Stenberg ha adeguato il software in tal senso, in modo che questo d’ora in poi protraesse solo la variante scritta in minuscolo http_proxy per la determinazione del server proxy, indicando però, al contempo, che una misura di questo tipo non era sostanzialmente sufficiente per i sistemi Microsoft. Comunque nelle ultime versioni di Windows il problema non dovrebbe più esserci.

A luglio 2012, quasi un decennio dopo, durante l’implementazione della classe NET::HTTP, un’API del client HTTP per le applicazioni Ruby, il team di Ruby si è imbattuto nella questione a lungo dimenticata dell’HTTPoxy. Per superare questo problema, l’HTTP_Proxy ha assunto, tra gli altri, il ruolo di variabile standard. Negli anni successivi, tra i casi noti si sono aggiunte anche le applicazioni del web server NGINX (2013) e Apache (2015), dove gli utenti attenti hanno avvisato gli sviluppatori della potenziale situazione pericolosa.

Nel 2016 il team responsabile per la sicurezza dell’azienda di sviluppatori Vend ha infine stabilito che la falla di sicurezza HTTPoxy, anche dopo 15 anni dalla scoperta, rimane ancora una vulnerabilità presente nel PHP e in altri linguaggi di programmazione, oltre che nelle librerie, nel momento in cui viene utilizzata in combinazione con un’interfaccia CGI o in un ambiente di runtime simile con variabili configurabili. Molte applicazioni coinvolte che permettono lo sfruttamento dell’HTTPoxy sono state elencate nelle specificazioni ufficiali per le falle di sicurezza, chiamate CVEs (Common Vulnerabilities and Exposures):

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
  • CVE-2016-6287: CHICKEN’s http-client
  • CVE-2016-1000104: mod_fcgi
  • CVE-2016-1000105: Nginx cgi script
  • CVE-2016-1000107: Erlang inets
  • CVE-2016-1000108: YAWS
  • CVE-2016-1000109: HHVM FastCGI
  • CVE-2016-1000110: Python CGIHandler
  • CVE-2016-1000111: Python Twisted
  • CVE-2016-1000212: lighttpd

Come proteggere voi e il vostro server dall’HTTPoxy

Indipendentemente dal fatto che gestiate o meno un vostro web server, HTTPoxy rappresenta per voi un rischio, se navigate nel mare magnum del World Wide Web. Il servizio web richiamato può venir reindirizzato tramite richieste HTTP esterne, indesiderate, e di conseguenza anche i vostri dati finiscono in cattive mani. Per ridurre il rischio di una perdita di dati, dovreste perciò preferire pagine che sono protette tramite un certificato TLS/SSL e dove tutte le informazioni sono trasmesse in maniera crittografata. In questo modo è perciò possibile il reindirizzamento dei dati tramite un finto proxy, ma i criminali riescono ad ottenere molte meno informazioni, visto che i dati personali sono protetti, o generalmente non ne ricavano alcun profitto. Per i gestori di una pagina diventa quindi sempre più importante il passaggio all’HTTPS. Ma avete anche sempre l’opzione, in generale, di evitare l’HTTPoxy, semplicemente eliminando la vulnerabilità. Visto che l’header proxy non può essere incorporato nello standard IETF né registrato nello IANA come header ufficiale, potete ancora intercettarlo prima che raggiunga la vostra applicazione web. I client conformi allo standard HTTP e i server non inviano ugualmente da soli nessun pacchetto dati con questo header. Essenzialmente, oltre alla crittografia dello scambio dati HTTP, avete due possibilità per tenere lontane dal vostro sito web queste richieste minacciose:

  1. Filtrate l’header proxy di tutti i pacchetti in entrata.
  2. Bloccate automaticamente tutti i pacchetti in entrata che contengono l’header proxy.

La prima variante è molto più diffusa e si può mettere in atto grazie a tutti i web server comuni, al proxy o al software di load balancing. Nei paragrafi successivi trovate informazioni su come rintracciare nel traffico dati l’header potenzialmente pericoloso grazie alle applicazioni dei web server Apache e NGINX e al software per il server proxy HAProxy, presente su diverse distribuzioni Linux.

Eludere l’HTTPoxy nel server Apache

Il software libero Apache è generalmente installato su tutte le distribuzioni correnti di Linux ed è per molti, fino ad oggi, la prima scelta quando si tratta di gestire un proprio web server. Un componente del programma è il modulo mod_headers, che vi consente di filtrare l’header proxy di tutte le richieste HTTP in entrata. Il procedimento varia leggermente a seconda della distribuzione.

Ubuntu e Debian:

Nella prima parte si deve attivare il modulo, cosa che fate con il seguente comando:

sudo a2enmod headers

Dopodiché aprite il file di configurazione principale di Apache con un editor, tra i quali è molto consigliato nano, il tool della riga di comando utilizzato nell’esempio:

sudo nano /etc/apache2/apache2.conf

Infine aggiungete il seguente codice al file:

<IfModule mod_headers.c>
    RequestHeader unset Proxy early
</IfModule>

Dopo che avete salvato il file, attivate la protezione HTTPoxy, caricando il file di configurazione specificato tramite script a2enconf e poi riavviate il server:

sudo a2enconf httpoxy
sudo service apache2 restart

CentOS e Fedora:

Se utilizzate una versione delle distribuzioni Linux CentOS o Fedora, il modulo mod_headers è solitamente già attivato, perciò potete saltare questo passaggio e aprire subito il file di configurazione:

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

Poi, nel file aggiungete il nuovo codice:

RequestHeader unset Proxy early

Infine, salvate le modifiche ed eseguite un riavvio del server Apache.

sudo service httpd restart

Eliminare l’header proxy HTTP nel server NGINX

Nel frattempo NGINX è entrato a fare parte della cerchia dei maggiori web server e la sua popolarità non fa che crescere di giorno in giorno. Grazie al software open source sono anche necessari solo pochi passaggi per proteggere sufficientemente dalla falla di sicurezza HTTPoxy le applicazioni CGI che sono installate sul server o vengono eseguite tra client e server.

Ubuntu e Debian:

Di solito i parametri FastCGI (FastCGI è un’ottimizzazione dello standard CGI) sono contenuti su Ubuntu e Debian nei file fastcgi_params o fastcgi.conf quando configurate un proxy FastCGI NGINX. In entrambi i file potete eliminare il proxy header nelle richieste HTTP. A questo scopo ricorrete ai seguenti comandi:

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

Non appena utilizzate il proxy HTTP convenzionale, potete filtrare anche l’header. Così inserite la regola corrispondente nel file proxy_params, in cui sono eseguiti i parametri per il server proxy:

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

Nell’ultimo passaggio riavviate NGINX con questo comando:

sudo service nginx restart

CentOS e Fedora:

La procedura per evitare il pericolo dell’HTTPoxy per i proxy FastCGI, che eseguite su CentOS o Fedora, non si distingue dalla procedura necessaria per i sistemi Ubuntu e Debian. Visto che le configurazioni NGINX sono stabilite anche su queste distribuzioni nel file fastcgi_params o in quello fastcgi.conf, attivate l’header proxy anche qui con i comandi già visti sopra:

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

Per proteggere i proxy convenzionali su Fedora e CentOS, dovete assicurarvi che l’header venga bloccato dappertutto, laddove NGINX esegue la direttiva proxy_pass. Per scoprire dove viene utilizzata potete ricorrere ai servizi del comando di ricerca grep:

sudo grep -r "proxy_pass" /etc/nginx

Ottenete così una lista di file di testo nei quali viene eseguita la direttiva e il risultato sarà simile a quello esposto nell’esempio seguente:

/etc/nginx/nginx.conf.default:        #    proxy_pass http://127.0.0.1;

In questo caso proxy_pass sarebbe quindi impostato nel file di configurazione NGINX. Perciò dovreste aggiungere nel file nginx.conf il seguente codice:

proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";

Infine in entrambi i casi è opportuno fare un riavvio del server:

sudo service nginx restart

Come difendersi dall’HTTPoxy con il server HAProxy

Se inoltrate le richieste HTTP al vostro progetto web attraverso un server HAProxy, potete rimuovere l’header proxy ancora prima che il proxy invii le richieste. Questo processo non cambia in base alle diverse distribuzioni di Linux. Prima di tutto bisogna aprire il file di configurazione principale del proxy, cosa che fate con il seguente comando:

sudo nano /etc/haproxy/haproxy.cfg

In questo modo aprite il file haproxy.cfg con nano, l’editor della riga di comando già utilizzato prima. Se avete indicato una cartella alternativa per HAProxy, dovete ovviamente adeguare il comando di conseguenza.

Nel file aperto potete ora aggiungere per le tre sezioni “frontend”, “backend” e “listen” una direttiva di richiesta HTTP, che elimina l’header indesiderato. Il risultato è il seguente:

frontend name
    http-request del-header Proxy
…
backend name
    http-request del-header Proxy
…
listen name
    http-request del-header Proxy

Salvate le modifiche e riavviate il servizio HAProxy:

sudo service haproxy restart

Verificare la sicurezza del proprio server con il tool HTTPOXY Vulnerability Checking

Dopo esservi assicurati di aver configurato il proxy nel modo corretto, scegliendo tra una delle possibilità per proteggersi dall’HTTPoxy, dovreste verificare se vi potete accedere nel modo richiesto. Per fare questo esistono delle applicazioni come il tool HTTPOXY Vulnerability Checking di Luke Rehmann. Questo servizio web, utilizzabile gratuitamente, verifica gli URL per le vulnerabilità HTTPoxy, inviando una richiesta HTTP comprensiva di header proxy agli URL, che viene reindirizzata ad un server alternativo. Se il tool non riceve risposta da questo server, il blocco dell’header è andato a buon fine.

Tool web HTTPoxy Vulnerability Checking Tool
Verifica del sito IONOS.it con HTTPoxy Vulnerability Checking Tool, con esito positivo (fonte: httpoxy.rehmann.co)

Per utilizzare il servizio, dovete semplicemente aggiungere nel campo apposito l’URL dell’applicazione web da verificare e cliccare su “Test”.

Hai trovato questo articolo utile?
Per offrirti una migliore esperienza di navigazione online questo sito web usa dei cookie, propri e di terze parti. Continuando a navigare sul sito acconsenti all’utilizzo dei cookie. Scopri di più sull’uso dei cookie e sulla possibilità di modificarne le impostazioni o negare il consenso.