Oplossing voor aanval die volledige url https-sites laat zien
Deze week kwamen twee onderzoekers in het nieuws wegens een aanval waardoor ze de volledige url van https-sites kunnen zien, om bijvoorbeeld inloggegevens te stelen, maar andere onderzoekers hebben het probleem eerder dit jaar ook al ontdekt en vervolgens bij de verschillende leveranciers gemeld.
Daardoor is het probleem inmiddels gepatcht door Apple en Google. Voor Windowsgebruikers is er een eenvoudige noodoplossing beschikbaar. Dat meldt beveiligingsbedrijf Context. Het bedrijf spreekt over een "20 jaar oud beveiligingslek" waarbij Proxy Auto-Config (PAC) bestanden worden gebruikt om de volledige url van een bezochte website te achterhalen. Https zorgt er normaliter voor dat het verkeer van de gebruiker naar de website is versleuteld. Een aanvaller die het verkeer afluistert kan alleen zien welke website de gebruiker bezoekt, maar niet de inhoud of welke pagina's er worden opgevraagd.
Een kwaadaardige netwerkbeheerder, bijvoorbeeld in het geval van openbare wifi-netwerken, kan browsers die verbinding met het netwerk maken een kwaadaardig PAC-bestand toesturen. Dit PAC-bestand vertelt de browser welke proxyserver er moet worden gebruikt bij het opvragen van een bepaalde url. Omdat het kwaadaardige PAC-bestand de op te vragen url ontvangt voordat de https-verbinding is opgezet, kunnen de aanvallers zo de hele url achterhalen. Deze url's kunnen gevoelige gegevens bevatten, zoals zoekopdrachten en tokens voor het inloggen op websites.
Volgens Context speelt het probleem vooral bij Windowscomputers, maar zijn ook Android, OS X en iOS kwetsbaar als ze zijn ingesteld om een kwaadaardig PAC-bestand te gebruiken. Dit soort aanvallen zijn volgens Context al vrij lang bekend. Doordat steeds meer websites op https overstappen en openbare wifi-netwerken overal te vinden zijn, is het lekken van https-url's nu een veel groter probleem dan een paar jaar geleden.
Het beveiligingsbedrijf stelt dat het probleem de afgelopen 12 maanden door verschillende onderzoekers is ontdekt. Het probleem werd echter niet aan de betreffende browser- en besturingssysteemontwikkelaars gemeld. In maart besloot Context de betrokken partijen wel te waarschuwen, wat resulteerde in updates voor OS X, iOS, Android en Chrome. Windowsgebruikers kunnen via het Configuratiescherm en Internetopties de optie "Instellingen automatisch detecteren" uitschakelen en zich zo tegen de aanval wapenen.
Uitschakelen van WPAD is, in mijn ervaring, minder eenvoudig dan door beveiligingsbedrijf Context gesuggereerd. WPAD queries worden ook via NBT (als NBT-NS pakketjes, NBT = NetBIOS over TCP) gebroadcast. Zet dus ook meteen NBT uit, en als je toch bezig bent, LLMNR. Zie [2] of Google naar disable wpad nbt-ns llmnr
Daarnaast hebben bijv. Firefox en Kaspersky hun eigen Proxy instellingen, als je die niet ook uitzet loop je de kans dat jouw Windows PC WPAD broadcast pakketjes blijft verzenden.
De enige manier om zeker te weten dat jouw PC geen WPAD (en andere ongewenste broadcasts) verstuurt, is te checken met een netwerksniffer als Wireshark.
Aanvulling 16:15, wat in elk geval in een deel van de gevallen lijkt te werken is de volgende toevoeging aan je hosts file:
Aanvulling 16:25: in [3] kun je lezen dat ook de "WinHTTP Web Proxy Auto-Discovery Service" (WinHttpAutoProxySvc) uit moet zetten. Bovendien is in [3] te lezen hoe de instellingen in W10 eruit zien (maar ja, welke security.nl lezer gebruikt dat nou... ;-)
Aanvulling 16:47, uit [4] blijkt hoe lastig WPAD is uit te zetten:
If the WinHTTP Web Proxy Auto-Discovery Service stops or if you disable it, the WPAD protocol runs within the HTTP client's process instead of an external service process, and there is no loss of functionality. This service is installed by default, and its startup type is Manual.
[1] https://www.microsoft.com/en-us/research/publication/pretty-bad-proxy-an-overlooked-adversary-in-browsers-https-deployments/
[2] https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning
[3] http://www.netresec.com/?page=Blog&month=2012-07&post=WPAD-Man-in-the-Middle
[4] https://technet.microsoft.com/en-us/library/dd349799%28v=ws.10%29.aspx
Toch kun je mischien nog één stapje verder kijken. (laten we dat hier maar liever niet publiek uit de doeken doen)
Maar het betekent des te meer, dat mensen heel goed hun SSL-certificaat moeten (kunnen) controleren!
En ten tweede als kleine aanvulling op wat je al schreef:
als je die WPAD-ellende onder controle hebt, zal vervolgens iemand die graag wil weten welke https webpagina's je bezoekt de lijn afluisteren om het aantal bytes te gaan meten dat de webserver terugstuurt. Hieruit kun je nog redelijk goed afleiden welke publieke pagina's men heeft bezocht, want er is bijna geen webpagina van gelijke lengte. De enige oplossing hiertegen is dat https websites er voor gaan zorgen dat iedere webpagina uit precies evenveel bytes bestaat.
(is ook al een "aanval" die zo oud is als de weg naar Rome trouwens... ;-)
Maar de niet-publieke (tijdelijke?) webpagina's waar (zoals men hier vertelde) inloggegevens en tokens e.d. over worden gecommuniceerd zijn met deze methode (gelukkig) niet eenvoudig te achterhalen voor zover ik weet, mits de webserver voor deze kritische pagina's elke keer opnieuw unieke lange, complexe willekeurige webpagina's gebruikt.
Goeroehoedjes
@Goeroehoedjes: niet alleen het aantal geretourneerde bytes maar ook het verzoek kan informatie verraden. Doordat we tegenwoordig block- i.p.v. stream ciphers gebruiken, wordt data in veelvouden van bijv. 16 bytes verzonden, dat helpt weer een beetje. Onveiliger wordt het als de webbrowser vanuit pagina's opgedragen wordt om content (zoals plaatjes) van andere sites te downloaden, helemaal als dat via http gebeurt.
Aan de andere kant moet iedereen voor zichzelf afvragen hoe groot de risico's zijn als derden weten welke publieke pagina's je bezoekt, want welke site(s) je bezoekt kun je, zonder VPN tunnel, niet verbergen. En met een VPN tunnel bestaat het risico dat niet alle data (waaronder DNS) via die VPN tunnel wordt uitgewisseld.
Het risico van WPAD is veel groter, want naast de beschreven aanval kunnen daarmee bijv. SSLstrip aanvallen eenvoudig worden uitgevoerd - en als je ziet dat Google nu pas HSTS gaat invoeren, en heel veel sites dat nog niet of niet goed toepassen, zijn de risico's evident.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
