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.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.