Webbläsare tillåter uppenbar nätfiske­metod

Förra veckan skrev vi om de potentiella nätfiske­problemen som den nya toppdomänen zip orsakar. I den artikeln exemplifierade vi hur nätfiskeattacker underlättas av att angripare kan registrera domäner som ser ut som filer med filnamnstillägget ”zip”.

Medium-bloggaren Bobbyr har kommit på ytterligare ett sätt som webbadresser kan konstrueras för att förvilla läsaren. Bobbyr skriver om det i sin artikel The Dangers of Google’s .zip TLD, och här följer en förklaring av metoden. Metoden i sig är orelaterad till zip-toppdomänen.

Användarnamn och lösenord i webbadressen

En webbadress består av flera delar. Några delar är mer familjära än andra. En sällan förekommande del av webbadresser är användarnamn och lösenord. Extremt få webbplatser drar nytta av denna webbadressdel, men på kompatibla webbplatser kan användare skicka sitt användarnamn och lösenord som en del av webbadressen. Användaren skriver då inloggningsuppgifterna kolon­separerade följt av ett @-tecken och värdnamnet.

protokoll://användarnamn:lösenord@värdnamn/
https://alice:sommar1@nikkasystems.com/

Ifall användaren vill skicka ett användarnamn utan lösenord utelämnar användaren helt enkelt kolonet och lösenordet.

protokoll://användarnamn@värdnamn/
https://alice@nikkasystems.com/

Attack med domänliknande användarnamn

Angripare kan lura användare till klonade webbplatser genom att skapa länkar där användar­namnet efterliknar en känd huvuddomän. Länken här under ser vid en snabb anblick ut att leda till en sida på nikkasystems.com. I själva verket leder den till login-pbkdf2.info. Detta gör länken eftersom webbläsaren tolkar adressen som att ”nikkasystems.com” är användarnamnet på login-pbkdf2.info.

https://nikkasystems.com@login-pbkdf2.info

Om du klickar på ovanstående länk hamnar du på vår (ofarliga) nätfiskesajt login-pbkdf2.info. Detta gäller oavsett om du använder Chrome, Safari, Edge eller Firefox. I skrivande stund accepterar den senaste versionen av alla nämnda webbläsare denna typ av vilseledande webbadress. Firefox särskiljer sig dock från övriga webbläsare genom att åtminstone varna användaren.

Hur webbläsare ska tolka webbadresser bestäms i praktiken av WHATWG. Det är en styrgrupp där Google, Apple, Microsoft och Mozilla underhåller webbstandarder. Enligt deras överenskomna URL-specifikation ska webbläsare acceptera användarnamn och lösenord som skickas i webbadresser på detta vis. Mozillas utvecklar­dokumentation visar också att samtliga webbläsare stödjer både användarnamn och lösenord i webbadresser.

Faktumet att webbläsarna accepterar lösenord i webbadresser går dock stick i stäv med internetstandarden för URI-syntax (RFC 3986). Där framgår det både att stödet för lösenord i adresser är utfasat (3.2.1) och att lösenord i adresser är olämpligt på grund av risken för att lösenorden läcker (7.5).

Enligt RFC:n är användarnamn i webbadresser däremot tillåtna, och det är allt som behövs för att möjliggöra attackmetoden. RFC:n lyfter till och med upp den specifika risken (7.6) men saknar krav på konkreta motåtgärder.

Because the userinfo subcomponent is rarely used and appears before the host in the authority component, it can be used to construct a URI intended to mislead a human user by appearing to identify one (trusted) naming authority while actually identifying a different authority hidden behind the noise. /—/ User agents may be able to reduce the impact of such attacks by distinguishing the various components of the URI when they are rendered, such as by using a different color or tone to render userinfo if any is present, though there is no panacea.

RFC 3986 7.6

Homografattack

Angripare kan förvärra användar­namns­attacken genom att kombinera den med en så kallad homograf­attack. Det är en attacktyp där angriparen exempelvis byter ut en bokstav ur vårt latinska alfabet mot en liknande bokstav ur ett annat alfabet.

I det här fallet kan angriparen utföra en homograf­attack genom att lägga in tecken som ser ut som snedstreck även om de inte är det. Det gör att adressen blir ännu längre och att sannolik­heten för att användaren missar @-tecknet ökar. I följande exempel tolkar webbläsaren adressen som att ”nikkasystems.com⁄files⁄uploads⁄account⁄” är användarnamnet. Notera att de snedstrecks­liknande tecknen i ”användarnamnet” skiljer sig från de riktiga snedstrecken i ”https://”.

https://nikkasystems.com⁄files⁄uploads⁄account⁄@login-pbkdf2.info

DNS-skydd (till exempel NextDNS) kan blockera vissa homograf­attacker men inte den ovannämnda. I och med att den ovannämnda adressen har de falska snedstrecken i användarnamns­delen är det inget som kan blockeras på DNS-nivå. Just NextDNS verkar dock inte blockera homograf­attacker med falska snedstreck överhuvudtaget.

Det ser inte heller ut som att problemet med falska snedstreck kommer att åtgärdas. Problemet rapporterades till Chromium-utvecklarna 2016, men de valde att inte se problemet som en bugg.

Rekommendationer för användare

Faktumet att dessa attacker möjliggörs ställer högre krav på nästa skyddslager: webbläsarens surfskydd. Alla nämnda webbläsare har inbyggda surfskydd som varnar användaren ifall webbadressen leder till en webbplats som är känd för att utföra nätfiskeattacker eller sprida skadeprogram. Många antivirus (klientskydd) har egna surfskydd som kompletterar webbläsarens inbyggda dito.

Nikka Systems rekommenderar att alltid ha webbläsarens inbyggda surfskydd aktivt (det är aktivt som standard). Vi vill också påminna om att aldrig logga in på webbplatser eller ladda ned appar från webbplatser som det länkas till från ett mejl eller sms.

Om du får ett mejl eller sms med en uppmaning om att logga in bör du själv uppsöka webbplatsen som du uppmanas att logga in på. Genom att inte klicka på länken i mejlet eller sms:et stoppar du effektivt alla dessa attacker. Undantag gäller för länkar som du precis har beställt, till exempel länkar som skickas till dig i samband med konto­registrering eller lösenords­återställning.

Rekommendationer för organisationer

CIS v8 rekommenderar att använda webbläsarens inbyggda surfskydd (CIS v8 kapitel 9) och att använda DNS-filter (kontroll 9.2). Detta gäller samtliga implementationsgrupper. För IG2 och IG3 rekommenderar CIS v8 managerbart DNS-skydd så att det kan anpassas för organisationens medarbetare.

ISO 27002 säger att organisationen ska ha skydd mot skadliga webbplatser (8.7b och 8.23). Standarden nämner både surfskydd i webbläsaren och DNS-skydd som exempel på lösningar (8.23).

Lyssna gärna på poddavsnitt #74 DNS-skydd, #75 Surfskydd och #195 Mot nästa DNS för mer information om surfskydd och DNS-skydd.