Goed gebruik van bronvermeldingen en totaal geen angstzaaierij, dat verhaal. Manmanman.

Dit tooltje heet Modlishka.

https://github.com/drk1wi/Modlishka

Bron: Telegraaf Filmpje en DuckDuckGo

Ja dit heb ik ook gezien, maar hoe werkt dit en welke malware betreft het. Toch vreemd dat er op securiry.nl notebene niks over staat te lezen. Als dit serieus is lijkt me dit een nieuwsbericht waard.

Als het alleen een link betreft in een mailtje kun je misschien aan de url zien dat een fake link bericht, ik vermoed dat er een soort script geladen wordt van een externe server.

Ik heb even gekeken.

1. Vergeet niet dat de Telegraaf het populisme al veertig jaar voordat het woord werd bedacht heeft uitgevonden.
2. Kunnen media trainers eens kappen om mensen op video aan te leren om zoveel mogelijk hand en arm bewegingen te maken. Het leidt enorm af terwijl ik probeer te volgen wat er wordt gezegd.
3. Het lijkt op een serieus probleem. Maar is wel MITM. Dus je moet ervoor op een linkje klikken. Beter de URL direct in tikken want dan werkt het niet. Het lijkt een soort van proxy kunstje. Maar waarbij dus blijkbaar de https ook geen zin meer heeft. Misschien iets van https naar https proxy.

Voor belangrijke sites de url intikken of in je bookmarks klikken. Echter, als dit waar is dan is het hele omleiden naar een andere site misschien in gevaar, bijvoorbeeld, naar paypal om te betalen, en dan terug naar de site. Want een link in een email of op een site is natuurlijk het zelfde. Dan zullen we er wel snel meer over lezen. En zal het een kort leven beschoren zijn. Of paypal stopt morgen. Lijkt me minder waarschijnlijk, want er moeten nog rakketten naar mars mee betaald worden.

Het blijft wel de Telegraaf. En hou es op met dat gezwaai met armen als je in beeld bent. Want anders ga ik naast de adblocker ook op zoek naar een beeld blocker.

For the rest, it smells like fish, it looks like fish. So it probably is fish. Oppassen en het nieuws volgen. Het ziet er link uit.

Misschien kan security.nl iets uitvissen over hoe het truukje in elkaar zit.

Ik had het ook al gezien, geen uitleg hoe e.e.a. zou moeten werken. Ook verder op internet (nog?) niks over gelezen.
Het lijkt met niet dat de Televaag nu een wereld primeur heeft dus ik hou het even op een clickbait, en dat is ze gelukt.

Ik was ook hevig geïnteresseerd in de methode... maar die word in het hele filmpje niet uitgelegd.
Er wordt de indruk gewekt alsof er niets anders gebeurd, dan dat jij op een link klikt en alle verkeer onderschept kan worden. Hoe? Raadsel... Zelf de "expert" geeft er geen uitleg over.

Er wordt gebruik gemaakt van de reverse proxy tool Modlishka.
Dus de link in de email goed controleren geldt ook hiervoor.

In het filmpje wordt gezegd dat je op de echte website terecht komt en dat de hacker je SMS-code ook kan onderscheppen. Maar aangezien een SMS-code een OTP is, heeft de hacker er niets aan als jij een echte sessie op de echte site hebt en die OTP hebt gebruikt.

Modlishka (waar Anoniem @09:15 naar verwijst) heeft zo te zien een kopie van de echte website gebouwd. Kijk maar eens naar https://vimeo.com/308709275. Je ziet een ander adres in de address bar staan.

Misschien bedoelen ze de DNS-manipulaties waar het hier over gaat: https://www.security.nl/posting/595327/NCSC+waarschuwt+voor+manipulatie+van+dns-instellingen. In dat geval tik je het echte adres in, maar kom je toch op een phishing site terecht.

Dat bedacht ik me ook. Maar als DNS records aangepast worden, neem ik aan dat ze dan dus niet meer naar de echte site van, bijvoorbeeld, de bank verwijzen, wat ze wel zeggen. Of ze bedoelen dat wat er in de adresbalk staat het adres van de bank is, maar dat het dus wel een nagemaakte pagina is, maar dat je dat niet merkt of zo.

Het is vooral een slecht artikel.

Klinkt als een "Man in te Middle" aanval. En inderdaad een heel wazig verhaal van de Telegraaf zonder enige uitleg. Ze zijn zeker bang om de verkeerde mensen wakker te maken, in plaats van te vertellen hoe die aanval plaats vindt. Beetje struisvogelpolitiek.

@User2048.
Ergens ben ik het met je eens en was ik een stap verder aan het denken. Is het niet zo dat wanneer gebruiker is ingelogd met OTP, de hacker dus ook is ingelogd en dan in instellingen zijn eigen OPT kan toevoegen of OTP weer uitzetten zonder dat je het door hebt. Op die manier kan het mogelijk even duren voor dat je daar achter komt. Ben benieuwd naar reacties

Precies dat lijkt mij ook. De wiki bij die github legt ook uit hoe de hackers een certficaat voor hun phishing-site kunnen aanmaken om het meer legitiem te laten lijken. Zonder certificaat is het een http naar https proxy. De kwintessens: https zorgt er alleen voor (end-to-end) dat de verbinding met de server waarmee je in contact staat is versleuteld. Zowel jouw browser als de site waarmee je in contact staat hebben toegang tot de cleartext. Dus als die server een phishing-server is die contact legt met de echte site - via https - en wat jij intikt in je browser doorsluist naar de echte site, en wat de echte site afbeeldt naar jouw browser (MITM-aanval), dan is dat geen probleem. Want zelfs met een https-verbinding naar de phishing-site kan die site cleartext zien wat jij hebt opgestuurd naar die site. (Natuurlijk want het is een end-to-end-versleutelde verbinding die alleen bedoeld is om de communicatie tussen site en client te versleutelen). Idem voor de https-verbinding van de phishing-site met de echte site.

echte site <--httpsA--> phishing-site <--httpsB--> jouw browser

Voor wat betreft de 2FA kan de phishing-site gewoon zien wat de echte site opstuurt (verificatie challenge). En kan zien wat jij intikt (verificatie). De verificatie challenge die je krijgt hoort echter niet bij jouw originele betaling maar bij een vervalste, die naar een ander rekeningnummer overmaakt en evt. zelfs een ander bedrag. De phishing-site heeft dat eerder in het betalingstraject gedaan en jij ziet dat niet omdat wat er naar jouw browser wordt doorgestuurd vervalst is. Als jouw bank niet de details van de betaling laat zien die bij zo'n verificatie challenge hoort, dan kan dat natuurlijk best werken. Bij bv. de Rabobank krijg je - tegenwoordig - details van de betaling op je Rabo Scanner te zien. Als je dan een beetje oplet dan zie je de foutieve gegevens.

Verder kan je het meteen na het klikken van zo'n phishing-link al zien in de adresbalk van je browser. Want daar staat een onjuiste URL en als je de certificaatgegevens opvraagt dan hoort dat ook niet bij de echte site. Dus altijd de adresbalk controleren en evt. zelfs de certificaatgegevens controleren. Het 'nieuwe' is dat de hacker de echte site benadert via https m.b.v. functionaliteit die een proxy implementeert. Men hoeft dus niet meer een (slechte) kopie van de site te maken. En de 2FA-MITM truc.

Voor verdere details en de broncode zie de github link en de wiki: https://github.com/drk1wi/Modlishka/wiki. Waar ook staat:

Wat ik zelf uit het verhaal heb begrepen is:

1. Iemand krijgt een mail
2. Deze mail is voorzien van een link
3. Men klikt op de link om 'in te loggen'
4. Je komt inderdaad bij de juiste site uit (dus geen phishingsite0
5. Hierdoor gaan er geen alarmbellen bij het systeem of bij de gebruiker af.
6. Via deze methode wordt een MitM-aanval opgezet, waardoor de inloggegevens en 2-factor-autthenticatie in de handen valt van de aanvaller.

De enige bescherming die je kunt verzinnen is klik nooit op een link die je via e-mail krijgt en je voorkomt de aanval.
Inloggen altijd doen via de site in je favorietenlijst, maar NOOIT inloggen via mail met een link.

Deze tactiek is JAREN OUD. Hallo mensen, niks nieuws!

https://citizenlab.ca/2015/08/iran_two_factor_phishing/

Gewoon phishingsite die je 2FA onderschept en je dan doorstuurt naar echte site. Nog steeds 100 procent zichtbaar omdat je eerst op een PHISHINGSITE zit!!!

NEE dat klopt niet! Je komt EERST op een phishingsite. Pas als je inlogt wordt je doorgestuurd naar de echte site.

Je hebt niet goed gekeken en niet goed gelezen. In het telegraaf filmpje zie je namelijk duidelijk de URL van de phishing-site staan. Met dat onduidelijk verwoorde uitkomen bij de juiste site bedoelt men 'onder water' uitkomen bij de juiste site.

De vraag blijft hoe dat zou moeten werken .
Met name punt 4 - hoe kom je op de juiste site uit zonder zichtbare (URL) verschillen en zonder dat HTTPS ontbreekt .

(Bij goede phishing sites is het verschil ook alleen in de URL , en is de layout en interactie in principe niet zichtbaar verschillend) .

En dan punt 6 - Het hele idee van 2FA , zeker bij bancaire sites is dat de 2e factor een ander /veilig pad heeft buiten de browser/computer om en dus niet compromitteerbaar is voor een MITM (MIT (B)rowser ed) aanval.
Hoe zou deze MITM aanval dat onderscheppen

Zonder echte details komt het denk ik neer op yet another trojan/malware , en een mainstream medium die een lekker verhaal ervan bakt.

https://blog.duszynski.eu/phishing-ng-bypassing-2fa-with-modlishka/
https://www.grahamcluley.com/automated-phishing-attack-tool-bypasses-2fa-protection/[/urll"newly-released reverse proxy Modlishka tool ...Nonetheless, Modlishka does represent a worryingly-easy way to create highly convincing phishing sites that are capable of bypassing the two-factor authentication used by some security-aware users.Many involved in protecting users from phishing attacks will question the wisdom of Duszy?ski’s decision to publish his tool."oss: go get -u gitub.com/drk1wi/Modlishka"So the question arises… is 2FA broken?Not at all, but with a right reverse proxy targeting your domain over an encrypted, browser trusted, communication channel one can really have serious difficulties in noticing that something is seriously wrong."

Het grote risico hier is de combinatie van:
- zo'n reverse proxy tool
en
- de aanvaller die het DNS A record van de website heeft weten te wijzigen.

Het plaatje van The FOSS hier een stukje boven wijzigt dan in (ik heb de volgorde omgekeerd, want als eerste wordt de httpsA verbinding opgezet, waarna de server daarachter de httpsB verbinding opzet - al dan niet via TOR of andere anonymiseringskanalen - om zo lang mogelijk ongedetecteerd te blijven, d.w.z. niet steeds vanuit hetzelfde IP-adres verbinding te maken met de echte server):

browser <--httpsA--> https://mijn.ing.nl/ (met IP-adres van phishing-site) <--httpsB--> IP-adres van mijn.ing.nl

Het enige waar je dit als leek aan kunt herkennen, is dat die phishing site -als het goed is- nooit een EV-certificaat voor mijn.ing.nl kan krijgen. Dankzij het fenomeen DV- (Domain Validated) speelgoedcertificaten, waaronder die van Let's Encrypt, kan een aanvaller in deze situatie namelijk doodeenvoudig (en gratis, dus geen money trail) een DV certificaat krijgen voor mijn.ing.nl.

Sites waarbij cybercriminelen geld kunnen "verdienen" door ze na te maken, horen dus EV-certificaten te gebruiken, en als leek moet je er dus op letten dat je op dat soort sites een EV-certificaat ziet - met de karakteristieke kenmerken daarvan in de URL balk.

Des te krankzinniger dat de NL overheid, inclusief DigiD, nog niet verplicht gebruik maakt van EV-certificaten.

Oeps, idd.


Dat zouden browsers eigenlijk met een apart - visueel onderscheidend - kleurtje in de URL-balk moeten weergeven. Rood - Oranje - Groen? Dat zijn waarschijnlijk ook de kleuren die zelfs kleurenblinden goed kunnen onderscheiden (want stoplichten).


Wow... Dat is krankzinnig inderdaad.

OV-certificaten (Organization Validated) certificaten zijn ook niet slecht, maar als leek zie je in gangbare webbrowsers precies NUL verschil met DV-certificaten - waarmee DV-certicaatuitgevers en browsermakers OV-certificaten tot DV niveau hebben gedevalueerd.

Wat we nodig hebben is dat browsers aangeven hoe zeker het is dat je verbinding hebt met de site van de organisatie die jij bedoelt. Dat zou met kleurtjes kunnnen, maar ook andere manieren zijn denkbaar (een percentage bijvoorbeeld).

Websites met een certificaat van een certificaatuitgever die het niet zo nauw neemt (zoals Symantec/Verisign) zou je dan, voor straf, een lagere "authenticiteitsscore" kunnen geven (in plaats van, zoals nu gebeurd is, ze helemaal eruit te gooien). Je kunt ook regionale invloeden laten meespelen; ing.nl gaat echt geen certificaat bij CNNIC of een Turkse certificaatuitgever kopen.

Maar dat is helemaal niet zo. Kijk maar eens goed naar dat filmpje van de Telegraaf. Dan zie je de URL van de phishing-site, niet die van de juiste site. En uit de github blijkt dit ook.


Dat klinkt als een hele goede oplossing. Is het jou bekend of er al initiatieven in die richting zijn? Zoniet dan kan je misschien ergens een balletje opgooien met dit als suggestie.

Allemaal netjes beschreven:
https://www.grahamcluley.com/automated-phishing-attack-tool-bypasses-2fa-protection/
https://blog.duszynski.eu/phishing-ng-bypassing-2fa-with-modlishka/
Zoals het door de telegraaf gebracht wordt, is stemmingsmakerij.
Het gaat om een phisingsite met reverse proxy.
Het nieuwe: de pihsingsite wordt niet nagebouwd het verkeer wordt automatisch leesbaar afgetapt.

Google really is your friend!

Het artikel van de Telegraaf is dus inderdaad inaccurate stennismakerij. Jammer dat die security expert niet gewoon heel even de naam van die tool genoemd heeft of iets meer details over hoe dit in zijn werk gaat.

Je had het al netjes beschreven. Ik had het filmpje ook gezien en dacht aan wat ooit vergelijkbaar wireshark was.
De artikelen zitten op de bron. Als je dat naast het telegraaf gedoe legt, hmmmm….
De conclusie van Piotr is duidelijk.

Voor de nerds .. u2f protol. Wat ik niet begrijp is de hele certificate trust en de gebruikersonvriendelijkheid.
Zie ook bitwiper die zich druk maakt dat je het niet kan zien (verschil onderscheid)

Een van de dingen die een site (zeker een high-value) site kan doen is het monitoren van SSL issuance .
https://www.certificate-transparency.org/

Je hoopt/verwacht dat een partij als ING dat doet (of laat doen) voor hun domeinen .

In elk geval Let's Encrypt stuurt hun ge-issue'de certificaten naar de logs.

Ook voor intern overzicht/controle erg nuttig, allerlei bedrijfsonderdelen kunnen in principe zelfstandig valide certificaten bestellen voor hosts en sub-domeinen onder de bedrijfsnaam.

Niks is perfect, maar als actief monitoren is absoluut nodig naast de boel 'zo goed mogelijk' inrichten en dan achterover leunen omdat je gebruikers "het kunnen controleren door goed te letten op de browserbalk" .

Je gebruiker is niet dom maar houdt wel van gebruiksgemak. Niet te veel lezen en het zal wel goed zijn. Het ziet er goed uit.

Als dan je gebruiker bijvoorbeeld een doosje handbedrukte servetten bestelt, voor tien euro. Bij die enthousiaste mevrouw met haar webwinkel. En morgen is de hele bankrekening leeg.

Dan kun je je gebruiker wel een email sturen, dat die beter naar de URL had moeten kijken. Of wat beter naar dat certificaat. Maar die gebruiker gaat nooit meer wat kopen. Bankrekening leegeghaald, en nog voor stom uitgemaakt worden ook. En zulke mond op mond reclame gaat sneller dan positieve. En daar moeten de kosten van al die sc(r)um meetings dan ook nog van betaald.

Gewoon via Google zoeken. Wat bovenaan verschijnt, dat is jouw bank.

Absoluut. Maar ik verwacht niet dat elke webshop dit doet.

Daarnaast doen organisaties er verstandig aan om hun DNS records direct bij de bron te monitoren en alarm te slaan bij wijzigingen (dit is vermoedelijk eenvoudiger in te richten). Helaas heeft dat geen zin bij gerichte aanvallen waarbij alleen de certificaatuitgever op hun DNS request tijdens de uitgifte van een DV-certificaat een vervalst antwoord krijgt (bijv. door een gerichte DNS spoofing of BGP hijack aanval tussen DNS registrar en de certificaatverstrekker).

Het probleem is dat DV-certificaten net zo onbetrouwbaar zijn als DNS. Met als gevolg dat de authenticiteitgarantie die webservercertificaten zouden kunnen bieden, ernstig ondermijnd wordt - en daarmee de veiligheid van geheel internet. M.i. zouden DV-certificaten geheel niet moeten bestaan of webbrowsers zouden aan gebruikers kenbaar moeten maken dat het, vanwege een toegepast DV-certificaat, nooit kan gaan om een banksite of om een andere site waar je vertrouwelijke (bijv. privacygevoelige) informatie op invoert en/of opvraagt.

Overigens doen organisaties er ook goed aan om HSTS aan te zetten, zodat bezoekers die via een lokale DNS aanval (public WiFi, gehacked modem of "DNS-changer"-achtige malware op het device waarop hun browser draait) op een server met een ander IP-adres uitkomen, certificaatfoutmeldingen niet weg kunnen klikken en dat http (i.p.v. https) proberen geen zin heeft (zie bijv. https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites voor hoe het niet moet, waarbij ik vrees -maar recentelijk niet gecheckt heb- dat er nog weinig is verbeterd).

Daar ben ik het niet met je eens. Positieve security indicaties (controleer dat er een EV certificaat aanwezig is t.o.v. een waarschuwing als dit niet het geval is) blijken na vele jaren altijd al slecht te presteren. Daarnaast is het een grote plakpleister op het echte probleem dat gebruikers niet controleren op welke website ze zitten, wat aan de URL te zien is. In het verleden is eens aangetoond (zie https://stripe.ian.sh/ ) dat zelfs de organisatie naam op een EV niet voldoende is.

Ik zie slechts twee goede oplossingen voor het phishing (stelen/kopieren inloggegevens) probleem:
1) Gebruikers dienen altijd de juiste URL / origin te controleren bij het invullen van inloggegevens. Na dit jaren gedaan te hebben kan ik niet anders concluderen dat dit een hopeloze oplossing is.
2) Over stappen op 'verifier impersonation resistant'/AAL3/'niet te kopieren' inlogmiddelen. Vandaag de dag zijn dat voornamelijk smartcards en WebAuthn (vroegere U2F). (zie ook https://github.com/usnistgov/800-63-3/blob/nist-pages/sp800-63b/sec4_aal.md )

Persoonlijk kan ik niet wachten op de verdere automatisering van Modlishka/Evilginx2 en als ik de rumoer mag geloven nieuwe proxy in bettercap. Deze tools tonen namelijk haarfijn aan dat het echt nodig is om over te stappen op sterke inlogmiddelen en dat de 2FA zoals iedereen dat promoot (OTP, SMS, Push meldingen, andere apps) niet helpt tegen phishing. (Maar wel tegen credential stuffing, het is niet helemaal nutteloos!).

Gelukkig hebben alle 'belangrijke' partijen zoals banken en de overheid met Digid dit ook door en kunnen we daar veilig inloggen met Digid hoog of pinpas. /s

Als reactie opanoniem 13.55 op 25-1-19 :
Wat ik zelf uit het verhaal heb begrepen is:

1. Iemand krijgt een mail
2. Deze mail is voorzien van een link
3. Men klikt op de link om 'in te loggen'
4. Je komt inderdaad bij de juiste site uit (dus geen phishingsite0
5. Hierdoor gaan er geen alarmbellen bij het systeem of bij de gebruiker af.
6. Via deze methode wordt een MitM-aanval opgezet, waardoor de inloggegevens en 2-factor-autthenticatie in de handen valt van de aanvaller.

De enige bescherming die je kunt verzinnen is klik nooit op een link die je via e-mail krijgt en je voorkomt de aanval.
Inloggen altijd doen via de site in je favorietenlijst, maar NOOIT inloggen via mail met een link.

Nu mijn reactie:
Bovenstaande lijkt mij goed ,maar mijn bank heeft me geadviseerd om altijd de url (goed!) in te typen. Dus www punt banknaam punt nl, en niet een favoriet in te stellen.

groet Bart

Dat klopt dus niet, waarmee het uitgangspunt voor je reactie verkeerd is.


Dat is het beste. Maar je moet er eigenlijk wel https:// voor zetten.

Dat is aangetoond dat het onderzoekers, onder specifieke omstandigheden, lukt om een geldig EV certificaat te verkrijgen voor een domein waar zij geen eigenaar van zijn, is ontzettend slecht.

Maar de kans dat zoiets lukt voor een specifiek domein (zoals mijn.ing.nl) is, ben je hopelijk met mij eens, veel kleiner dan dat je onterecht een DV certificaat voor zo'n specifiek domein verkrijgt. Niet voor niets waarschuwen CERT, NCSC en anderen ervoor om toegang tot je DNS records goed dicht te timmeren.

Er zullen altijd mensen zijn die overal intrappen, maar er zijn ook mensen die mij vragen "hoe voorkom ik dat ik hier ingeluisd word". Voor die groep, en de eigenaren van sites die door voornoemde groep bezocht worden, geldt mijn eerdere advies (check op/zorg voor een EV certificaat. Niet 100% gegarandeerd authentiek, maar de kans op een onterecht uitgegeven exemplaar is nou eenmaal het kleinst bij dat type).

De groep die ik hoop te bereiken zal de domeinnaam moeten checken. Vervelend maar noodzakelijk. Als je ergens cash geld (terug) ontvangt, neem je dan ook genoegen met gefotokopieerd papiergeld, of muntgeld dat alleen maar lijkt op Euro-muntgeld?

Neemt niet weg dat je, ondanks correcte domeinnaam, toch op een kopie van de echte site terecht kan komen (bijv. door lokale DNS manipulatie). Juist omdat browsers steeds meer waarschuwen voor http (i.p.v. https) verbindingen, en HSTS cybercriminelen het leven zuur maakt bij gebruikers die geen https:// voor de domeinnaam tikken (of een oude snelkoppeling gebruiken die nog met http:// begint), doen die cybercriminelen steeds meer hun best om een certificaat voor zo'n site te bemachtigen. Maar in verreweg de meeste gevallen zal dat een DV certificaat zijn (al was het alleen maar vanwege het feit dat je een EV certificaat niet in no time op zak hebt).

Ik zie niet hoe dat soort middelen resistent zouden zijn tegen succesvolle proxy/MitM aanvallen. Als beide authenticatiefactoren via de MitM naar de bedoelde site worden gestuurd, kan die MitM daarna hetzelfde als jij kunt - omdat de site de MitM niet van jou kan onderscheiden (zie bijv. https://www.security.nl/posting/568113/MijnOverheid-phishingsite+maakte+ook+2-factorauthenticatie+buit). Alleen als er sprake is van twee volledig gescheiden kanalen voor elke factor (van 2FA), zijn grootschalige MitM aanvallen veel lastiger uit te voeren - omdat de aanvaller dan tegelijkertijd toegang zal moeten hebben tot beide kanalen.

Niet "eigenlijk" maar altijd; je bent er dan niet van afhankelijk of de betreffende site HSTS correct geïmplementeerd heeft, jij de bij die site horende HSTS gegevens in jouw browser hebt en ze niet zijn verlopen (zie https://www.security.nl/posting/564452/https+voor+leken). En ik raad af om elke keer te tikken: gebruik een favoriet/snelkoppeling (die met https:// begint). Dat voorkomt tikfouten en kost minder tijd (vooral omdat je, als je de URL elke keer intikt, deze ook elke keer met https:// moet laten beginnen).

Malware op jouw PC kan zo'n favoriet/snelkoppeling wijzigen (controleer dus altijd de domeinnaam in de URL balk zodra de versleutelde verbinding zonder foutmeldingen tot stand is gekomen). Maar als je malware op je PC hebt, is de kans groter dat je browser wordt aangepast (zodat er een "Man in the browser" onststaat - die mag wat jij mag). Met andere woorden, als je malware op je PC hebt, verlies je sowieso.

Volgens mij moeten we even het onderscheid maken tussen 1) het verkrijgen van een certificaat voor een phishing domein (zoals mijn.fakebank.nl) en 2) een geldig certificaat verkrijgen voor andermans domein (zoals mijn.ing.nl).

In het eerste geval lijkt het mij vanzelfsprekend dat daar eenvoudig een DV certificaat voor te krijgen is. Zelf denk ik dat een EV certificaat wat omslachtiger, maar niet onmogelijk is. In het tweede geval lijkt het verkrijgen van zowel een DV als EV certificaat erg lastig, je zult eerst de DNS records op de authoritative server moeten aanpassen. Een EV certificaat zal dat echter nog lastiger maken de extra controles.

Ik ben van mening dat het eerste scenario geen invloed zou moeten hebben op de veiligheid van jou eigen domein. Het zou je niks uit moeten maken of iemand anders kan aantonen dat hij beschikking heeft over zijn eigen domein, zelf met een EV certificaat. Het tweede scenario is gelijk het andere uiterste en wel groot probleem. De maatregelen die je hier tegen moet nemen zijn DNS records opschonen (subdomain takeover), toegang tot DNS records beperken (zie ook CISA emergency directive van afgelopen week) en regelmatig uitgegeven certificaten controleren via Certificate Transparancy. Maar als dat eenmaal het geval is lijkt mij dat er weinig meer te doen is tegen phishing...

Zoals ik beschreef gaat het over een positive indicatie. En hoe weet ik dat mijn.overheid.nl wel of geen EV certificaat heeft? Of Digid.nl ? Het is leuk dat mijn.ing.nl er een heeft, maar wat moet ik doen als ik geen EV certificaat zie? Dan maar niet inloggen? En wat als de ING besluit om geen EV certificaat meer te nemen maar op DV overstapt? Gaan ze dan iedereen per brief informeren om voortaan maar niet meer op EV certificaten te controleren? Er is voor gebruikers geen enkele manier om te weten of een website wel of geen EV certificaat hoort te hebben.

Beide zijn wel degelijk beschermt tegen de MitM zoals je het beschrijft omdat ze gebaseerd zijn op asymmetrische cryptografie. In het geval van smartcards komt er een handtekening op de TLS sessie te staan (op de client<>MiTM HTTPS connectie). Voor de MitM is het onmogelijk om deze handtekening te kopiëren en toe te passen om de eigen verbinding (op de MitM<>origin HTTPS connectie). In het geval van Webauthn staat er een handtekening op de "origin='mijn.fakebank.nl" zoals deze in de webbrowser te vinden is. De oorspronkelijke website controleert deze waarde, vergelijkt het met de echte URL waarop de site bereikbaar is, en accepteert of weigert dan de verbinding. Ook in dit geval is de MitM niet in staat om een handtekening aan te passen of te kopiëren omdat het geen toegang geeft tot het private sleutelmateriaal.

Inderdaad. Maar de Telegraaf wekt wel een andere indruk met:
Kennelijk zijn mensen die wel naar de URL kijken méér dan meest oplettend. Gelukkig zijn er tegenwoordig een heleboel mensen die ergens 200% voor gaan, het onmogelijke is gelukkig gewoon mogelijk tegenwoordig ;-).

Eens, prima.

Voor een cybercrimineel die snel wil cashen en wegwezen is dat m.i. geen realistische optie. Als ik me niet vergis schrijft het CAB forum haar leden voor dat zij geen EV certificaten mogen uitgeven voor lijkt-op namen. Anderzijds kan een EV-certificaat juist aangeven dat een site van een andere organisatie is.

Bijv. https://www.kadasterdata.nl/, een site die NIETS met het Kadaster van de NL overheid te maken heeft, zie ik een EV-certificaat waaruit je in een oogopslag ziet dat het om een B.V. gaat (en niet om een overheidswebsite).

Dat is m.i. véél lastiger, en niet realistisch voor cybercriminelen die snel willen werken, zich niet willen authenticeren en een hekel hebben geldstromen waaruit hun identiteit zou kunnen worden afgeleid. Met CSP's zie zich niets van hun primaire bestaansrecht aantrekken (en van de regels van het CAB forum) hoort het niet goed af te lopen, en dat browserfabrikanten het vertrouwen in prutsers opzeggen komt gelukkig gewoon voor.

Natuurlijk wel. Naar verluidt [1] had de overheid 100.000 Euro over voor de domeinnaam digi-d.nl, een site die door burgers wordt verward met digid.nl - met als gevolg dat de eigenaar van digi-d.nl vertouwelijke informatie ontvangt die niet voor hem bestemd is [2]. Kennelijk gaat dat zover dat criminelen die site proberen te hacken [3].

[1] https://tweakers.net/nieuws/77526/bedrijf-digi-d-vroeg-1-komma-4-miljoen-euro-om-naamsverwarring-te-voorkomen.html
[2] https://www.security.nl/posting/391217/Burgers%2Bsturen%2B40_000%2BDigiD-codes%2Bnaar%2BDigi-D_nl
[3] https://www.security.nl/posting/396418/Politie%2Barresteert%2Bman%2Bwegens%2Baanval%2Bop%2BDigi-D_nl

Feit is dat mensen in phishing trappen waarbij er "klinkt als" of "lijkt op" domeinnamen worden gebruikt, en dat organisaties op hersenloze wijze (in elk geval niet gehinderd door enige security awareness) domeinnamen registreren. Net zoals jij stelt dat het voor een gebruiker lastig is, zo niet onmogelijk, om vast te stellen of een certificaat van het type EV zou moeten zijn, hebben gebruikers geen idee welke domeinnamen van een organisatie zijn. Voorbeeld: als ik vakantie aan wil vragen log ik in op https://connect.visma.com/ waarna ik op een *.visma.net site uitkom. Stel morgen is dat ineens *.visma.biz of *.vizma.net, moet ik dat dan vertrouwen of niet? Ik kan dit soort idioterie niet uitleggen aan mensen die mij vragen waar ze op moeten letten.

Daar heb ik wel ideeën over, maar deze bijdrage is al veel te lang.

Zoals ik aangaf, zouden er bij mensen die wel op details letten, de alarmbellen moeten afgaan als mijn.ing.nl ineens geen EV certificaat meer heeft.

M.i. zou HSTS moeten worden uitgebreid met het minimaal vereiste authenticiteitsniveau van een website (om te beginnnen met het soort certificaat: DV, OV of EV). Als een website aangeeft het komende jaar een EV certificaat te zullen gebruiken, moet de browser de https verbinding weigeren als er, binnen 1 jaar na het laatste bezoek waarbij het voorgaande is aangekondigd, een DV of OV certificaat wordt aangeboden.

Een mechanisme "in dezelfde hoek" is overigens CAA (https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization), maar dat is weer afhankelijk van de betrouwbaarheid van DNS: je bent dus kansloos (behoudens nitwit cybercriminelen) als aanvallers jouw DNS records kunnen wijzigen.

Ah, ik had mij niet gerealiseerd dat dit zou kunnen. Weer wat geleerd, dank voor jouw bijdrage!