HTTPoxy: come la falla di sicurezza mette in pericolo le ap­pli­ca­zio­ni CGI

In­nu­me­re­vo­li progetti web ricorrono per motivi di sicurezza e per­for­man­ce ai server proxy. Questi pratici programmi svolgono la funzione di in­ter­fac­cia di co­mu­ni­ca­zio­ne tra client e sito e al­leg­ge­ri­sco­no il carico del web server, ac­co­glien­do, ela­bo­ran­do, inol­tran­do e ri­spon­den­do alle richieste HTTP. Per via di una falla di sicurezza, co­no­sciu­ta come HTTPoxy, questa tecnica può essere sfruttata in­de­bi­ta­men­te dagli hacker per rubare i dati personali. Ad essere coinvolte sono le ap­pli­ca­zio­ni che si ap­pog­gia­no allo standard CGI (Common Gateway Interface) e che portano così con sé le variabili con­fi­gu­ra­bi­li, chiamate variabili di ambiente. Alcuni programmi possono ricavare dalle variabili coinvolte anche le loro con­fi­gu­ra­zio­ni proxy e ciò si trasforma ve­lo­ce­men­te in un problema, se sono i criminali a ma­ni­po­la­re queste im­po­sta­zio­ni.

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 de­no­mi­na­zio­ne 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 au­to­ma­ti­ca­men­te la variabile HTTP_PROXY, che è prevista so­li­ta­men­te per la con­fi­gu­ra­zio­ne delle im­po­sta­zio­ni del proxy. Se una richiesta che comprende l’HTTP_PROXY raggiunge quindi l’ap­pli­ca­zio­ne CGI o l’ap­pli­ca­zio­ne stessa ne esegue una simile, la richiesta viene rein­di­riz­za­ta dal server proxy cor­ri­spon­den­te.

Le con­di­zio­ni riportate con­sen­to­no ad un hacker di far entrare in azione il suo server proxy e di farlo arrivare in questo modo ad in­for­ma­zio­ni con­fi­den­zia­li. A questo scopo l’hacker invia una richiesta HTTP con l’header proxy e un valore cor­ri­spon­den­te (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 ri­spon­de­re a pia­ci­men­to ri­man­dan­do indietro dei propri dati o carpire con metodi diretti i dati immessi dagli utenti.

Questa vul­ne­ra­bi­li­tà (il nome scelto non ha nessun si­gni­fi­ca­to par­ti­co­la­re) è comparsa per la prima volta a marzo 2001, quando il pro­gram­ma­to­re Randal L. Schwartz scoprì HTTPoxy nella libreria Perl libwww-perl e fece presente la cosa a Gisle Aas, lo svi­lup­pa­to­re della libreria, che risolse im­me­dia­ta­men­te la falla di sicurezza con l’update 5.5.1, facendo in modo che i nomi delle variabili potessero venir con­trol­la­te tramite la con­fi­gu­ra­zio­ne proxy, mo­di­fi­ca­ta in CGI_HTTP_PROXY.

Nello stesso anno è stata in­di­vi­dua­ta la vul­ne­ra­bi­li­tà anche nel programma di tra­sfe­ri­men­to dati curl per cui, in seguito, lo svi­lup­pa­to­re Daniel Stenberg ha adeguato il software in tal senso, in modo che questo d’ora in poi pro­traes­se solo la variante scritta in minuscolo http_proxy per la de­ter­mi­na­zio­ne del server proxy, indicando però, al contempo, che una misura di questo tipo non era so­stan­zial­men­te suf­fi­cien­te 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’im­ple­men­ta­zio­ne della classe NET::HTTP, un’API del client HTTP per le ap­pli­ca­zio­ni Ruby, il team di Ruby si è imbattuto nella questione a lungo di­men­ti­ca­ta dell’HTTPoxy. Per superare questo problema, l’HTTP_Proxy ha assunto, tra gli altri, il ruolo di variabile standard. Negli anni suc­ces­si­vi, tra i casi noti si sono aggiunte anche le ap­pli­ca­zio­ni del web server NGINX (2013) e Apache (2015), dove gli utenti attenti hanno avvisato gli svi­lup­pa­to­ri della po­ten­zia­le si­tua­zio­ne pe­ri­co­lo­sa.

Nel 2016 il team re­spon­sa­bi­le per la sicurezza dell’azienda di svi­lup­pa­to­ri Vend ha infine stabilito che la falla di sicurezza HTTPoxy, anche dopo 15 anni dalla scoperta, rimane ancora una vul­ne­ra­bi­li­tà presente nel PHP e in altri linguaggi di pro­gram­ma­zio­ne, oltre che nelle librerie, nel momento in cui viene uti­liz­za­ta in com­bi­na­zio­ne con un’in­ter­fac­cia CGI o in un ambiente di runtime simile con variabili con­fi­gu­ra­bi­li. Molte ap­pli­ca­zio­ni coinvolte che per­met­to­no lo sfrut­ta­men­to dell’HTTPoxy sono state elencate nelle spe­ci­fi­ca­zio­ni ufficiali per le falle di sicurezza, chiamate CVEs (Common Vul­ne­ra­bi­li­ties 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 CGI­Hand­ler
• CVE-2016-1000111: Python Twisted
• CVE-2016-1000212: lighttpd

In­di­pen­den­te­men­te dal fatto che gestiate o meno un vostro web server, HTTPoxy rap­pre­sen­ta per voi un rischio, se navigate nel mare magnum del World Wide Web. Il servizio web ri­chia­ma­to può venir rein­di­riz­za­to tramite richieste HTTP esterne, in­de­si­de­ra­te, e di con­se­guen­za 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 cer­ti­fi­ca­to TLS/SSL e dove tutte le in­for­ma­zio­ni sono trasmesse in maniera crit­to­gra­fa­ta. In questo modo è perciò possibile il rein­di­riz­za­men­to dei dati tramite un finto proxy, ma i criminali riescono ad ottenere molte meno in­for­ma­zio­ni, visto che i dati personali sono protetti, o ge­ne­ral­men­te non ne ricavano alcun profitto. Per i gestori di una pagina diventa quindi sempre più im­por­tan­te il passaggio all’HTTPS. Ma avete anche sempre l’opzione, in generale, di evitare l’HTTPoxy, sem­pli­ce­men­te eli­mi­nan­do la vul­ne­ra­bi­li­tà. Visto che l’header proxy non può essere in­cor­po­ra­to nello standard IETF né re­gi­stra­to nello IANA come header ufficiale, potete ancora in­ter­cet­tar­lo prima che raggiunga la vostra ap­pli­ca­zio­ne web. I client conformi allo standard HTTP e i server non inviano ugual­men­te da soli nessun pacchetto dati con questo header. Es­sen­zial­men­te, oltre alla crit­to­gra­fia dello scambio dati HTTP, avete due pos­si­bi­li­tà per tenere lontane dal vostro sito web queste richieste mi­nac­cio­se:

1. Filtrate l’header proxy di tutti i pacchetti in entrata.
2. Bloccate au­to­ma­ti­ca­men­te tutti i pacchetti in entrata che con­ten­go­no 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 suc­ces­si­vi trovate in­for­ma­zio­ni su come rin­trac­cia­re nel traffico dati l’header po­ten­zial­men­te pe­ri­co­lo­so grazie alle ap­pli­ca­zio­ni dei web server Apache e NGINX e al software per il server proxy HAProxy, presente su diverse di­stri­bu­zio­ni Linux.

Eludere l’HTTPoxy nel server Apache

Il software libero Apache è ge­ne­ral­men­te in­stal­la­to su tutte le di­stri­bu­zio­ni correnti di Linux ed è per molti, fino ad oggi, la prima scelta quando si tratta di gestire un proprio web server. Un com­po­nen­te del programma è il modulo mod_headers, che vi consente di filtrare l’header proxy di tutte le richieste HTTP in entrata. Il pro­ce­di­men­to varia leg­ger­men­te a seconda della di­stri­bu­zio­ne.

Ubuntu e Debian:

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

Dopodiché aprite il file di con­fi­gu­ra­zio­ne prin­ci­pa­le di Apache con un editor, tra i quali è molto con­si­glia­to nano, il tool della riga di comando uti­liz­za­to nell’esempio:

Infine ag­giun­ge­te il seguente codice al file:

Dopo che avete salvato il file, attivate la pro­te­zio­ne HTTPoxy, caricando il file di con­fi­gu­ra­zio­ne spe­ci­fi­ca­to tramite script a2enconf e poi riavviate il server:

CentOS e Fedora:

Se uti­liz­za­te una versione delle di­stri­bu­zio­ni Linux CentOS o Fedora, il modulo mod_headers è so­li­ta­men­te già attivato, perciò potete saltare questo passaggio e aprire subito il file di con­fi­gu­ra­zio­ne:

Poi, nel file ag­giun­ge­te il nuovo codice:

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

Eliminare l’header proxy HTTP nel server NGINX

Nel frattempo NGINX è entrato a fare parte della cerchia dei maggiori web server e la sua po­po­la­ri­tà non fa che crescere di giorno in giorno. Grazie al software open source sono anche necessari solo pochi passaggi per pro­teg­ge­re suf­fi­cien­te­men­te dalla falla di sicurezza HTTPoxy le ap­pli­ca­zio­ni CGI che sono in­stal­la­te sul server o vengono eseguite tra client e server.

Ubuntu e Debian:

Di solito i parametri FastCGI (FastCGI è un’ot­ti­miz­za­zio­ne dello standard CGI) sono contenuti su Ubuntu e Debian nei file fastcgi_params o fastcgi.conf quando con­fi­gu­ra­te un proxy FastCGI NGINX. In entrambi i file potete eliminare il proxy header nelle richieste HTTP. A questo scopo ricorrete ai seguenti comandi:

Non appena uti­liz­za­te il proxy HTTP con­ven­zio­na­le, potete filtrare anche l’header. Così inserite la regola cor­ri­spon­den­te 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 ne­ces­sa­ria per i sistemi Ubuntu e Debian. Visto che le con­fi­gu­ra­zio­ni NGINX sono stabilite anche su queste di­stri­bu­zio­ni nel file fastcgi_params o in quello fastcgi.conf, attivate l’header proxy anche qui con i comandi già visti sopra:

Per pro­teg­ge­re i proxy con­ven­zio­na­li su Fedora e CentOS, dovete as­si­cu­rar­vi che l’header venga bloccato dap­per­tut­to, laddove NGINX esegue la direttiva proxy_pass. Per scoprire dove viene uti­liz­za­ta potete ricorrere ai servizi del comando di ricerca grep:

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:

In questo caso proxy_pass sarebbe quindi impostato nel file di con­fi­gu­ra­zio­ne NGINX. Perciò dovreste ag­giun­ge­re nel file nginx.conf il seguente codice:

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

Come di­fen­der­si dall’HTTPoxy con il server HAProxy

Se inoltrate le richieste HTTP al vostro progetto web at­tra­ver­so un server HAProxy, potete rimuovere l’header proxy ancora prima che il proxy invii le richieste. Questo processo non cambia in base alle diverse di­stri­bu­zio­ni di Linux. Prima di tutto bisogna aprire il file di con­fi­gu­ra­zio­ne prin­ci­pa­le del proxy, cosa che fate con il seguente comando:

In questo modo aprite il file haproxy.cfg con nano, l’editor della riga di comando già uti­liz­za­to prima. Se avete indicato una cartella al­ter­na­ti­va per HAProxy, dovete ov­via­men­te adeguare il comando di con­se­guen­za.

Nel file aperto potete ora ag­giun­ge­re per le tre sezioni “frontend”, “backend” e “listen” una direttiva di richiesta HTTP, che elimina l’header in­de­si­de­ra­to. Il risultato è il seguente:

Salvate le modifiche e riavviate il servizio HAProxy:

Per uti­liz­za­re il servizio, dovete sem­pli­ce­men­te ag­giun­ge­re nel campo apposito l’URL dell’ap­pli­ca­zio­ne web da ve­ri­fi­ca­re e cliccare su “Test”.