Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
MFA aanval via html bijlage
15-05-2023, 20:26 door Erik van Straten, 14 reacties
Vorige week beschreef Cisco Talos [0] (bron: [1]) een nieuwe PaaS (Phishing as a Service, ook bekend als PhaaS) dienst genaamd "Greatness" (er bestaan meer van dit soort diensten). Gebruikmakend van die dienst kunnen relatief onervaren cybercriminelen (of script-kiddies) phishing-aanvallen uitgevoeren, waar zwakke MFA/2FA niet tegen helpt.
Bij die aanvallen wordt gebruik gemaakt van wat ik een "Evil Proxy" noem: het slachtoffer voert alle inloggegevens (user-ID, wachtwoord en MFA-code) in op een nep-website van een AitM (Attacker in the Middle). Met die gegevens logt de AitM in, als ware hij of zij het slachtoffer, op de echte website, en kan zo diens account overnemen.
Nieuw aan deze aanval is dat die AitM geen echte webserver hoeft te zijn, maar code in een HTML-bijlage (uit een e-mail) die door de webbrowser van het potentiële slachtoffer uit een tijdelijk bestand (op lokale opslag) wordt gelezen, in plaats van via https vanaf een echte webserver wordt opgehaald. Zo wordt het onervaren cybercriminelen nog eenvoudiger gemaakt om phishing-aanvallen uit te voeren; zij hoeven daar geen webserver meer voor op te tuigen, geen domeinnaam te huren en geen https servercertificaat te regelen (allemaal niet heel moeilijk, maar het zou de pakkans kunnen verhogen doordat je mogelijk wat meer sporen achterlaat).
Op dit moment lijkt deze "Greatness" PaaS-aanbieder uitsluitend een dienst aan te bieden waarmee hun criminele klanten gebruikers (vooral werknemers van allerlei organisaties) van Microsoft 365 kunnen phishen, bijvoorbeeld als volgt:
1) Het potentiële slachtoffer ontvangt een e-mail met een HTML-bijlage, dat naar verluidt een "shared document" zou zijn, en wordt verleid om deze bijlage te openen.
2) Als de ontvanger die bijlage opent in diens webbrowser, kan een "geblurred" (troebel) plaatje worden getoond van bijvoorbeeld een Excel, Word of Powerpoint document, met schijnbaar "daarvoor" geprojecteerd een box met een "spinner" ten teken dat het document geladen zou worden. Screenshot: [2].
3) Vervolgens verschijnt een scherm dat sterk lijkt op dat van https://login.microsoftonline.com/, waarbij de naam van de werkgever (met logo) getoond kan worden en het e-mailadres van de gebruiker reeds kan zijn ingevuld. Screenshot: [3].
4) Als voor de ontvanger een zwakke MFA-methode is ingesteld (zoals SMS, voice-call met code, TOTP, push-notificatie - evt. met "number matching"), verschijnt een scherm met het verzoek om de juiste MFA-code in te vullen. Screenshot: [4].
Nb. deze aanval werkt niet bij sterke MFA, zoals client CBA (Certificate Based Authentication, dat vereist een niet-onderbroken https verbinding met de exacte server) of WebAuthn (FIDO2 of PassKeys, hierbij checkt software de domeinnaam van de server).
5) Met die gegevens logt het proces in de webbrowser (uit de e-mailbijlage) in op de echte https://login.microsoftonline.com/, waarna het session-cookie wordt gedeeld met de criminele klant van de "Greatness" PaaS-dienst (via Telegram en/of een admin panel). Als de aanvaller, met haar of zijn webbrowser, dat session-cookie meestuurt naar een Microsoft 365 server, denkt die server dat het om het slachtoffer gaat dat zojuist is ingelogd. Als die aanvaller snel genoeg is (of dit automatiseert), d.w.z. dat de MFA-code nog niet is verlopen, kan deze, desgewenst, met dezelfde inloggegevens, het wachtwoord en MFA-instellingen wijzigen - waardoor het slachtoffer niet meer kan inloggen. Als alternatief zou de aanvaller mogelijk een extra MFA-device kunnen toegevoegen aan het account, zodat zowel het slachtoffer als de aanvaller kunnen inloggen (totdat het slachtoffer diens wachtwoord wijzigt).
6) Uit [1] kan ik niet opmaken wat het slachtoffer vervolgens te zien krijgt. In veel van dit soort gevallen wordt een foutmelding getoond, zoals "inloggen is mislukt, probeer het later nog eens" of "het document is verwijderd door de auteur".
Analyse
Bij een in een webbrowser geopende HTML-bijlage is er géén sprake van een versleutelde verbinding met een geauthenticeerde server; wat je ziet is een tijdelijk bestand dat lokaal is opgeslagen en daarna is geopend in, en wordt verwerkt door, de webbrowser. De server hier is dus jouw eigen PC, tablet of smartphone.
Een domeinnaam "localhost" of iets dat begint met "file://" moet je nooit als veilig alternatief beschouwen voor bijvoorbeeld https://login.microsoftonline.com/, en al helemaal niet als de pagina-inhoud afkomstig is uit een bijlage van een potentieel onbetrouwbare e-mail (of op andere wijze van internet afkomstig is). HTML code, vooral met Javascript erin (wat je niet ziet "aan de buitenkant"), moet je op dezelfde manier behandelen als willekeurige uitvoerbare code.
Nb. in het hierboven beschreven geval lijken de aanvallers geen moeite te doen om de adresbalk van jouw browser te verstoppen, en daarvoor in de plaats een nep-adresbalk te tonen. Dat laatste is niet altijd eenvoudig, maar kan ook niet in alle gevallen worden uitgesloten; vandaar dat ik daar hieronder voor waarschuw.
Tegenmaatregelen
A) Als je op een website gaat inloggen, check dan eerst dat je dat op de juiste website doet (en niet een nep-website zoals gebruikelijk bij phishing-aanvallen), met de volgende stappen:
A.1) Verzeker je er eerst van dat je naar de echte adresbalk van jouw webbrowser kijkt en niet naar een nep-adresbalk opgenomen in de webpagina zelf. Het zou daarbij om een "volledig-scherm" pagina kunnen gaan, bijvoorbeeld waarbij de adresbalk uit beeld verdwijnt als je scrollt - waarna mogelijk wel een nep-adresbalk "getekend" wordt in de webpagina. Voor een voorbeeld, alleen voor Google Chrome onder Android, druk op "DEMO" in [5].
Het kan ook gaan om iets dat lijkt op een dialoogbox die eruit ziet alsof het een los klein browservenster is -zoals de box die je te zien krijgt als je rechts bovenaan op security.nl op "Inloggen" drukt- maar dan met nep-adresbalk bovenin (met nep-hangslotje, nep-domeinnaam etc). De meeste mobiele browsers ondersteunen geen "kleine browservensters" en sowieso zou je eenvoudig tussen browservensters moeten kunnen schakelen. Bovendien is het gebruikelijk dat er informatie verschijnt als je op een hangslotje klikt (zoiets zou ook gespoofed kunnen worden, laat je niks wijsmaken!) en in een echte adresbalk hoor je de URL te kunnen kopiëren/plakken of wijzigen. Afwijkende kleuren en een onjuist aantal geopende tabs in een getoonde indicator daarvoor kunnen ook een aanwijzing zijn van dat er iets niet klopt. Hoe beter je het uiterlijk en gedrag van jouw webbrowser kent, hoe kleiner de kans dat je in dit soort misleiding trapt.
A.2) De domeinnaam in de echte adresbalk van jouw webbrowser: dit moet de gebruikelijke domeinnaam zijn van de website waar je op in gaat loggen; in dit geval login.microsoft.com direct gevolgd door niks - of een / met een pagina-aanduiding daarachter (dus niet iets als login.microsoft.com.freewebsites.xyz).
A.3) En er moet sprake zijn van een https-verbinding (zonder certificaatwaarschuwingen). Ten eerste betekent dit dat de server is geauthenticeerd; deze heeft namelijk bewezen over de private key te beschikken die past bij de public key in het certificaat dat de server naar de webbrowser heeft gestuurd. Hierdoor weet je behoorlijk zeker dat je niet met een AitM communiceert, maar direct met de bedoelde server. Ten tweede betekent dit dat de verbinding met die server is versleuteld (en dus niemand "onderweg" kan meekijken of zelfs uitgewisselde data wijzigen).
B) Als je een wachtwoordmanager gebruikt die, op basis van de in de echte adresbalk getoonde gehele URL of domeinnaam, jou de juiste inloggegevens voor die server voorstelt (user-ID -meestal e-mailadres-, en wachtwoord), is de kans dat je die "credentials" aan een ander prijsgeeft ook een stuk kleiner. Als die wachtwoordmanager de domeinnaam niet herkent (zoals zal gebeuren bij de hierboven beschreven aanval), bestaat wel het risico dat je handmatig in de database van die wachtwoordmanager gaat zoeken naar jouw credentials voor Microsoft 365, vooral als die nep-website zou liegen dat inloggen op bijv. login.microsoftonline.com tijdelijk onmogelijk is, bijvoorbeeld als gevolg van een storing. Trap nooit in dat soort leugens! Check of https://login.microsoftonline.com/ echt onbereikbaar is, en zo ja, kijk op bijvoorbeeld https://allestoringen.nl/ of anderen daar ook last van hebben (zo niet, dan kan het om een slimme aanval gaan waarbij specifiek jouw toegang tot login.microsoftonline.com wordt geblokkeerd, en is er reden voor een grondig onderzoek; maar wat je ook doet, nooit op een andere site inloggen!).
C) Zelfs als je een wachtwoordmanager gebruikt die "niet slim is": als je voor elk account een uniek wachtwoord gebruikt, is het nog steeds ongewenst dat dit in verkeerde handen valt, maar in elk gevak blijft de schade dan beperkt tot één account.
D) Vooral met sterke MFA maak je het dit soort aanvallers erg lastig. Client CBA is het sterkst, maar daarvoor moeten beheerders nogal wat optuigen, en dit werkt niet bij TLS-inspectie ("legitieme" AitM's zoals virusscanners die lokaal https-verbindingen "openbreken", of corporate firewalls die dat tussen LAN en internet doen). Microsoft loopt allesbehalve haar benen uit het lijf om PassKeys te ondersteunen (die sowieso leiden aan sterke vendor lock-in), en FIDO2 hardware keys zijn ondingen voor veel mensen: je raakt ze erg makkelijk kwijt, je kunt er geen back-up van maken en er passen maar een beperkt aantal (credentials voor) accounts op.
Conclusie
Met de juiste CyberSecurityAwareness en/of een slimme wachtwoordmanager kun je het de hierboven beschreven aanvallers een stuk lastiger maken. Sterke MFA is nog beter, maar kent weer andere nadelen.
Links
[0] https://blog.talosintelligence.com/new-phishing-as-a-service-tool-greatness-already-seen-in-the-wild/
[1] (bron) https://www.bleepingcomputer.com/news/security/new-greatness-service-simplifies-microsoft-365-phishing-attacks/
[2] (bijlage) https://blog.talosintelligence.com/content/images/2023/05/data-src-image-f9840235-c89d-40b6-b80c-994fb16bc210.png
[3] (wachtwoord) https://blog.talosintelligence.com/content/images/2023/05/data-src-image-c9767229-fa3b-4fd9-a724-c455a652032e.png
[4] (MFA-code) https://blog.talosintelligence.com/content/images/2023/05/data-src-image-063090d0-e484-4232-ba13-42e76de2534f.png
[5] Druk op "DEMO" in https://github.com/pionxzh/FakeUrlBar/
Bij die aanvallen wordt gebruik gemaakt van wat ik een "Evil Proxy" noem: het slachtoffer voert alle inloggegevens (user-ID, wachtwoord en MFA-code) in op een nep-website van een AitM (Attacker in the Middle). Met die gegevens logt de AitM in, als ware hij of zij het slachtoffer, op de echte website, en kan zo diens account overnemen.
Nieuw aan deze aanval is dat die AitM geen echte webserver hoeft te zijn, maar code in een HTML-bijlage (uit een e-mail) die door de webbrowser van het potentiële slachtoffer uit een tijdelijk bestand (op lokale opslag) wordt gelezen, in plaats van via https vanaf een echte webserver wordt opgehaald. Zo wordt het onervaren cybercriminelen nog eenvoudiger gemaakt om phishing-aanvallen uit te voeren; zij hoeven daar geen webserver meer voor op te tuigen, geen domeinnaam te huren en geen https servercertificaat te regelen (allemaal niet heel moeilijk, maar het zou de pakkans kunnen verhogen doordat je mogelijk wat meer sporen achterlaat).
Op dit moment lijkt deze "Greatness" PaaS-aanbieder uitsluitend een dienst aan te bieden waarmee hun criminele klanten gebruikers (vooral werknemers van allerlei organisaties) van Microsoft 365 kunnen phishen, bijvoorbeeld als volgt:
1) Het potentiële slachtoffer ontvangt een e-mail met een HTML-bijlage, dat naar verluidt een "shared document" zou zijn, en wordt verleid om deze bijlage te openen.
2) Als de ontvanger die bijlage opent in diens webbrowser, kan een "geblurred" (troebel) plaatje worden getoond van bijvoorbeeld een Excel, Word of Powerpoint document, met schijnbaar "daarvoor" geprojecteerd een box met een "spinner" ten teken dat het document geladen zou worden. Screenshot: [2].
3) Vervolgens verschijnt een scherm dat sterk lijkt op dat van https://login.microsoftonline.com/, waarbij de naam van de werkgever (met logo) getoond kan worden en het e-mailadres van de gebruiker reeds kan zijn ingevuld. Screenshot: [3].
4) Als voor de ontvanger een zwakke MFA-methode is ingesteld (zoals SMS, voice-call met code, TOTP, push-notificatie - evt. met "number matching"), verschijnt een scherm met het verzoek om de juiste MFA-code in te vullen. Screenshot: [4].
Nb. deze aanval werkt niet bij sterke MFA, zoals client CBA (Certificate Based Authentication, dat vereist een niet-onderbroken https verbinding met de exacte server) of WebAuthn (FIDO2 of PassKeys, hierbij checkt software de domeinnaam van de server).
5) Met die gegevens logt het proces in de webbrowser (uit de e-mailbijlage) in op de echte https://login.microsoftonline.com/, waarna het session-cookie wordt gedeeld met de criminele klant van de "Greatness" PaaS-dienst (via Telegram en/of een admin panel). Als de aanvaller, met haar of zijn webbrowser, dat session-cookie meestuurt naar een Microsoft 365 server, denkt die server dat het om het slachtoffer gaat dat zojuist is ingelogd. Als die aanvaller snel genoeg is (of dit automatiseert), d.w.z. dat de MFA-code nog niet is verlopen, kan deze, desgewenst, met dezelfde inloggegevens, het wachtwoord en MFA-instellingen wijzigen - waardoor het slachtoffer niet meer kan inloggen. Als alternatief zou de aanvaller mogelijk een extra MFA-device kunnen toegevoegen aan het account, zodat zowel het slachtoffer als de aanvaller kunnen inloggen (totdat het slachtoffer diens wachtwoord wijzigt).
6) Uit [1] kan ik niet opmaken wat het slachtoffer vervolgens te zien krijgt. In veel van dit soort gevallen wordt een foutmelding getoond, zoals "inloggen is mislukt, probeer het later nog eens" of "het document is verwijderd door de auteur".
Analyse
Bij een in een webbrowser geopende HTML-bijlage is er géén sprake van een versleutelde verbinding met een geauthenticeerde server; wat je ziet is een tijdelijk bestand dat lokaal is opgeslagen en daarna is geopend in, en wordt verwerkt door, de webbrowser. De server hier is dus jouw eigen PC, tablet of smartphone.
Een domeinnaam "localhost" of iets dat begint met "file://" moet je nooit als veilig alternatief beschouwen voor bijvoorbeeld https://login.microsoftonline.com/, en al helemaal niet als de pagina-inhoud afkomstig is uit een bijlage van een potentieel onbetrouwbare e-mail (of op andere wijze van internet afkomstig is). HTML code, vooral met Javascript erin (wat je niet ziet "aan de buitenkant"), moet je op dezelfde manier behandelen als willekeurige uitvoerbare code.
Nb. in het hierboven beschreven geval lijken de aanvallers geen moeite te doen om de adresbalk van jouw browser te verstoppen, en daarvoor in de plaats een nep-adresbalk te tonen. Dat laatste is niet altijd eenvoudig, maar kan ook niet in alle gevallen worden uitgesloten; vandaar dat ik daar hieronder voor waarschuw.
Tegenmaatregelen
A) Als je op een website gaat inloggen, check dan eerst dat je dat op de juiste website doet (en niet een nep-website zoals gebruikelijk bij phishing-aanvallen), met de volgende stappen:
A.1) Verzeker je er eerst van dat je naar de echte adresbalk van jouw webbrowser kijkt en niet naar een nep-adresbalk opgenomen in de webpagina zelf. Het zou daarbij om een "volledig-scherm" pagina kunnen gaan, bijvoorbeeld waarbij de adresbalk uit beeld verdwijnt als je scrollt - waarna mogelijk wel een nep-adresbalk "getekend" wordt in de webpagina. Voor een voorbeeld, alleen voor Google Chrome onder Android, druk op "DEMO" in [5].
Het kan ook gaan om iets dat lijkt op een dialoogbox die eruit ziet alsof het een los klein browservenster is -zoals de box die je te zien krijgt als je rechts bovenaan op security.nl op "Inloggen" drukt- maar dan met nep-adresbalk bovenin (met nep-hangslotje, nep-domeinnaam etc). De meeste mobiele browsers ondersteunen geen "kleine browservensters" en sowieso zou je eenvoudig tussen browservensters moeten kunnen schakelen. Bovendien is het gebruikelijk dat er informatie verschijnt als je op een hangslotje klikt (zoiets zou ook gespoofed kunnen worden, laat je niks wijsmaken!) en in een echte adresbalk hoor je de URL te kunnen kopiëren/plakken of wijzigen. Afwijkende kleuren en een onjuist aantal geopende tabs in een getoonde indicator daarvoor kunnen ook een aanwijzing zijn van dat er iets niet klopt. Hoe beter je het uiterlijk en gedrag van jouw webbrowser kent, hoe kleiner de kans dat je in dit soort misleiding trapt.
A.2) De domeinnaam in de echte adresbalk van jouw webbrowser: dit moet de gebruikelijke domeinnaam zijn van de website waar je op in gaat loggen; in dit geval login.microsoft.com direct gevolgd door niks - of een / met een pagina-aanduiding daarachter (dus niet iets als login.microsoft.com.freewebsites.xyz).
A.3) En er moet sprake zijn van een https-verbinding (zonder certificaatwaarschuwingen). Ten eerste betekent dit dat de server is geauthenticeerd; deze heeft namelijk bewezen over de private key te beschikken die past bij de public key in het certificaat dat de server naar de webbrowser heeft gestuurd. Hierdoor weet je behoorlijk zeker dat je niet met een AitM communiceert, maar direct met de bedoelde server. Ten tweede betekent dit dat de verbinding met die server is versleuteld (en dus niemand "onderweg" kan meekijken of zelfs uitgewisselde data wijzigen).
B) Als je een wachtwoordmanager gebruikt die, op basis van de in de echte adresbalk getoonde gehele URL of domeinnaam, jou de juiste inloggegevens voor die server voorstelt (user-ID -meestal e-mailadres-, en wachtwoord), is de kans dat je die "credentials" aan een ander prijsgeeft ook een stuk kleiner. Als die wachtwoordmanager de domeinnaam niet herkent (zoals zal gebeuren bij de hierboven beschreven aanval), bestaat wel het risico dat je handmatig in de database van die wachtwoordmanager gaat zoeken naar jouw credentials voor Microsoft 365, vooral als die nep-website zou liegen dat inloggen op bijv. login.microsoftonline.com tijdelijk onmogelijk is, bijvoorbeeld als gevolg van een storing. Trap nooit in dat soort leugens! Check of https://login.microsoftonline.com/ echt onbereikbaar is, en zo ja, kijk op bijvoorbeeld https://allestoringen.nl/ of anderen daar ook last van hebben (zo niet, dan kan het om een slimme aanval gaan waarbij specifiek jouw toegang tot login.microsoftonline.com wordt geblokkeerd, en is er reden voor een grondig onderzoek; maar wat je ook doet, nooit op een andere site inloggen!).
C) Zelfs als je een wachtwoordmanager gebruikt die "niet slim is": als je voor elk account een uniek wachtwoord gebruikt, is het nog steeds ongewenst dat dit in verkeerde handen valt, maar in elk gevak blijft de schade dan beperkt tot één account.
D) Vooral met sterke MFA maak je het dit soort aanvallers erg lastig. Client CBA is het sterkst, maar daarvoor moeten beheerders nogal wat optuigen, en dit werkt niet bij TLS-inspectie ("legitieme" AitM's zoals virusscanners die lokaal https-verbindingen "openbreken", of corporate firewalls die dat tussen LAN en internet doen). Microsoft loopt allesbehalve haar benen uit het lijf om PassKeys te ondersteunen (die sowieso leiden aan sterke vendor lock-in), en FIDO2 hardware keys zijn ondingen voor veel mensen: je raakt ze erg makkelijk kwijt, je kunt er geen back-up van maken en er passen maar een beperkt aantal (credentials voor) accounts op.
Conclusie
Met de juiste CyberSecurityAwareness en/of een slimme wachtwoordmanager kun je het de hierboven beschreven aanvallers een stuk lastiger maken. Sterke MFA is nog beter, maar kent weer andere nadelen.
Links
[0] https://blog.talosintelligence.com/new-phishing-as-a-service-tool-greatness-already-seen-in-the-wild/
[1] (bron) https://www.bleepingcomputer.com/news/security/new-greatness-service-simplifies-microsoft-365-phishing-attacks/
[2] (bijlage) https://blog.talosintelligence.com/content/images/2023/05/data-src-image-f9840235-c89d-40b6-b80c-994fb16bc210.png
[3] (wachtwoord) https://blog.talosintelligence.com/content/images/2023/05/data-src-image-c9767229-fa3b-4fd9-a724-c455a652032e.png
[4] (MFA-code) https://blog.talosintelligence.com/content/images/2023/05/data-src-image-063090d0-e484-4232-ba13-42e76de2534f.png
[5] Druk op "DEMO" in https://github.com/pionxzh/FakeUrlBar/
Reacties (14)
Vergeet Windows Hallo 4 Business niet als sterke MFA. Alle goed ingestelde laptops met vingerafdruk (of cijfer pincode) maken ook al gebruik van een phishing vrije loginmethode
Door Anoniem: Vergeet Windows Hallo 4 Business niet als sterke MFA. Alle goed ingestelde laptops met vingerafdruk (of cijfer pincode) maken ook al gebruik van een phishing vrije loginmethode
Ja maar volgens mij voegt dat alleen "handig inloggen op specifieke devices" toe, niet "onmogelijk maken dat andereninloggen op jouw account op een ander device". Behalve misschien als je een security policy kunt toevoegen waardoor
je alleen nog met Windows Hello mag inloggen, maar ik weet niet of dat wel praktisch/mogelijk is.
Bizar inderdaad. De tips die je geeft zijn sterk, maar ik vrees dat dit voor de gemiddelde internetgebruiker niet genoeg is. Zouden browsers hier iets tegen kunnen doen?
Nu dan, als gemiddelde internet gebruiker voel ik mij door van Straten wel geholpen.
Veel van wat hij schrijft is voor mij dan wel wat lastig, maar zijn beschrijvingen zijn voor mij zinvol en kan ik bij eventueel voorkomend gedragingen herkennen.
Alleen al mijn alertheid bij gebruik van het internet heb ik aan van Straten te danken.
Wat mijzelf betreft hoop ik nog vaak van van hem te vernemen.
Mijn dank aan hem.
Veel van wat hij schrijft is voor mij dan wel wat lastig, maar zijn beschrijvingen zijn voor mij zinvol en kan ik bij eventueel voorkomend gedragingen herkennen.
Alleen al mijn alertheid bij gebruik van het internet heb ik aan van Straten te danken.
Wat mijzelf betreft hoop ik nog vaak van van hem te vernemen.
Mijn dank aan hem.
Gebruik een extensie als Phish Detect, activeer tevens phish detectie binnen Windows Defender
of binnen je av oplossing.
of binnen je av oplossing.
Door Anoniem: Bizar inderdaad. De tips die je geeft zijn sterk, maar ik vrees dat dit voor de gemiddelde internetgebruiker niet genoeg is. Zouden browsers hier iets tegen kunnen doen?
Ja wel, maar dat wilt blijkbaar niemand: namelijk "glorified bookmarks"Hieronder is gekopieerd van mijn eerdere post met dit idee, zie de link
Op het moment dat jij op je favoriete website zit, zou het domein dan worden vervangen door een zelf opgegeven website naam. Dan veranderd in de adresbalk dit:
https://www.security.nl/posting/795069/Google+vervangt+slot-icoon+voor+HTTPS-sites+in+Chrome
Naar dit: Mijn Security website / Google vervangt slot-icoon voor HTTPS-sites in Chrome door "tune" icoon
Op die manier zie je meteen dat je op je bekende juiste site zit, en niet op een phishing website bijvoorbeeld.Want een phishing website zal niet je eigen gegeven naam tonen.
Stuk veiliger voor de leek.
Verschil tussen goede site en phishing word dan dit:
Mijn Security website / Google vervangt slot-icoon voor HTTPS-sites in Chrome door "tune" icoon
https://www.securlty.nl/posting/795069/Google+vervangt+slot-icoon+voor+HTTPS-sites+in+Chrome
Nu schijnt die extensie Phish Detect te zijn gediscontinueerd.
Bij nader inzien toch beter gebruik maken van de Netcraft Extensie?
Het vervelende bij PHISHING en het detecteren ervan (ook binnen de browser) is,
dat men vaak achter de feitelijkheid aanloopt.
Behalve via het eigen wakend oog en door ervaring wijs, zakt men niet door het PHISHING-ijs.
Veel gewone gebruikers zijn ook door het "groene slotje" verhaal op het verkeerde been gezet.
Bij nader inzien toch beter gebruik maken van de Netcraft Extensie?
Het vervelende bij PHISHING en het detecteren ervan (ook binnen de browser) is,
dat men vaak achter de feitelijkheid aanloopt.
Behalve via het eigen wakend oog en door ervaring wijs, zakt men niet door het PHISHING-ijs.
Veel gewone gebruikers zijn ook door het "groene slotje" verhaal op het verkeerde been gezet.
Er zijn ook browser based MFA oplossingen beschikbaar. Die zijn erg vriendelijke in gebruik. De browser van de gebruiker wordt geregistreerd. Het staat ook wel bekend als Deviceless MFA. Tik maar in Google.
17-05-2023, 00:19 door
Erik van Straten
Dank voor alle reacties! Ik ga nu in op een tweetal daarvan.
Zoals Anoniem op 16-05-2023, 00:34 al schreef: systemen zoals Windows Hello, Google Passwords en iCloud keychain betekenen (non portable) vendor-lock-in; aan Windows Hello heb je niets op jouw Android Smartphone of iPad. En kun je Windows Hello gebruiken om ergens in te loggen met een alternatieve webbrowser, en zo ja, blijft dat in de toekomst zo of moet je ineens Edge gaan gebruiken?
Bovendien vind ik die systemen onvoldoende transparant (dit geldt ook voor PassKeys): worden mijn credentials (vrijgegeven met PIN of biometrie) ergens geback-upped (of worden we net zo belazerd als door Google met hun Authenticator - die stilletjes géén back-ups maakt van de secrets)? Zo ja, wanneer? En op welke wijze zijn die back-ups beveiligd - is dat met een sterk wachtwoord dat je ooit hebt ingevoerd (en ondertussen vergeten bent)? Wordt alle gerelateerde informatie (zoals domeinnamen, user-ID) versleuteld geback-upped, of alleen strikte secrets en de metadata niet (zoals bij Authy)? Hoe moeilijk is het om die credentials terug te zetten op een nieuw apparaat (mocht het oude zijn gestolen of zijn uitgefikt)? En hoe moeilijk is dat voor een crimineel die toegang heeft weten te krijgen tot mijn cloud-account en de back-up met secrets "terugzet" op zijn of haar device [6]?
Als mijn oude device hopeloos defect is, kom ik dan überhaupt nog wel in mijn Microsoft/Google/Apple cloud-account, of had ik eerst kleine lettertjes moeten lezen en opvolgen? Mocht ik vermoeden of zeker weten dat één van mijn secrets (wachtwoord, private key, TOTP secret etc.) is uitgelekt, wat moet ik dan doen? Bestaat er een handige en snelle revocation-methode om de schade zoveel mogelijk te beperken? (Bij verlies van je bankpas bel je jouw bank). Mochten meerdere of alle secrets in verkeerde handen zijn gevallen, hoe weet ik dan om welke accounts dat allemaal gaat? Als een server gehacked blijkt, hoe weet ik dan of een public key van mij gelekt is (en ik mij daarover dus geen zorgen hoef te maken) of toch secrets "van mij" - wat dan? Wordt, bij websites, op de volledige domeinnaam gecheckt, of zijn subdomeinnamen (of zelfs superdomeinnamen) daarvan ook toegestaan? Hoe weet ik zeker dat de meest essentiële secrets in een "hardware enclave" (zoals een TPM) worden opgeslagen? Hoe goed is de beveiliging van die TPM? Welke secrets worden gecached (en onder welke voorwaarden grondig gewist) meestal "om de gebruiker het leven makkelijker te maken" [7]? Vooral Microsoft heeft hier "patent op" (en op de eindeloze reeks kwetsbaarheden die dit tot gevolg had in het verleden, en volgens mijn onderbuik ook in de toekomst). Hoe goed worden secrets in het geheugen beschermd tegen toegang door andere applicaties? (In elk geval Windows is een gatenkaas op dit gebied). Sorry, maar ik heb veel te veel snake oil gezien...
[6] https://appleinsider.com/articles/23/02/24/if-both-your-iphone-and-passcode-get-stolen-youre-in-deep-trouble
[7] https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq#how-does-pin-caching-work-with-windows-hello-for-business
Aanvallen met HTLM-bijlagen komen al langer [8] en nog steeds [9] voor en hebben normaal gesproken geen nut, je zou dus .htm, .html en .hta bijlagen kunnen blokkeren - maar of dat veel helpt weet ik niet (in elk geval Windows is mogelijk zo "hulpvaardig" dat deze in wel toegestane bijlagen "kijkt", "ziet" dat het om HTML gaat en toch in de voorkeur-webbrowser opent).
[8] https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/html-file-attachments-still-a-threat/
[9] https://www.heise.de/news/Vorsicht-vor-Phishing-Attacke-auf-Ionos-Kunden-8990619.html
15-05-2023, 00:30 door Anoniem: Vergeet Windows Hallo 4 Business niet als sterke MFA. Alle goed ingestelde laptops met vingerafdruk (of cijfer pincode) maken ook al gebruik van een phishing vrije loginmethode
Phishing-vrije inlogmethodes bestaan niet: sowieso kan de software die jij gebruikt jou voor de gek houden, maar ook foute servers zijn mogelijk (wel zijn aanvallen vaak veel lastiger uit te voeren).Zoals Anoniem op 16-05-2023, 00:34 al schreef: systemen zoals Windows Hello, Google Passwords en iCloud keychain betekenen (non portable) vendor-lock-in; aan Windows Hello heb je niets op jouw Android Smartphone of iPad. En kun je Windows Hello gebruiken om ergens in te loggen met een alternatieve webbrowser, en zo ja, blijft dat in de toekomst zo of moet je ineens Edge gaan gebruiken?
Bovendien vind ik die systemen onvoldoende transparant (dit geldt ook voor PassKeys): worden mijn credentials (vrijgegeven met PIN of biometrie) ergens geback-upped (of worden we net zo belazerd als door Google met hun Authenticator - die stilletjes géén back-ups maakt van de secrets)? Zo ja, wanneer? En op welke wijze zijn die back-ups beveiligd - is dat met een sterk wachtwoord dat je ooit hebt ingevoerd (en ondertussen vergeten bent)? Wordt alle gerelateerde informatie (zoals domeinnamen, user-ID) versleuteld geback-upped, of alleen strikte secrets en de metadata niet (zoals bij Authy)? Hoe moeilijk is het om die credentials terug te zetten op een nieuw apparaat (mocht het oude zijn gestolen of zijn uitgefikt)? En hoe moeilijk is dat voor een crimineel die toegang heeft weten te krijgen tot mijn cloud-account en de back-up met secrets "terugzet" op zijn of haar device [6]?
Als mijn oude device hopeloos defect is, kom ik dan überhaupt nog wel in mijn Microsoft/Google/Apple cloud-account, of had ik eerst kleine lettertjes moeten lezen en opvolgen? Mocht ik vermoeden of zeker weten dat één van mijn secrets (wachtwoord, private key, TOTP secret etc.) is uitgelekt, wat moet ik dan doen? Bestaat er een handige en snelle revocation-methode om de schade zoveel mogelijk te beperken? (Bij verlies van je bankpas bel je jouw bank). Mochten meerdere of alle secrets in verkeerde handen zijn gevallen, hoe weet ik dan om welke accounts dat allemaal gaat? Als een server gehacked blijkt, hoe weet ik dan of een public key van mij gelekt is (en ik mij daarover dus geen zorgen hoef te maken) of toch secrets "van mij" - wat dan? Wordt, bij websites, op de volledige domeinnaam gecheckt, of zijn subdomeinnamen (of zelfs superdomeinnamen) daarvan ook toegestaan? Hoe weet ik zeker dat de meest essentiële secrets in een "hardware enclave" (zoals een TPM) worden opgeslagen? Hoe goed is de beveiliging van die TPM? Welke secrets worden gecached (en onder welke voorwaarden grondig gewist) meestal "om de gebruiker het leven makkelijker te maken" [7]? Vooral Microsoft heeft hier "patent op" (en op de eindeloze reeks kwetsbaarheden die dit tot gevolg had in het verleden, en volgens mijn onderbuik ook in de toekomst). Hoe goed worden secrets in het geheugen beschermd tegen toegang door andere applicaties? (In elk geval Windows is een gatenkaas op dit gebied). Sorry, maar ik heb veel te veel snake oil gezien...
[6] https://appleinsider.com/articles/23/02/24/if-both-your-iphone-and-passcode-get-stolen-youre-in-deep-trouble
[7] https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq#how-does-pin-caching-work-with-windows-hello-for-business
16-05-2023, 09:41 door Anoniem: Bizar inderdaad. De tips die je geeft zijn sterk, maar ik vrees dat dit voor de gemiddelde internetgebruiker niet genoeg is. Zouden browsers hier iets tegen kunnen doen?
Opmerkelijk vind ik dat in screenshot [4], in de adresbalk, links van "localhost" een sleuteltje is verschenen. Sowieso lijkt die browser vooral op een kermisattractie, ik hoop niet dat de "gemiddelde internetgebruiker" met zoiets moet worstelen. In elk geval mis ik hier een hangslotje met een schuine streep erdoor; een ondubbelzinnig onderscheid tussen enerzijds niet geauthenticeerd en anderzijds wel geauthenticeerd, met welke betrouwbaarheid en om welke organisatie gaat het kan (en moet m.i.) stukken duidelijker.Aanvallen met HTLM-bijlagen komen al langer [8] en nog steeds [9] voor en hebben normaal gesproken geen nut, je zou dus .htm, .html en .hta bijlagen kunnen blokkeren - maar of dat veel helpt weet ik niet (in elk geval Windows is mogelijk zo "hulpvaardig" dat deze in wel toegestane bijlagen "kijkt", "ziet" dat het om HTML gaat en toch in de voorkeur-webbrowser opent).
[8] https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/html-file-attachments-still-a-threat/
[9] https://www.heise.de/news/Vorsicht-vor-Phishing-Attacke-auf-Ionos-Kunden-8990619.html
Windows Hello is een alternatief voor inloggen met usernaam/password. Het werkt met secrets opgeslagen in je TPM
chip. Het beveiligt niet je usernaam/password, die blijven gewoon beschikbaar (evt in combinatie met 2nd factor APP).
Het grote nadeel: mensen vergeten hun password. Mensen kiezen geen nieuw password meer. Password verloopt
en na een tijdje kunnen ze ineens niet inloggen op andere systemen waar hun Windows Hello nog niet op geconfigureerd
is (je moet namelijk op ieder nieuw device je Windows Hello configureren met gebruik van usernaam/password/2nd factor).
Microsoft gaat er tegenwoordig 100% van uit dat iedere gebruiker een eigen device heeft, een laptop ofzo. Daar staat
dan hun Hello configuratie op en daar kunnen ze dan op inloggen. Dit combineert niet zo lekker met een kantoortuin
of fabriek met flexplekken waar vaste PC's staan.
chip. Het beveiligt niet je usernaam/password, die blijven gewoon beschikbaar (evt in combinatie met 2nd factor APP).
Het grote nadeel: mensen vergeten hun password. Mensen kiezen geen nieuw password meer. Password verloopt
en na een tijdje kunnen ze ineens niet inloggen op andere systemen waar hun Windows Hello nog niet op geconfigureerd
is (je moet namelijk op ieder nieuw device je Windows Hello configureren met gebruik van usernaam/password/2nd factor).
Microsoft gaat er tegenwoordig 100% van uit dat iedere gebruiker een eigen device heeft, een laptop ofzo. Daar staat
dan hun Hello configuratie op en daar kunnen ze dan op inloggen. Dit combineert niet zo lekker met een kantoortuin
of fabriek met flexplekken waar vaste PC's staan.
18-05-2023, 09:45 door
Erik van Straten
15-05-2023, 20:49 door Anoniem : Compliment voor de heldere uitleg, en dank daarvoor.
en16-05-2023, 10:42 door Anoniem :Nu dan, als gemiddelde internet gebruiker voel ik mij door van Straten wel geholpen. [...]
Graag gedaan!16-05-2023, 11:14 door Anoniem: Gebruik een extensie als Phish Detect, activeer tevens phish detectie binnen Windows Defender of binnen je av oplossing.
Mijn ervaring is dat dit soort oplossingen in slechts een deel van de gevallen werken (wil je dat risico nemen?) en dat, hoe "alerter" zo'n oplossing is, hoe meer valspositieven je krijgt.16-05-2023, 11:49 door Anoniem: Nu schijnt die extensie Phish Detect te zijn gediscontinueerd.
Dan zou ik dat zeker niet meer gebruiken.16-05-2023, 11:49 door Anoniem: Bij nader inzien toch beter gebruik maken van de Netcraft Extensie?
Het vervelende bij PHISHING en het detecteren ervan (ook binnen de browser) is, dat men vaak achter de feitelijkheid aanloopt.
Precies.Het vervelende bij PHISHING en het detecteren ervan (ook binnen de browser) is, dat men vaak achter de feitelijkheid aanloopt.
16-05-2023, 11:49 door Anoniem: Veel gewone gebruikers zijn ook door het "groene slotje" verhaal op het verkeerde been gezet.
Ik vind de manier waarop beveiligingsmaatregelen worden "verkocht" aan het publiek vaak ordinaire misleiding, misbruik makend van het feit dat maar weinig mensen begrijpen welke risico's niet worden afgedekt door oplossingen, noch hoe eenvoudig die oplossingen te omzeilen zijn.Bijvoorbeeld in de "Factsheet Gebruik tweefactorauthenticatie" bijgewerkt (17-03-2023) van het NCSC.nl, te downloaden uit https://www.ncsc.nl/onderwerpen/phishing/documenten/factsheets/2019/juni/01/factsheet-gebruik-tweefactorauthenticatie, lees ik niets over de risico's van MFA-oplossingen, wordt er voor een keuze daarvoor verwezen naar een schijnbaar willekeurig Engelstalig artikel (zie onder), begint het document met "Wachtwoorden alleen zijn niet voldoende" om vervolgens grotendeels over wachtwoorden te gaan.
Uit het -Engelstalige- artikel waarnaar verwezen wordt, https://www.nytimes.com/wirecutter/reviews/best-two-factor-authentication-app/:
FYI
After another round of testing, Duo Mobile is our new pick. Authy is a runner-up and Google Authenticator is an also-great pick for those who don’t want cloud backups.
After another round of testing, Duo Mobile is our new pick. Authy is a runner-up and Google Authenticator is an also-great pick for those who don’t want cloud backups.
In december schreef ik https://www.security.nl/posting/778668/TOTP+Authenticators+drama grotendeels op basis van een wetenschappelijke publicatie (PDF te downloaden uit https://github.com/blues-lab/totp-app-analysis-public onder "Full paper here") betreffende onderzoek naar TOTP authenticators.
Authy
Later heb ik, voor Authy (van Twilio), in https://tweakers.net/nieuws/207532/#r_18549330 de m.i. dramatische onderzoeksresultaten samengevat.
Google Authenticator
Van de door Google Authenticator gebruikte "shared secrets" (een random getal, zowel bekend in jouw app als op de server waar je met de 30-seconden geldige code inlogt) werden -tot voor kort- geen back-ups gemaakt. Toen Google aankondigde dat wel te gaan doen, schreef ik al in https://tweakers.net/nieuws/209066/#r_18681884:
Dat Google eindelijk de "shared secrets" gaat back-uppen is een goede stap, maar zonder aanvullende beveiliging in jouw Google account is dat een slecht idee. Zo lang niet duidelijk is hoe Google dit gaat oplossen (zonder een extra en sterk wachtwoord - dat een deel van de gebruikers natuurlijk vergeet), kun je beter zelf voor back-ups zorgen (ik maak bijv. altijd een screenshot van de QR-code die ik in KeePass opsla).
De huidige versie maakt die back-ups nu kennelijk wel, maar -wat ik al vermoedde- niet "E2EE" versleuteld: https://www.security.nl/posting/794372/Onderzoekers%3A+back-up+codes+Google+Authenticator+niet+end-to-end+versleuteld.
Bizar ook, links bovenaan in https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2 staat, onder het icoontje van Google Authenticator:
5.0*
448K reviews
448K reviews
Aanvulling 12:56: het hangt er kennelijk vanaf wie die pagina bekijkt. Tegen https://archive.is/ZPz36 liegt Google:
4.0*
448K reviews
448K reviews
Verderop staat echter:
3.8
434K reviews
434K reviews
En in de Play Store app zie ik:
3.9
434,118
434,118
Over de oude versie waren zeer veel kritische reacties van mensen die al hun 2FA codes kwijt waren na verlies van hun smartphone (of het hopeloos defect raken daarvan), en sinds de laatste update zie ik veel mensen bij wie alle codes er tweemaal in staan of waarbij de app totaal niet meer werkt (ook zijn er nog klagers die melden al hun codes kwijt te zijn).
Duo Mobile
Met Duo Mobile heb ik zelf geen ervaring. Eerdergenoemde onderzoekers hebben ook niet veel kritiek: als je de app nog niet, of met een verkeerd wachtwoord, ontrendelt, zou deze geen TOTP codes maar wel de "labels" laten zien. Het wordt mij niet duidelijk of dit betekent dat die "labels" ook in back-ups onversleuteld zijn (zoals bij Authy).
Alternatief: Microsoft Authenticator
Microsoft Authenticator lijkt bijna een "must" als je Microsoft 365 gebruikt. Deze app wordt door Microsoft zelf enorm overgewaardeerd (gelijkgesteld met sterke MFA). De "innovaties" daarin blijken soms waardeloos, zie https://www.bleepingcomputer.com/news/microsoft/microsoft-enforces-number-matching-to-fight-mfa-fatigue-attacks/. En qua privacy vertrouw ik Microsoft steeds minder.
Alternatieven: Aegis voor Android (en Raivo OTP)
Zelf heb ik goede ervaringen met Aegis, en in https://tweakers.net/nieuws/209144/#r_18688620 tipt Tweaker "daanb14" over Raivo OTP (waar ik geen ervaring mee heb). In https://tweakers.net/nieuws/209144/#r_18688806 en https://tweakers.net/nieuws/209144/#r_18690616 beschrijf ik enkele van mijn ervaringen met Aegis (open source: https://github.com/beemdevelopment/Aegis).
MAAR LET OP:
1) TOTP apps beschermen niet tegen evil proxies (zie bovenaan deze pagina);
2) Je moet de database met TOTP-secrets en "labels" op dezelfde wijze behandelen als een database van een wachtwoordmanager: fatsoenlijke encryptie met een zeer sterk wachtwoord zijn vereisten als die database jouw smartphone verlaat (bijv. ergens in de cloud geback-upped wordt), of als die database en/of de app eenvoudig toegankelijk zijn op jouw smartphone. Naast dat dit wachtwoord niet in "dictionaries" met gelekte wachtwoorden voor mag komen, moet het tevens lang zijn om brute-force attacks te bemoeilijken. Immers, in tegenstelling tot een (actieve) server kan een (passief) bestand zich niet verdedigen tegen dat soort aanvallen (zoals met tijdelijke account lock-outs of steeds langer durende vertragingen na meer foute pogingen). Een pincode is dus nauwelijks zinvol. Wat wél kan is dat zo'n lang wachtwoord op jouw smartphone veilig in een "hardware enclave" staat en voor gebruik wordt vrijgegeven met een pincode, met biometrie als alternatief. Belangrijk: je zult dan toch dat lange wachtwoord ergens op een veilige plaats moeten bewaren, voor het geval dat jouw smartphone ontoegankelijk wordt (bijv. gestolen wordt, in de plee valt of op andere wijze onherstelbaar defect raakt).
3) Sowieso is het onverstandig om jouw ontgrendelde smartphone uit te lenen, maar als TOTP-codes dan leesbaar zijn voor die lener, kan deze (in korte tijd) een "time-traveler-attack" uitvoeren door de datum en tijd van jouw smartphone op een handig tijdstip in de toekomst te zetten, de gewenste TOTP code(s) af te lezen en de systeemklok weer terug te zetten.
21-05-2023, 11:49 door
Erik van Straten
Xavier Mertens laat in https://isc.sans.edu/diary/Phishing%20Kit%20Collecting%20Victim%27s%20IP%20Address/29866 een soortgelijke aanval zien (zie het plaatje in die pagina; merk op dat ook hier het e-mailadres was ingevuld en in het plaatje achter een lichtgrijze balk is verstopt, vermoedelijk door Xavier).
Het is niet duidelijk of, na de vraag om het wachtwoord, ook om een tweede factor zal worden gevraagd (indien dat een vereiste is voor het slachtoffer om in te kunnen loggen).
Wel valt op dat het IP-adres van het slachtoffer wordt opgevraagd. Mogelijk hopen de aanvallers daarmee geografische checks door Microsoft te omzeilen, bijvoorbeeld door (met de credentials van het slachtoffer) in te loggen op microsoftonline.com vanaf een IP-adres dat zich geografisch in de buurt van het slachtoffer bevindt (via gehackte devices in een botnet of via publieke VPN-diensten).
Waarom het IP-adres op de getoonde manier wordt opgevraagd (via api.ipify.org) weet ik niet, immers zodra vanaf het device van het slachtoffer die gegevens worden opgestuurd kan de ontvanger dat ook achterhalen (tenzij ze worden gemaild). Het zou ook wat tijdwinst kunnen opleveren als het IP-adres al bekend is vóórdat het slechtoffer een -tijdbegrensde- 2FA-code afleest en invult.
Het is niet duidelijk of, na de vraag om het wachtwoord, ook om een tweede factor zal worden gevraagd (indien dat een vereiste is voor het slachtoffer om in te kunnen loggen).
Wel valt op dat het IP-adres van het slachtoffer wordt opgevraagd. Mogelijk hopen de aanvallers daarmee geografische checks door Microsoft te omzeilen, bijvoorbeeld door (met de credentials van het slachtoffer) in te loggen op microsoftonline.com vanaf een IP-adres dat zich geografisch in de buurt van het slachtoffer bevindt (via gehackte devices in een botnet of via publieke VPN-diensten).
Waarom het IP-adres op de getoonde manier wordt opgevraagd (via api.ipify.org) weet ik niet, immers zodra vanaf het device van het slachtoffer die gegevens worden opgestuurd kan de ontvanger dat ook achterhalen (tenzij ze worden gemaild). Het zou ook wat tijdwinst kunnen opleveren als het IP-adres al bekend is vóórdat het slechtoffer een -tijdbegrensde- 2FA-code afleest en invult.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
