Door Anoniem: Een bank die niet tenmiste spf zou gebruiken voldoet niet aan de laagste standaarden. Bunq heeft spf en DKIM aan staan. De TXT record is "v=spf1 -all". Hard fail. Dat is goed, zelfs beter dan menige andere bank, die lange/grote reeksen van andere verzenders toestaan, dat een supply chain attack niet uitsluit.
Da's leuk, maar veel phishingberichten bereiken je als SMS'je. Vaak kun je dan niet eens het "zendende telefoonnummer" achterhalen (en als dat wel mogelijk is, kan het vervalst zijn).
Daarnaast,
https://mxtoolbox.com/SuperTool.aspx?action=spf%3abunq.com&run=toolpage: de halve wereld.
En zonder DMARC (wat zowel voor
bunq.nl,
bunq.me {1} en
bunq.com -zo te zien correct- geconfigureerd is) heb je sowieso niets aan SPF en DKIM om impersonatie van de afzender te voorkómen {2}.
Maar ook
met DMARC is impersonatie simpel; als de SMTP e-mail afzender bijvoorbeeld luidt:
no-reply@mijn-bunq-omgeving,com {3}
en DMARC klopt {4}, en de link in de e-mail begint met:
https://mijn-bunq-omgeving,com/- waarom zouden mensen dáár dan
níet in trappen?
{3} Die domeinnaam komt uit de pagina met de link die ik in mijn lange post bovenaan vergeten was te noemen:
https://www.virustotal.com/gui/ip-address/91.215.85.79/relations (je moet omdertussen wel meerdere keren op de ••• drukken om die domeinnaam te zien te krijgen). In de hier getoonde domeinnaam heb ik de punt door een komma vervangen (om te voorkómen dat deze als geldig e-mailadres en webadres worden herkend).
{4} D.w.z. dat aan minstens één van de volgende twee voorwaarden wordt voldaan:
a) De SPF-validatie is geslaagd én de header-From domeinnaam komt voldoende overeen met de envelope-From domeinnaam;
b) De DKIM-validatie is geslaagd én de header-From domeinnaam komt voldoende overeen met de in de DKIM-header opgenomen domeinnaam.
Dat nog afgezien van het feit dat de meeste mobiele e-mail apps de SMTP-afzender (naam@example.com) überhaupt niet tonen. Ten slotte (v.w.b. de e-mailafzender) maken ook banken gebruik van third parties die hun mailings verzorgen, en de worden regelmatig gehacked. Een e-mail met een domeinnaam zoals
mailings.bunq.nl in een SMTP-afzenderadres kan nog steeds een phishingbericht zijn.
Wat ook niet helpt is dat ik, in elk geval in de Apple mail app voor iPadOS, een HTML phishing mail gezien heb waarin de domeinnaam van de website
niet getoond werd toen ik langer op de knop drukte - waar duidelijk
wél een link "onder" zat (wat ook bijv. een "bit.ly" link zou zijn, en dan weet je nog niks). Want toen ik erop drukte opende wel degelijk een phishingsite.
Het gedonder met SPF, DKIM, DMARCDMARC verzorgt
authenticatie van een e-mailafzenderdomein, maar daar heb je bar weinig aan omdat:
• Veel beheerders denken dat, als je "bewijst" dat een email van jouw domein afkomstig is (
authenticatie dus), dit "het probleem" (ontvangers die, via een "
zou-kunnen-zijn-van domeinnaam, in
impersonatie trappen), zou oplossen;
• Niet zelden voor een e-mailafzender een andere domeinnaam dan voor de website van de organisatie wordt gebruikt (of afwijkende TLD's, zoals
.net of
.com i.p.v.
.nl, waardoor eindgebruikers niet weten waarom bijvoorbeeld
.top of
.me wél foute boel zou zijn);
• Veel (vooral mobiele) e-mail apps het SMTP-afzenderadres (met afzenderdomein) überhaupt niet tonen;
• Forwarding door SPF onmogelijk wordt gemaakt en er vervelende workarounds nodig zijn (die
derde partijen moeten implementeren) om dat probleem "op te lossen";
• SPF t.g.v. te veel recursieve "includes" onverwacht kan falen;
• Een DKIM signature niets zegt als deze niet door de bedoelde server is gezet;
• Veel mailinglist servers stukjes van e-mails wijzigen waardoor vervolgens DKIM-validatie faalt;
• Door bovenstaand "gedoe" het voor DMARC acceptabel is als ofwel SPF-validatie, ofwel DKIM-validatie faalt - waardoor het DMARC protocol wordt verzwakt (en, aan afzenderzijde, SPF in combinatie met DMARC vaak met "
~all" wordt geconfigureerd, waardoor een ontvangende mailserver, die DMARC niet checkt, zal denken dat een SPF-fail niet boeit);
• Er tussen mailserverbeheerders geen consensus bestaat over de juiste instellingen en iedereen zijn eigen "ding" doet;
• DNS zonder DNSSEC gangbaar is en onbetrouwbaarder is dan mét;
• E-mailontvangers geen idee hebben wat er achter de schermen gebeurt, noch op de hoogte worden gehouden van wijzigingen in configuraties (die kunnen plaatsvinden als er bijv. te veel verzonden of juist ontvangen mail wordt geblokkeerd);
• Er nog steeds idioten zijn die stellen dat SPF, DKIM en DMARC antispammaatregelen zijn;
• Er nog steeds idioten zijn die stellen dat als je "zeker weet hoe het afzenderdomeim luidt", dit iets zegt over de
betrouwbaarheid van de afzender (alsof cybercriminelen niet zouden weten hoe je die protocollen inzet);
• SPF, DKIM en DMARC complexe protocollen zijn die vaak onvoldoende worden begrepen, hetgeen enerzijds de kans op configuratiefouten vergroot (zowel aan de zendende als de ontvangende zijde). Anderszijds zijn beheerders, die er veel tijd in hebben gestopt om te begrijpen hoe het allemaal werkt en hoe je e.e.a. configureert, vaak
niet bereid om toe te geven dat phishing nauwelijks of niet voorkómen wordt, en je ze
vooral moet implementeren omdat anders
andere "gelovigen" (waaronder Big Tech) mails vanuit jouw domein blokkeren;
• Niets helpt indien afzenders gehacked worden en cybercriminelen namens hen phishingmails kunnen verzenden.
Kortom:1) Zowel bij SMS als bij e-mail is impersonatie eenvoudig en, voor de meeste ontvangers, zeer effectief. Als je SMS, en vooral e-mail, eenvoudig betrouwbaar zou kunnen maken, was dat allang gebeurd.
2)
Indien je op een link klikt, check
altijd of de uiteindelijke verbinding (zonder waarschuwingen) van
https:// gebruikmaakt (ook al is die tekst "
https://"
zelf niet te zien in de adresbalk)
én dat je zeker weet dat de volledige domeinnaam, getoond in de adresbalk van jouw browser, van de bedoelde organisatie is (vertrouw
niets in de webpagina totdat je de domeinnaam gecheckt hebt).