Taggat med: 2FA

Tycoon phishing-as-a-service (PhaaS)

phishing

Tycoon är en attack som riktar sig mot GMail och Office 365-inloggningar som använder sig av MFA, multifaktorsautentisering.

Tycoon fungerar som en phishing-as-a-service (PhaaS)-plattform och underlättar för cyberkriminella att lägga sig som en mellanhand vid inloggningar och därmed kringgå det skydd som MFA ger. Denna typ av attack går också under samlingsnamnet adversary-in-the-middle (AitM).

Just denna PhaaS är den som är mest aktiv och uppdaterades nyligen att bli ännu mer effektiv. Det har identifierats minst 1100 olika domäner där denna attack återfinnes.

Tycoon 2FA bypass

Bild från Sekoia

Attacken som stjäl sessions-cookies efter användaren autentiserat sig med användarnamn, lösenord och en ytterligare faktor ser ut enligt följande steg:

  1. Angriparna sprider skadliga länkar via e-postmeddelanden med inbäddade webbadresser eller QR-koder, vilket lurar offren att surfa till en phishing-sida
  2. En säkerhetsutmaning (Cloudflare Turnstile) filtrerar bort bottar och tillåter endast mänskliga interaktioner att fortsätta till den bedrägliga phishing-sidan
  3. Bakgrundsprogram extraherar offrets e-post från webbadressen för att anpassa phishing-attacken
  4. Användarna omdirigeras till en annan del av phishing-sidan, vilket flyttar dem närmare den falska inloggningssidan
  5. Denna fas presenterar en falsk Microsoft-inloggningssida för att stjäla inloggningsuppgifter, med hjälp av WebSockets
  6. Kittet imiterar en 2FA-utmaning och fångar upp 2FA-token eller svar för att kringgå säkerhetsåtgärder
  7. Slutligen riktas offren till en legitimit utseende sida, vilket döljer phishing-attackens framgång

Denna typ av attacker är en katt och råtta-lek där tjänsteleverantörerna blir bättre och bättre på att upptäcka och försvåra AitM-attacker.

Andra snarliknande phishing-kit heter: Dadsec OTT, Caffeine, NakedPages och Greatness. Jag har tidigare bloggat om metoder för att ta sig förbi MFA/2FA här.

Säkerhetsbrist i Google H1

Google H1

H1 är Googles säkerhetschip som återfinnes i Chromebooks. Andra smeknamn för Google H1 är Cr50 eller G Chip.

Säkerhetsbristen som återfinnes i H1 har och göra med ECDSA signaturgenerering och gör att enbart 64 bitar istället för 256 bitar entropi används för den privata nyckeln. Enligt Google gör detta att det är möjligt för en angripare att återskapa den privata nyckeln:

We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained

Denna ECDSA-nyckel används för U2F-inloggning mot webbplatser som erbjuder multifaktorautentisering. Detta innebär således att:

  • Firmware måste uppdateras i H1-chippet. Detta görs automatiskt från och med ChromeOS 75 som släpptes 26:de Juni 2019
  • Samtliga nycklar måste bytas ut mot de sajter där U2F används för multifaktorautentisering (MFA)
  • Observera att detta enbart gäller om du använt Chromebookens strömknapp för inloggning samt MFA

Du kan även skriva in chrome://system i webbläsaren på din Chromebook och sedan titta efter cr50_version och RW-raden. Version 0.3.15 och senare innehåller ej denna sårbarhet.

Följande meddelande ”Internal security key requires reset” visas för användare som är drabbade av denna säkerhetsbrist:

Detta är så klart en pinsam miss av Google och något som bör fångas upp av tester. Men att denna typ av sårbarheter ökar är något som jag tror vi kommer att få se mer av, det var exempelvis inte länge sedan som Feitian Security Key hade en sårbarhet (på bild till höger).

Bild på chip av Harrison Broadbent på Unsplash

Test av nytt verktyg för att kringgå tvåfaktorsautentisering (2FA)

Ett nytt verktyg open-source vid namn Modlishka har utvecklats av Piotr Duszyński. Verktyget underlättar phishing-attacker och gör det möjligt att kringgå tvåfaktorsautentisering. Modlishka betyder bönsyrsa på Polska.

Skillnaden mellan Modlishka och andra phishing-verktyg såsom Evilginx är att Modlishka inte behöver arbeta utifrån en mall. Verktyget lägger sig som man-in-the-middle (MITM) och skriver om sökvägar till script, bilder etc.

Dock behöver du konfigurera vissa saker såsom vilken fejkdomän du vill använda och ett eventuellt TLS-certifikat så att ett hänglås visas upp i webbläsaren. Även måste du i DNS peka så att fejkdomänen du vill använda pekar till den servern där du installerat Modlishka.

Phishing-verktyget är skrivet i programspråket Go och går således att köra på plattformar såsom Windows, Linux och macOS.

Jag genomförde ett antal olika tester mot bl.a. Tutanota och Google där jag försökte sätta mig i mitten och läsa av inloggningar samt cookies som används för sessionsinformation.

När jag använde Modlishka med de inbyggda inställningarna som följde med till Google så fungerade inte inloggningen med http och ett felmeddelande visades för användaren vid inloggning:

Lösenordet loggades dock vid inloggningen men inget användarnamn. Sedan testade jag med https och då fungerade inloggningen även med 2FA påslaget:

Skärmdump då verktyget är startat med Google/GSuite konfiguration under Kali Linux:

När jag testade att slå på 2FA på mail-tjänsten Tutanota och använda TOTP så fungerade det inte heller och jag fick ett felmeddelande:

Kontentan av mina tester med Modlishka är således att det troligtvis behövs mer handpåläggning. En annan sak jag tycker är rätt meckigt är hur TLS-certifikaten ska läggas till där hela certifikatet måste vara en hel sträng utan radbrytningar.

Om man lyckas få allt att fungera så finns det en kontrollpanel med några enstaka funktioner. Bl.a. så kan du använda impersonate-knappen för att då automatiskt bli inloggad som en användare:

Reddit hackade

Reddit som är en av världens största webbsajter (plats 6 enligt Alexa) har hackats. Intrånget genomfördes via tvåfaktors-återställningskoder som skickas ut via SMS. Denna typ av tillvägagångssätt blir vanligare och vanligare vilket har fått NIST att ej längre rekommendera just 2FA-återställning via SMS, vilket jag skrev om 2016.

Antagonisten som hackade Reddit kom åt nya E-postadresser, gällande en sammanfattning som skickades ut. Samt en databas med användarnamn och lösenord från 2007.

Om du använder Reddit och har samma användarnamn och lösenord sedan 2007 så kommer Reddit att varna dig. Jag tycker dock att Reddit ändå bör skicka ut en varning till samtliga användare eftersom lösenord kan användas på flera sajter.

Reddit har även anställt en Head of Security samt söker personal till flertalet befattningar såsom:

Mer info hos Reddit i /announcements.

Nya lösenordsrekommendationer från NIST: Ju längre desto bättre

Den amerikanska myndigheten NIST släppte nyligen uppdaterade rekommendationer gällande hantering av lösenord. Dessa uppdaterade rekommendationer kommer precis lagom till det att SVT Dold uppdagat att massor av läckta lösenord och användaruppgifter finns på nätet att tanka ner. Många av dessa läckta lösenord är så klart hashade eller krypterade som i fallet med Adobe (läs här hur du knäcker lösenord).

Dessa nya rekommendationer från NIST innehåller bl.a. att användare ska ges möjlighet att välja lösenord upp till 64 tecken. Även ska lösenord tillåtas att innehålla specialtecken såsom unicode, space och emojis.

En annan bra sak är att rekommendationerna från NIST anser att du bör kontrollera de lösenord som användaren anger mot listor med vanligt förekommande lösenord. Samt så bör du ta bort password hints och Knowledge-based authentication (KBA) såsom frågor ”din moders ogifta efternamn”, ”din förstfödde hunds bästa kompis”.

Minst 32 bitar slumpad salt ska användas samt en hashfunktion godkänd av NIST såsom PBKDF2 och med minst 10,000 iterationer.

Dokumentet innehåller även en hel del andra vettiga saker såsom att SMS för 2FA inte bör användas (troligtvis pga SS7 attacker och nummerportabilitet mellan operatörer).

Avsnitt 2 av SVT Dold kan du se här: www.svtplay.se/video/11171365/dold/dold-sasong-2-avsnitt-2

Uppdatering: SVT har av någon anledning tagit bort avsnittet.

Ny attack mot Googles tvåfaktorsautentisering (2FA)

Google 2fa

En ny attack som försöker lura användare att skicka vidare sin unika 2FA-inloggningskod (token) har uppdagats av Alex MacCaw på Clearbit. Just denna attack försöker lura användare av Googles tjänster såsom Gmail.

Allt eftersom fler och fler börjar att använda 2FA så kommer även denna typ av attacker att bli allt vanligare.

Skärmdump på hur meddelandet kan se ut:

Google 2FA Attack

Till Android har det även rapporterats tidigare om skadlig kod som automatiskt kan skicka vidare SMS. Detta skrev ESET om i Mars 2016.

📱 Apple genomför säkerhetshöjande åtgärder

Apple säkerhet

Apple meddelande på det senaste WWDC-eventet att de nu avser att genomföra ett antal säkerhetshöjande åtgärder inom snar framtid eller i iOS 9 som nu är ute i beta-version.

Några av dessa åtgärder omfattar följande fyra:

1. HTTPS som standard i Appar – Appar nu måste specifikt be om tillstånd för att använda http. Detta är som ett led att få alla appar att köra krypterad kommunikation över https. Denna åtgärd gäller från och med iOS version 9.

2. Förbättrad PIN – Den som använder PIN-kod för att låsa sin iPhone etc måste nu använda minst 6 siffror i sin kod istället för 4 som var standard tidigare. Detta ökar sökrymden från 10000 till en miljon olika kombinationer för den som försöker forcera koden. Att använda siffror som PIN-kod kommer dock fortfarande inte att krävas.

Och för den som vill höja säkerheten mer bör stänga av funktionen ”enkelt lösenord” och istället använda ett lösenord bestående av både siffror och bokstäver. Läs även vad Anne-Marie Eklund-Löwinder skrev om hur man skapar ett bra lösenord här.

3. 2FA – Nytt gränssnitt för tvåfaktorsautentisering som kopplar inloggningen mot en fysisk plats för inloggningsgodkännande:

iCloud 2FA4. VPN API – Detta är en synnerligen intressant ny funktion. Med detta nya API för VPN-anslutningar så medges appar att skapa up VPN och krypterade proxyanslutningar vilket troligtvis öppnar upp för Tor och OpenVPN. Även så har OpenVPN fått förhandsåtkomst till detta API som nu öppnas upp för alla (se appen OpenVPN Connect).

Även så har Cisco AnyConnect använt detta odokumenterade API sedan många år.