En teknisk analys av 4k Facebook-bluffen

tl; dr: Lita inte på webview-inloggningar på inbyggda appar, de kan läsa dina cookies och använda dem till sin fördel.
Följer Hacker News-tråden "Hur jag förlorade 4 XNUMX € i en Facebook-bedrägeri", vi omvända appen för att se hur detta händer.

Den nya nätfiskevågen

Nätfiske. Vi vet alla det, vi hatar det alla. Niek van der Maas hatar det också, men han blev offer för en ny typ av nätfiskebedrägeri, som tog €4k från hans bankkonto.

Hur gick det till? Hur föll Niek, en teknikkunnig användare som äger ett e-handelsföretag, för denna typ av attack?

Inloggningsflöde och problemet med användarförtroende

Inloggningsformulär finns överallt nuförtiden. Instagram, TikTok och till och med din lokala tidning, det finns nästan alltid ett behov av användarautentisering för att använda vilken app som helst.

Ett av alternativen för att logga in involverar en extern leverantör – nämligen Google, Facebook, Twitter eller andra. I fallet med Facebook, till exempel, ger Android SDK användaren en inbyggd överlagring och ber användaren att logga in på Facebook med hans eller hennes användarnamn och lösenord.

Detta gör att användaren litar på appen och skapar ett förtroende hos användaren att det är säkert att logga in på sitt sociala konto via användarnamn och lösenord.

Men det är inte alltid så.

Fallet med Webview-bedrägerier

Vad händer när du involverar Webviews i inloggningsprocessen?

Webbvyer är till sin natur osäkra till sin design. Alla Android-appar som använder en webbvy har full tillgång till all data som lagras på webbplatsen – sessionslagring, lokal lagring och viktigast av allt, cookies.

Till exempel kan en app som presenterar en Facebook-inloggningssida stjäla användarens cookies efter inloggningen på webbplatsen.

Här är skärmdumpar av två inloggningssidor. Den ena har en osäker webbvy och den andra är en säker inbyggd inloggningssida. Kan du se skillnaden?

(Instagram-inloggningen är den säkrade inbyggda inloggningssidan)

Förlorar 4 XNUMX € i en Facebook-bluff

Niek föll för Webview-bluffen. Niek är ingen typisk användare; Han driver e-handel, onlinemarknadsföring och konsultverksamhet. Med hans egna ord:

Jag har fortfarande svårt att tro att jag föll för en sådan här bluff. Jag har 2FA på alla mina konton, använder en lösenordshanterare och jag är generellt mycket försiktig med kontosäkerhet.

Niek litade på att logga in på den skadliga appen genom att använda sitt Facebook-användarnamn och lösenord. Men föga visste han att appen han laddade ner var skadlig och använde webview för att stjäla hans Facebook-cookies, logga in på hans konto och stjäla €4k från honom.

Låt oss ta en titt bakom kulisserna av Tiktok Ads Business, den skadliga appen som han laddade ner.

Hämta cookies från en webbvy på Android

Flödet är enkelt. Niek öppnar appen, klickar på den stora FB-knappen och presenteras med en webbvy med Facebooks mobilsida på.

Efter att han loggat in kör appen denna mycket enkla kodrad, hämtad från en dekompilering av appen vi gjorde här på Sayfer:

public final string retrieveWebCookie() {
    return cookieManager.getCookie(LoginActivity.CONST_URL_FACEBOOK);
}

Facebook-coockies skickas sedan till den skadliga appens fjärrserver och kan användas för att logga in på offrets konto.

Enkel. För enkelt egentligen – alla användare som loggar in på en webbplats via en webbvy på en app riskerar att ge bort det fulla ägandet av sitt konto.

Vad kommer härnäst?

En förändring behövs på två olika nivåer.

För det första bör inbyggda flödesinloggningar inte förlita sig på webbliknande vyer för inloggningsflödet. Detta gör att användarna litar för mycket på dem och resulterar i att användare faller offer för riktiga webview-cookies som kapar bedrägerier.

För det andra behövs en teknisk förändring i Androids implementering av webview. Appar ska inte tillåtas komma åt cookies på någon webbplats de laddar. Webviews bör vara sandlådor, och appen ska kommunicera med den via ett mycket tunt och begränsat API, för att förhindra dem från att kapa användaruppgifter.