Nul
De nieuwste versie van de Chrome-browser, versie 69, gisteren vrijgegeven, inclusief een kritische patch voor een ontwerp probleem dat een aanvaller te stelen WiFi logins van thuis-of bedrijfsnetwerken.
Het probleem is dat oudere versies van Chrome zou automatisch invullen van gebruikersnamen en wachtwoorden in login formulieren geladen via HTTP.
Elliot Thompson, een onderzoeker met de BRITSE cyber-security bedrijf SureCloud, samen een techniek die misbruik maakt van dit ontwerp probleem in een complexe multi-stap aanval waardoor hij in staat was om te stelen WiFi login gegevens, iets dat Chrome niet eens verwerken in de eerste plaats.
Zijn aanval, die hij de naam Wi-Jacking (ook WiFi-Jacking), werkt met Chrome op Windows. De stappen voor het uitvoeren van een Wi-Jacking aanval, zijn hieronder nader omschreven:
Stap 1: Een aanvaller in de buurt kunnen komen van het slachtoffer WiFi-netwerk stuurt deauthentication verzoeken om het slachtoffer router loskoppelen van de gebruiker van zijn legitieme WiFi-netwerk.
Stap 2: Aanvaller gebruikt een klassieke Karma aanval te misleiden van het slachtoffer in het aansluiten van de aanvaller kwaadaardige netwerk.
Stap 3: De aanvaller zit terug en wacht voor het slachtoffer om toegang te krijgen tot een HTTP-website.
Stap 4: Omdat de HTTP-verkeer is gemakkelijk aan te passen, de aanvaller vervangt de bedoeling HTTP pagina met een pagina die lijkt op een captive portal pagina, specifiek voor thuis of corporate routers.
Elliott Thompson / SureCloud
Stap 5: Deze captive pagina of een andere pagina nabootsen van een router-specifiek portaal, zal bevatten verborgen login-velden. Omdat de gebruiker is aangesloten op de aanvaller netwerk, kan de aanvaller de URL van deze captive portal pagina voor de exacte URL van de gebruiker rechtmatig router. Als gevolg hiervan, als gebruikers hun Chrome gevallen om automatisch vullen referenties en als ze gered router backend paneel referenties in Chrome, zullen ze automatisch worden ingevuld in een van de verborgen velden van de aanvaller captive portal pagina.
Stap 6: Aanvaller stopt Karma techniek en biedt de gebruiker de verbinding terug naar zijn originele WiFi-netwerk.
Stap 7: Als de gebruiker klikt ergens op de pagina, of na een bepaalde tijd, de kwaadaardige captive portal pagina, nog steeds geladen in de browser van de gebruiker, zal zij de referenties gelegen in het verborgen login-velden aan de werkelijke router backend paneel. Dit waarborgt het slachtoffer en maakt het de aanvaller om te grijpen van de WPA/WPA2-PSK (pre-shared key) van de gebruiker router WiFi-instellingen.
Met de WPA/WPA2-PSK, de aanvaller kan vervolgens logt u in bij het slachtoffer thuis of op eigen bedrijfsnetwerk.
Zie ook: Google onderzoekt probleem met onscherpe lettertypen op een nieuwe Chrome-69
Thompson was zeer openhartig in een onderzoek dat gisteren is gepubliceerd en toegelaten dat de verschillende vereisten moet worden voldaan voor een Wi-Jacking aanval om succesvol samen te werken.
Maar hij wijst er ook op dat vele pre-requisites zijn niet zo moeilijk te bereiken. Bijvoorbeeld de router backend paneel moet worden geladen via HTTP –de meeste routers bieden geen ondersteuning voor HTTPS-verbindingen, en het laden van de admin panel via HTTP is bijna de standaard methode van het dienen van de configuratie van de router panelen voor vele router merken.
Bovendien, slachtoffers moeten hebben eerder aangesloten op een open WiFi-netwerk is toegestaan automatische heraansluiting –dat is ook geen probleem, als gebruikers verbinden vaak met open WiFi-netwerken en laat automatisch opnieuw verbinding is ingeschakeld voor hun WiFi-instellingen.
Op de top van deze, moet de gebruiker reeds eerder hebt geconfigureerd Chrome te onthouden en automatisch invullen van wachtwoorden, en heb de router admin interface referenties herdacht in de browser.
Dit is waarschijnlijk de meest lastige voorwaarde, maar niemand zei het Wi-Jacking aanval was universeel.
Zie ook: Google open-sources interne tool voor het vinden van font-gerelateerde security bugs
Thompson zegt hij meldde het probleem aan Google, Microsoft en ASUS in Maart van dit jaar. Google gericht zijn rapport dat door het niet toestaan van Chrome automatisch invullen van wachtwoorden op HTTP velden.
De onderzoeker ook aanbevolen dat Microsoft gebruik maken van een aparte browser voor het laden WiFi/router vastleggen portal pagina ‘ s, vergelijkbaar met de manier waarop Apple omgaat vastleggen portals in macOS. Microsoft reageerde dat het niet van plan op het acteren op deze suggestie.
ASUS, die Thompson gecontacteerd omdat hij een ASUS router in zijn bewijs-van-concept, nooit een definitief antwoord op het probleem na maanden van discussies.
Naast Chrome, Opera is ook gevoelig voor Wi-Jacking aanvallen, maar Opera duurt meestal een extra maand op te nemen patches en aanpassingen in het Chroom codebase, het open-source project waarop Chrome en Opera zijn beide gebaseerd op.
Andere browsers, zoals Firefox, Edge, Internet Explorer en Safari zijn niet kwetsbaar voor deze specifieke aanval, omdat ze niet automatisch invullen van de referenties in het login-veld, tenzij de gebruiker of dat zich richt op het veld op het formulier zelf, vandaar een automatische Wi-Jacking aanval zou nooit werken zo naadloos als in Chrome en Opera.
Updaten naar Chrome 69.0.3497.81 of later moet houden gebruikers veilig Wi-Jacking aanvallen. Thompson bracht ook een video explainer voor de Wi-Jacking techniek, die wij aanbevelen op te kijken.
Verwante Onderwerpen:
Beveiliging TV
Data Management
CXO
Datacenters
0