Applicaties in PHP, Go en Python zijn kwetsbaar via cgi door 'httpoxy'-lek

Onderzoeker Dominic Scheirlinck heeft de details bekendgemaakt van de 'httpoxy'-kwetsbaarheden, waarmee een aanvaller kan bepalen waar verzoeken van een webapplicatie naartoe worden gestuurd. Het gaat om een oud lek, dat gevolgen heeft voor PHP, Go, Python en andere talen.

Op een site legt Scheirlinck de kwetsbaarheden en de mogelijke oplossingen uit. Het komt erop neer dat een aanvaller door middel van een request header kan bepalen waar een webapplicatie verzoeken naartoe stuurt. Dit is mogelijk doordat de aanvaller gebruikmaakt van een proxy-header, die door cgi wordt geïnterpreteerd als een variabele. Deze variabele, genaamd 'HTTP_PROXY', wordt echter ook gebruikt om een proxy voor uitgaande verbindingen te configureren. De aanvaller kan dit benamingsconflict gebruiken om zelf een proxy te bepalen.

Daardoor is het bijvoorbeeld mogelijk dat hij daarbij gebruikmaakt van een kwaadaardige proxy en op deze manier een man-in-the-middle-aanval kan uitvoeren en gegevens kan onderscheppen. Volgens de onderzoeker is het lek al vrij oud, het werd in 2001 al ontdekt dat de libwww-perl-module de proxy-header verkeerd interpreteerde. Later bleken ook Ruby, Nginx en curl vatbaar te zijn. Nu blijkt het lek ook in Go, Python en PHP te zitten. Scheirlinck meldt op de site dat het ook mogelijk is dat andere talen getroffen zijn.

Om kwetsbaar te zijn is vereist dat code in een cgi-omgeving wordt uitgevoerd en dat HTTP_PROXY als variabele wordt gezien. Daarnaast moet een http-client deze proxy vertrouwen en als zodanig configureren, Die client moet vervolgens een http verzoek in plaats van een https-verzoek uitvoeren. Het advies van de onderzoeker is dan ook om in eerste instantie inkomende proxy-verzoeken zo vroeg mogelijk te blokkeren, voordat zij een applicatie bereiken. Er zijn advisories uitgebracht door Apache, Nginx, Red Hat, Drupal, US CERT, CloudFlare en Akamai.

Reacties (65)

In PHP is dus voornamelijk Guzzle 4+ (dus 3 niet) en Artax vatbaar, maar hier maken veel andere libraries gebruik van (voornamelijk Guzzle 6 wordt veel gebruikt, oa. ook door Drupal 8 ).

Een beperking van deze kwetsbaarheid is dat deze niet werkt op HTTPS verbindingen. Dit is hopelijk bij veel API's het geval als het gaat om betaal gateways, cloud storage (Flysystem, AWS/Dropbox etc) or OAuth (Facebook/LinkedIn ed.). Maar voornamelijk interne API's, die als vertrouwd worden gezien, kunnen hier wel last van hebben. Het is dus mogelijk om verkeer af te luisteren (API keys, wachtwoorden als deze verzonden worden) of bijv. extra HTML/Javascript te plaatsen, als er widgets/code wordt opgehaald.

And, of course, another defense-in-depth strategy that works is to use HTTPS for internal requests, not just for securing your site’s connections to the outside world. Those aren’t affected by HTTP_PROXY.

Maar wel verstandig om snel up te daten, zeker als je niet zeker weet of je software up to date is of je puur HTTPS gebruikt overal!

[Reactie gewijzigd door Barryvdh op 19 juli 2016 09:23]

Niet echt een spraakmakend lek. De combinatie van CGI, gebruik van HTTP_PROXY, een vertrouwde proxy en geen ssl komt weinig voor in de praktijk.

Je hoeft dus geen vertrouwde proxy te gebruiken. Met deze aanval kan je een HTTP Client (bijv. Guzzle) forceren om een HTTP proxy te gebruiken, die je zelf op geeft.

1. Code running under a CGI-like context, where HTTP_PROXY becomes a real or emulated environment variable
2. An HTTP client that trusts HTTP_PROXY, and configures it as the proxy
3. That client, used within a request handler, making an HTTP (as opposed to HTTPS) request

1 = standaard bij Apache/Nginx
2 = Bijvoorbeeld Guzzle (4+), de populairse PHP HTTP client met 14 miljoen installs: https://packagist.org/packages/guzzlehttp/guzzle
3 = Kan bij interne requests nog wel eens voorkomen.

[Reactie gewijzigd door Barryvdh op 19 juli 2016 13:39]

Het gaat echter niet alleen om Guzzle, (guzzle is slechts een known voorbeeld waarbij dit optreed)
zoals de geschiedenis laat zien van de 'bug' is deze er al lang en komt deze door dat mensen onterecht vertrouwen op client-supplied data.

Volgens de CGI specs word de 'Proxy' header netjes een Environment variables (je zou het een protocol fout kunnen noemen). Een CGi applicatie mag dus nooit zomaar deze waarde vertrouwen (enkel binnen een gecontroleerde omgeving waar deze buwust word doorgegeven voor client specifieke doeleinde, waarbij de enviromnetal variable CGI_HTTP_PROXY een veel beter keus is)

Deze fout komt overigins op ieder platform voor en ook bij andere clients dan apache/nginx zoals lightdm. en andere.

Ik denk dat jij je miskijkt op de term 'CGI', dat is niet perse iets van heel vroeger waarmee je perl scripts of binaries kon aanroepen vanuit apache. Het is ook een van de meest populaire manieren op php op te zetten voor bijvoorbeeld nginx of apache.

En veel software gebruikt (interne) REST api's waarbij calls naar die API's dus nu naar de proxy gestuurd worden in plaats van rechtstreek naar de bedoelde (waarschijnlijk interne) API. En intern verkeer word lang niet altijd geencrypt. Gelukkig is het betalingsverkeer (en de API calls die daar gedaan worden) meestal wel voorzien van https.

Dit is een typische setup die je op talloze websites tegen kan komen en die zullen allemaal moeten checken of ze hier vatbaar voor zijn.

Nee hoor, PHP draait onder apache doorsnee als mod_PHP of SU_PHP.
PHP via CGI wordt al jaren afgeraden.

Maar mod_php (en php-fpm) is dus wel vatbaar iig: https://httpoxy.org/#affected-summary

Hmm dat is wel minder, want dat is de default configuratie.

[code]Another example is in Composer’s StreamContextBuilder utility class[/code]

auwtsj.............

[Reactie gewijzigd door hackerhater op 19 juli 2016 09:45]

Maar Composer is dan juist normaal gesproken alleen benaderbaar vanaf de CLI, en daar is hij niet vatbaar.
Als hij echter via het web benaderbaar is, moet je idd wel updaten naar Composer 1.2.0

Ik gebruik composer niet via het web, maar er zijn ongetwijfelt mensen die het doen.

Wat zou de use-case kunnen zijn om dit te doen?

No idea, maar het is technisch mogelijk dus het zal ongetwijfelt door mensen gebruikt worden.

Ehm, PHP-FPM (FastCGI Process Manager) is de enige oplossing als je nginx gebruikt, en ook voor apache word het vaak aangeraden om PHP-FPM te gebruiken, wat zelfs verplicht is op het moment dat je niet de prefork MPM wil gebruiken vanwege performance.

En daarnaast is mod_php ook vatbaar.

Als mensen CGI zeggen zonder verdere toepassingen wordt normaal de oude manier bedoeld en die wordt al jaren afgeraden.

Barryvdh corrigeerde me al dat mod_php getroffen is.
Zucht dit wordt tientallen servers aanpassen. Alsof ik niet al genoeg te doen had

Ik ben gelukkig er al klaar mee, als je nu een proxy header naar tweakers.net stuurt krijg je een mooie foutlmelding

yum install yum-cron
of
apt-get install unattended-upgrade

Even zomaar servers upgraden? Ben je wel helemaal lekker?
Ken je de uitdrukking "downtime" is not an option?

Dan moet je je platform beter inrichten. 1 server uit je cluster halen, bijwerken, testen en terug. Herhaal voor alle webservers in cluster.

We werken niet allemaal voor grote partijen die server-clusters hebben.
Ik heb een hot-standby, thats it.

Ik ook niet, en we hebben ook geen groot cluster. Dat wil niet zeggen dat je het niet goed kunt inrichten.

Daarnaast is deze fix een kwestie van een service reload dus zero-downtime.

Ik reageerde op svennd met zijn commando voor automatische updates
Deze fix vereist inderdaad alleen een herstart van Apache.

ken je de uitdrukking, je bent een idioot en niet capabel als je zomaar commands uitvoerd op een productie systeem die een andere willekeurige tweaker onder een artikel plaatst.

Als beheerder van die systemen wordt er van je verwacht dat je weet waar je mee bezig bent. niet dat je zomaar code gaat uitvoeren en wel ziet wat er gebeurt.

[Reactie gewijzigd door Proxx op 19 juli 2016 10:15]

Dat doe ik sowieso niet, ik herken de commando's maar al te goed.

yum install yum-cron => Installeer yum-cron op RPM-based systeem
apt-get install unattended-upgrade => upgrade een debian-based systeem naar een nieuwe versie.

Eigenlijk niet, yum-cron is een updater die iedere nacht loopt, op Centos7 gaat hij default zelfs niks doen behalve kijken of er update zijn, afhankelijk van hoe je het configureert kan je updates/security patches afhalen...

Unattented-upgrades is de tegenhanger voor debian based systemen, hoe goed je die kan instellen weet ik niet, maar het is absoluut niet een "apt-get dist-upgrade" die jij refereerde.

Evengoed. automatisch patchen van servers is zeer af te raden.
Dat is de manier om je server onderuit te trekken.

Niet echt... De OS libraries zijn normaliter prima automatisch te upgraden. Alleen libs die je voor evt applicaties gebruikt zet je even in de exclude voor t geval dat of als je die applicatie zelf niet goed up to date houdt (hopelijk met een reden...). Het is onzin om alles geheel handmatig te doen en t gehele auto-update proces uit te schakelen. 99.9% van OS updates zullen nooit problemen geven. Je moet alleen onderscheid maken tussen de essentiele OS updates en de updates aan je (web)applicaties.

Dan nog zal ik hem niet automatisch laten updaten. Ik wil zien wat ie wilt bijwerken. 9 van de 10 keer laat ik hem gewoon lopen, maar ik wil het als beheerder eerst zien.

Stel je hebt nog een legancy site die vervangen wordt en je mist de update van bijvoorbeeld PHP 5.6 naar 5.7. Boem daar ging die site.

[Reactie gewijzigd door hackerhater op 19 juli 2016 13:02]

Tenzij je een goede testset hebt, haal uit cluster, update, test, test ok, dan pas weer terug in cluster. Blijft ie 5 minuten normaal? Volgende. Gaat het instalbiel worden tijdens dat je nog bezig bent met dit proces. Revert.

Moet je wel clusters tot je beschikking hebben. Dat heb ik simpelweg niet.
Geen ideale situatie maar het is niet anders.

Stap je over op AWS?
Wellicht goedkoper

no use => privacy wetgeving. Data mag gegarandeerd niet europa verlaten
Evengoed, leuk die tools maar ik ben een programmeur die het beheer er bij doet. Ik ben geen full blown beheerder.

AWS heeft gewoon ook twee data centra in Duitsland en met je cloudformation template (infra definitie bestand) kun je gewoon aangeven dat de data alleen daar mag staan.

Je kunt ook voor Ierland kiezen.

[Reactie gewijzigd door djwice op 21 juli 2016 18:55]

Even goed ga ik er niet over en kan ik dat niet zomaar doorvoeren.

hoe goed je die kan instellen weet ik niet,

Via de file /etc/apt/apt.conf.d/50unattended-upgrades kan je een groot aantal dingen instellen, zoals de repositories die gebruikt mogen worden om automatisch packages van te downloaden en te installeren (standaard alleen -security) en of er een automatische reboot mag plaatsvinden mocht dat nodig zijn.

Ik heb persoonlijk nooit met yum-cron gewerkt want ik zit altijd op Debian gebaseerde distro's, maar ik ga er stiekem vanuit dat de configuratiemogelijkheden vergelijkbaar zijn.

Zeer waarschijnlijk.
Heel handig voor mams en paps zodat ze er geen omkijken naar hebben
Echter een grote no-no voor servers.

Automatiseer je test werk!

Je gaat toch niet handmatig iets doen op servers?

Puppet, Ansible, kies maar wat om je werk goed te doen.

[Reactie gewijzigd door djwice op 19 juli 2016 21:31]

Ik heb gelukt dat ik alles met Ansible heb ingericht.

Dat soort tools kosten even tijd, maar in dit soort situaties. EPIC.

Heb je geen SaltStack of Puppet ofzo in gebruik?

Nope helaas en sowieso ken ik die tools niet inhoudelijk.
Gezien de servers flink afwijken van elkaar is het ook lastig om de boel te automatiseren.

Het gebruik van bv Guzzle is gevaarlijk. Ik ga iig patchen aangezien wij Guzzle voor nogal wat diensten gebruiken.

[Reactie gewijzigd door LarBor op 19 juli 2016 10:06]

https://github.com/guzzle...49ca5bdd8e0ba38b7006a1eR5

Is al gepatched in 6.2.1

Cheers!

Ik zie die anders met grote regelmaat bij

• Ruby on rails
• Go-lang Applicaties
• Python Applicaties
• Perl Applicaties
• Nginx met PHP
• LightDM met php
• Apache met php-fpm

Overigens is je aaname dat apache met mod_php veilig is niet waar zoals @Barryvdh al zei.

[Reactie gewijzigd door Sysosmaster op 19 juli 2016 12:20]

Deze variabele, genaamd 'HTTP_PROXY', wordt echter ook gebruikt om een proxy voor uitgaande verbindingen te configureren. De aanvaller kan dit benamingsconflict gebruiken om zelf een proxy te bepalen.

Dus een simpele security fix voor webservers in de toekomst: strip standaard een ingestelde HTTP_PROXY header van binnenkomende verzoeken voordat deze worden doorgestuurd naar backend servers, zodat de software in de standaardconfiguratie veilig is. Misschien met een override mogelijkheid voor obscure gevallen waar dit daadwerkelijk als functie gebruikt wordt.

[Reactie gewijzigd door The Zep Man op 19 juli 2016 09:27]

Dat is ook wat ze aanraden als oplossing
https://httpoxy.org/#fix-now

The best immediate mitigation is to block Proxy request headers as early as possible, and before they hit your application. This is easy and safe.

Dat is ook wat ze aanraden als oplossing
https://httpoxy.org/#fix-now

Klopt, maar dat is advies naar beheerders, niet naar de ontwikkelaars achter de webserver software. M.a.w.: beheerders moeten handmatig een actie uitvoeren, op bestaande en op toekomstige systemen. Handmatige acties om de beveiliging naar een minimaal acceptabel niveau te tillen zijn onacceptabel doordat het de deur wagenwijd openzet voor configuratiefouten. Daarom mijn reactie: dit moet standaard gedrag van webservers zijn.

Volgens mij is dat iig wel de reactie van Apache toch?
https://www.apache.org/security/asf-httpoxy-response.txt

The bundled httpd modules all rely on ap_add_common_vars() to set up the
target CGI environment. The project will include the recommended patch
below in all subsequent releases of httpd, including 2.4.24 and 2.2.32.

Volgens mij is dat iig wel de reactie van Apache toch?

Yup. En waarschijnlijk gaan de andere webserver softwarepakketten het ook implementeren.

Vervelende bij dit lek is dat het geen zin heeft om binnen de applicatie deze headers te strippen, want blijkbaar wordt dit alsnog overruled en gebruikt de achterliggende HTTP library alsnog de meegegeven proxyserver. Daarom is op korte termijn de fix dat deze header al meteen bij het binnenkomende request gestript wordt.

Wellicht alleen een whitelist aan headers door laten? Als het goed is weet je welke headers je apllicsties nodig hebben. De rest kan er af.

Scheelt ook nog een beetje op je interne traffic. Dus weer wat meer ruimte voor data die er wel toe doet.

Dit probleem bestaat al 15 jaar dus waarom er nu opeens haast bij is…

Om dat er nu exploits gaan komen na zo'n security announcement
of vind jij het niet belangrijk dat je veilige software draait gevrijwaard van alle bekende data-lekken.

Dit artikel heeft wel een aantal taalfouten, in de titel poxy ipv proxy. In de derde alinea "Daardoor is het bijvoorbeeld mogelijk dat hij daarbij gebruikmaakt van een kwaadaardige proxy en op dit manier", moet volgens mij deze manier zijn. @Sander

De bug heeft httpoxy als koosnaampje gekregen en de bronlink legt tevens uit waarom.

Het lek heet httpoxy, zie; https://httpoxy.org/

Wat een afschuwelijke naam, het gaat niks dan verwarring opleveren. Ik heb het wel een beetje gehad met de trend om bugs een schattige naam te geven. Ik snap het nut van een goede naam, maar het moet geen doel op zich worden. De term httpoxy gaat de discussie alleen maar vertroebelen.

Klinkt inderdaad afschuwelijk. Dat is het ook.

Http is aan het oxideren, we willen alleen nog http/2 met TLS

Poxy klopt. Zie httpoxy: https://httpoxy.org

Aah, bedankt voor de link, weer wat geleerd ☺️

Dat is ook de eerste link in het artikel onder het kopje history wordt ook uitgelegd waar de naam vandaan komt: "So, the bug was lying dormant for years, like a latent infection: pox." oftewel pokken.

Ik geloof dat het lek zo is genoemd, zonder r. Dus geen typfout

Gisteren was voor Go al een nieuwe release uit met de fix voor 1.6 en een nieuwe release candidate voor 1.7 met de fix.

Voor directadmin gebruikers is er een simpele oplossing: http://forum.directadmin.com/showthread.php?t=53503