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:
- Filtrate l’header proxy di tutti i pacchetti in entrata.
- 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.
Per utilizzare il servizio, dovete semplicemente aggiungere nel campo apposito l’URL dell’applicazione web da verificare e cliccare su “Test”.
Articoli simili
Sicurezza su Internet: siti web sicuri con SSL e HTTPS
Il tema della sicurezza dati diventa sempre più importante, sia nel privato sia nel settore professionale. Come gestori di siti web dovreste prendere tutte le precauzioni necessarie per rendere la visita del vostro sito web il più possibile sicura e garantire la trasmissione di dati senza rischi. La migrazione da HTTP a SSL e HTTPS è il primo passo verso una pagina sicura e per guadagnarvi la…
Cos’è la CGI?
Gli utenti hanno giornalmente a che fare con delle Common Gateway Interface, ad esempio quando compilano un modulo online, quando cliccano sul carrello della spesa o commentano un blog. La tecnologia consente di applicare funzioni dinamiche senza dover impiegare le risorse del server. Come funziona la CGI? Quali sono i vantaggi e gli svantaggi e quali le alternative disponibili per gli…
Log4Shell: le cause e gli effetti della vulnerabilità di Java
Quando alla fine del 2021 è stata rivelata la vulnerabilità Log4Shell, che ha permesso ai criminali informatici di prendere facilmente il controllo di interi sistemi remoti, la notizia ha fatto il giro del mondo. Quasi tutte le grandi aziende e molti dei servizi più utilizzati sono stati colpiti. Scoprite perché la falla di sicurezza Log4Shell è stata così devastante, come funzionano gli exploit e…
