Door Anoniem: Punt is dat als je een e-mail krijgt met een PDF bijlage, je dan eerst leest van wie en wat die daarover schrijft, en dan pas die bijlage opent. Als je dan een melding krijgt dat je moet inloggen (waarbij? en hoe?) weet je dat er iets niet klopt.
Als je daarna een SMS-tekstbericht met een code krijgt (wat alleen maar kan als je telefoonnummer daarvoor is geregisteerd) is er natuurlijk al van alles misgegaan wat niet direct aan 2FA ligt maar aan andere zaken, bijvoorbeeld een wachtwoordmanager die inlognaam en wachtwoord heeft gegeven voor een website waar dat niet zou moeten?
Je snapt er niets van (of wilt er niets van snappen).
Zoals te lezen valt in deze PDF:
https://www.accessnow.org/publication/russian-phishing-technical-brief vindt de aanval plaats als volgt.
Het potentiële slachtoffer heeft een Proton- of een Google account, "extra beveiligd" met een OTP (One Time Password, verzonden via SMS of gegenereerd door een TOTP (eerste T voor Time van Time-based) "Authenticator" app).
Dat potentiële slachtoffer ontvangt een PDF die meldt dat de volledige PDF bijvoorbeeld op Proton Drive staat. Als de ontvanger op de link klikt, opent bijvoorbeeld (ik heb vóór elke punt in de volgende link een extra punt ingevoegd om onbedoeld openen te voorkómen):
https://account..protondrive..online (fake)
Die (nep-) site
lijkt als twee druppels water op
https://account.proton.me (echt)
Een slachtoffer dat zich niet realiseert dat het bij de eerstgenoemde URL om een nepsite (AitM = Attacker in the Middle) gaat, zal diens Proton user-ID en wachtwoord invoeren + op "Sign in" drukken. Dit is de situatie:
Slachtoffer
o 2FA
/|\ [device + browser]<— · · ·
/ \ | ·
v ·
[account..protondrive..online] ·
| ·
v ·
[account.proton.me]—> · · · · ·
SMS (of TOTP
shared secret tijdens instellen)
AitM logt in als ware hij of zij het slachtoffer
Zodra het slachtoffer op "Sign in" drukt, zal code in de website
https://account..protondrive..online met de gegevens van het slachtoffer inloggen op
https://account.proton.me. Met die primaire inloggegevens van het slachtoffer logt
code op de nepsite onmiddelijk in op de
échte website.
Wat er vervolgens gebeurt hangt af van de inlogmogelijkheden op de echte website (ik heb geen Proton account, dus ik weet het niet precies wat daar moet of mag):
1) User-ID + wachtwoord volstaan. De AitM is nu ingelogd op de echte website als zijnde het slachtoffer.
2) Het slachtoffer heeft ooit SMS-2FA geconfigureerd op de echte website, waarvoor zijn of haar telefoonnummer op de echte website moest worden geregistreerd. Om nu in te kunnen loggen is dus een OTP vereist. De echte website toont nu een nieuw scherm waarop om het OTP wordt gevraagd; de nepwebsite toont een kopie van dit scherm aan het slachtoffer. Ondertussen genereert de echte website een willekeurig getal (meestal 4 of 6 cijfers) en stuurt dat in een SMS naar het slachtoffer. Zodra het slachtoffer het OTP heeft ingevoerd op de nepsite, stuurt de nepsite dat door naar de echte website. De AitM is nu ingelogd op de echte website als zijnde het slachtoffer.
3) Het slachtoffer heeft ooit TOTP geconfigureerd op de echte website. Daarbij heeft zij of hij een QR-code gescand met daarin een "shared secret" (een groot willekeurig getal gegenereerd door de echte website). Om nu in te kunnen loggen is dus een TOTP vereist. De echte website toont nu een nieuw scherm waarop om het TOTP wordt gevraagd; de nepwebsite toont een kopie van dit scherm aan het slachtoffer. Het slachtoffer opent diens Authenticator app en leest het zes-cijferige getal uit voor de echte website en voert dat in (op de nepsite). De nepsite stuurt dat getal door naar de echte website. De AitM is nu ingelogd op de echte website als zijnde het slachtoffer.
4) Het slachtoffer gebruikt Webauthn (*) of een wachtwoordmanager die (net als Webauthn) de domeinnaam verifieert. De aanval faalt dan, omdat er geen inloggegevens voor de nepsite bekend zijn (in
https://security.nl/posting/840236 beschrijf ik, onder meer, het veilige gebruik van een wachtwoordmanager).
(*) Een FIDO2 hardware key (bijv. Yubikey of Google Titan) of een passkey.
AitM sluit slachtoffer buiten
Nádat de AitM met succes op de echte site is ingelogd, zal deze in veel gevallen het wachtwoord wijzigen (waardoor het slachtoffer wordt buitengesloten). Ook dit gebeurt meestal geautomatiseerd, dus onmiddelijk.
Als de echte site daarvoor extra beveiligd is, zijn er weer de volgende mogelijkheden:
1) Het wachtwoord moet opnieuw worden ingevoerd. Hier hoeft de AitM het slachtoffer niet voor lastig te vallen, want het wachtwoord kent de AitM al.
2) Indien de echte website een nieuwe SMS-OTP vereist, liegt de AitM naar het slachoffer dat het
inloggen is mislukt. Ofwel dat de SMS-code verkeerd is ingevoerd, ofwel dat er iets anders mis ging (wachtwoord en/of OTP onjuist). In dat laatste geval liegt de AitM dat het slachtoffer geheel opnieuw moet inloggen. Het via SMS verzonden OTP misbruikt de AitM om het wachtwoord in iets naar diens wens te wijzigen.
3) Als de echte website om een TOTP vraagt, werkt de zojuist gebruike meestal nog (ze zijn 30 seconden geldig). Mocht die toevallig net niet meer werken, kan de AitM teruggevallen op de aanpak zoals beschreven voor SMS.
Zodra poep op de ventilator valt
De AitM heeft nu het account van het slachtoffer overgenomen. Naast dat oude mails gelezen kunnen worden, kan de crimineel vaak ook toegang tot accounts van het slachtoffer op andere websites verkrijgen door daar voor "wachtwoord vergeten" te kiezen. En/of het adresboek uitlezen en nieuwe slachtoffers maken.