RIVM en de Rijksoverheid hadden authenticatie tegen e-mailspoofing niet op orde

Het RIVM en de Rijksoverheid hadden bepaalde authenticatie-instellingen voor e-mail niet goed. Daardoor zouden nepberichten uit naam van deze organisaties worden doorgelaten door derde partijen en in de postvakken van gebruikers terechtkomen.

E-mailspoofing bleek mogelijk met de domeinen rijksoverheid.nl en rivm.nl, zonder dat spamfilters van grote e-maildiensten deze nepberichten tegenhielden. Dat meldt RTL Z. Criminelen zouden zo phishingberichten kunnen sturen die afkomstig lijken te zijn van het RIVM of de Rijksoverheid, waardoor nietsvermoedende gebruikers eerder geneigd zouden zijn de kwaadaardige mails te openen.

Op Twitter licht RTL-journalist Daniel Verlaan toe dat het probleem lag bij onjuiste instellingen van het dmarc-authenticatieprotocol voor e-mail. Met dit protocol voor Domain-based Message Authentication, Reporting and Conformance kunnen ontvangende e-mailservers berichten controleren op basis van een dns-entry van de domeinhouder. Na authenticatie leveren de e-maildiensten het bericht af. Als de e-mail de check niet doorstaat, volgt quarantaine, afwijzing of, afhankelijk van de instelling, alsnog levering.

Dmarc is een extensie op spf en dkim. Beide zijn authenticatiemethoden waarmee een ontvanger van een e-mail kan nagaan of een bericht van het domein van de verzender inderdaad daarvandaan mocht worden verzonden. Op Internet.nl van het Platform Internetstandaarden kunnen organisaties controleren of hun maildienst de juiste instellingen heeft. Bij het Platform Internetstandaarden zijn onder andere Internet Society Nederland, NLNet, RIPE NCC en SIDN betrokken, maar ook het ministerie van Economische Zaken en Klimaat.

Alle overheden moeten vanaf eind 2019 strikte instellingen voor dmarc en spf hebben geïmplementeerd, volgens de streefbeeldafspraak uit 2018 van het Overheidsbrede Beleidsoverleg Digitale Overheid op advies van Forum Standaardisatie.

Reacties (32)

[daandv98]

Hetzelfde security issue dat de WHO heeft. Vox heeft hier gisteren een leuke aflevering van gepubliceerd.

[Reactie gewijzigd door daandv98 op 23 juli 2024 21:22]

[kwinvdv]

Als ik tweaker.net in diezelfde website gooi (valimail.com) zie ik dat tweakers ook niet beschermd is tegen spoofing. Ik ben een leek op het gebied van spoofing, dus ik weet 100% zeker of dit correct is.

[Lord Anubis]

Hoe zit dat met b.v iCloud.com adressen? Heeft Apple ze dan ook niet in orde? Kan je ze wel in orde brengen?

[willyb]

iCloud heeft dat gewoon op orde https://internet.nl/mail/icloud.com/342716/

Op https://internet.nl/halloffame/mail/ staan alle domeinen die getest zijn en waar dat en al die andere testen ook op orde waren.

[e.dewaal]

Mijn ervaring met dit protocol is dat veel mailproviders hier geen rekening mee houden. Daarnaast is het heel lastig om te verifiëren welke werknemers de correcte instellingen in hun mailclient gebruiken. Als werknemers bijv. nog SMTP poort 25 ingesteld hebben, wordt met enige regelmaat de mailserver van de provider nog gebruikt.

Daarnaast maakt één van de organisaties waar ik het beheer over heb gebruik van Google Apps. Echter heeft zelfs een grote organisatie als Google zijn protocollen niet op orde, althans, bij mij werkt het niet... Als bijvoorbeeld mails vanuit de calendar gestuurd worden (uitnodiging of afwijzing afspraak), wordt dit gedaan vanaf aparte google servers waardoor dmarc controle niet slaagt.

Daarnaast, compleet legitieme e-mails waarvan ik in de broncode/headers kan zien dat dmarc controle slaagt, alsmede spf en dkim, beland alsnog in de spamfolder. Waar sommige mails van mijn domein, waar controle niet correct is om wat voor reden dan ook, beland niet in de spamfolder. Of ik snap de werking van het protocol niet, of er wordt niet naar gehandeld.

[LeonM]

> Mijn ervaring met dit protocol is dat veel mailproviders hier geen rekening mee houden.

Vrijwel alle grote email providers hebben DMARC verificatie geïmplementeerd, en dat nummer neemt nog steeds toe. Met on-premise mail services is het vaak een stuk treuriger gesteld, maar dat ligt buiten je macht als verstuurder.

> Daarnaast is het heel lastig om te verifiëren welke werknemers de correcte instellingen in hun mailclient gebruiken.

Dat is niet zo lastig, met DMARC monitoring zie je dit snel genoeg. De mailclient staat overigens los van SPF, DKIM en DMARC. SPF en DMARC gebeuren op domein niveau. DKIM wordt door de mailserver toegevoegd. Het poortnummer alsmede het gebruik (of gebrek) van TLS heeft niks te maken met DMARC. Als de mailclient de verkeerde SMTP server gebruikt om email te versturen, dan is dat een security issue, en zou het *juist* de bedoeling moeten zijn dat deze emails niet aankomen. Althans, wel voor organisaties zoals RIVM en de rijksoverheid.

> Daarnaast, compleet legitieme e-mails waarvan ik in de broncode/headers kan zien dat dmarc controle slaagt, alsmede spf en dkim, beland alsnog in de spamfolder

DMARC is een preventiemaatregel tegen fraude, geen anti-spam. Een volledige alignment op DMARC geeft geen garantie dat de email door een spamfilter komt, want als dat zo zou zijn dan zouden spammers vrij spel hebben.
Het werkt juist andersom: met DMARC verhoog de kans dat fraudeloze email _niet_ wordt geaccepteerd door de ontvanger.

Disclaimer: ik ben de oprichter van Mailhardener, een e-mail hardening platform.

[mgizmo]

"Als werknemers bijv. nog SMTP poort 25 ingesteld hebben, wordt met enige regelmaat de mailserver van de provider nog gebruikt."

Ja dan vraag je er om, als werkgever hoor je het te faciliteren dat mails via "eigen" mailservers gaan. Niet dat gebruikers even een pop3&smtp config gaan doen in een mailclient.

[e.dewaal]

Dat klopt voor bedrijven. Ik heb het nu over een ANBI waarbij ik geen controle heb over de computers van de gebruikers waarop ze dit instellen. Normaal gesproken levert dit geen problemen op omdat het automatisch goed komt te staan in de meestgebruikte e-mailclients. Ik heb echter vandeweek nog iemand geholpen die blijkbaar nog met Windows Live Mail werkte waarbij inderdaad de smtp opgegeven stond op poort 25 en de mail door de provider werd onderschept en verzonden via de providers e-mail. Ik heb ook graag dat ze gebruik maken van de veilige eigen mailservers (van Google in dit geval).
Gelukkig gaat Google het ophalen van mail middels "onveilge protocollen" (niet oauth) weren de komende periode, helaas is de timeframe gecanceld ivm COVID-19... (source).

[joker1977]

Je snapt het protocol waarschijnlijk wel, maar het probleem zit dieper: Omdat zaken als DMARC,DKIM en SPF afhankelijk zijn van de verzender en spam juist vervelend is voor de ontvanger zijn er allerlei truukjes bedacht hoe je spam kan herkennen.

Mede daardoor worden er allerlei analyses losgelaten op e-mails om tot een inschatting te komen of het spam is. Daarin scoren DMARC, DKIM en SPF positief in - maar ze zijn niet alles beslissend, want dan gingen spammers gewoon een spammer met DMARC optuigen (zo moeilijk is dat niet, mits je een domein hebt waar je controle hebt over de DNS-records).

[Visje!]

Vreemd... Ik beheer drie google-apps domeinen en ik ervaar die problemen niet. Alles dat via de Google servers verstuurd wordt is 100% dmarc-compliant. Wel alle spf- en dkim-instellingen goed ingesteld?
Zie: https://support.google.com/a/answer/2466580?hl=nl

[Blokker_1999]

spam filters kijken natuurlijk naar meer dan alleen maar spf/dkim/dmarc om te bepalen of iets spam is of niet. Dat mails waarbij dit in orde is dus alsnog in je spam folder belanden betekend dat ze ofwel kenmerken van spam vertonen, ofwel dat je scores slecht zijn afgesteld.

En mailproviders horen bij een fail ook niet zomaar de mail als spam te markeren of nog erger, gewoon tegen te houden. Ik zie liever een softfail zoals vele organisaties doen. Daarbij geven zij gewoon een banner boven de email in de trend van: opgelet, deze mail bevat technische indicatoren van fraude.

[biggydeen2]

Waarom niet? Als een valide bedrijf een SPF record heeft en jij krijgt een mail van een andere server welke niet in het SPF record staat is het gewoon spam/phising. Waarom zou je die mail in je mailbox willen hebben?

[biggydeen2]

Spf en dkim is niet gelijk aan spam. In het SPF record bepaalt het domein vanaf welke server de mail verzonden mag worden en dkim zorgt er voor dat als de mail eenmaal verstuurd is niet weer gewijzigd wordt (de ontvanger kan dit dan detecteren) Maar beiden zijn nutteloos als er door de ontvangende partij niet op wordt ge checked. Je kunt dus prima spam versturen met valide spf en dkim records. Maar de definitie van spam is nogal uitgebreid

[Reactie gewijzigd door biggydeen2 op 23 juli 2024 21:22]

[Pumbaa82]

Maar kan iemand concreet uitleggen WAT er dan niet correct was ??

Er wordt gerept over 'verkeerde configuratie' en de Termen SPF, DKIM en DMARC komen voorbij...
Maar nergens het wat en waarom..
Voor mij is dit meer nu sensatie zoeken op een moment dat RIVM en rijksoverheid natuurlijk 'populair' zijn.

Verwacht dat er wel veel meer instanties niet hun zaakjes volledig dicht hebben.
Fatsoenlijk email versturen is tegenwoordig ook meer raket wetenschap dan raket wetenschap was.

Kijk SPF niet goed... prima die kan ik rijmen, dat je mail niet laat versturen via een niet door je DNS records toegestane mail server. Dan kan je spoofen.

Maar een DMARC Policy die bv. op reporting zou staan ipv quarantaine of reject.
DMARC voelt als de kers op de taart, om het helemaal goed proberen te krijgen en de eerdere technieken SPF en DKIM te valideren.

Maar hier lijkt het nu alsof door de DMARC configuratie het niet goed was.
Volgens mij zou de SPF al de spoofing moeten voorkomen.
Zie ik dit nu zo verkeerd ?

[LeonM]

Dit zie je niet verkeerd.

Het was mogelijk om email te sturen met naam van de overheid, welke aankwam bij de ontvanger.

De 'verkeerde configuratie' komt er dus op neer dat:
- Er waarschijnlijk geen 'quarantine' of 'reject' DMARC policy werdt gebruikt
- Er mogelijk een permissive SPF prefix was gebruikt op de 'all' modifier

Nou vind ik 'verkeerde configuratie' een beetje misleidend, het is voor grote organisaties meestal niet dat men 'perongeluk' de verkeerde settings ofzo gebruikt. Er zijn vaak diverse organisatorische, technische en politieke factoren betrokken bij de implementatie van een strikte email omgeving (met als uiteindelijk resultaat een 'reject' DMARC policy).

Neemt niet weg dat overheidsinstanties al enige tijd verplicht zijn om deze zaken op orde te hebben, en dat hebben ze dus niet gered. Het artikel was daarom in mijn ogen wel terecht, maar wellicht wel wat laaghangend fruit qua sensatie factor.

[Anoniem: 426269]

Of het RIVM en de Rijksoverheid DMARC of zelfs SPF niet op orde had, maak ik niet op uit dit artikel.

Pas ook een klant wiens mailtjes van xsall niet aankwamen bij mailtjes gestuurd vanaf zijn website. Dat was ook niet vreemd, want Xs4all doet niets met SPF, dat raden ze af. Lastig ook in de SPF TXT record zetten dan, als er niets bekend is. Vreemd dat zij die policy aanhouden, maarja, het wordt toch KPN eerdaags.

https://twitter.com/dmsto...91933525355003904?lang=nl

https://www.xs4all.nl/ser...atie/abonnement-wijzigen/ (zoek naar SPF en krijg dit):
Sender Policy Framework/Sender Permitted From, of kortweg SPF, is ontworpen om het vervalsen/misbruiken van (afzender)adressen bij e-mail tegen te gaan. Spammers verzenden bijvoorbeeld nog steeds regelmatig e-mail met een afzenderadres wat van een nietsvermoedende gebruiker is.

Met een SPF-record is het mogelijk om aan te geven welke mailservers e-mails mogen versturen voor een bepaald domein. Een mailserver met SPF-ondersteuning zal bij elke inkomende e-mail controleren of het domein van de afzender een SPF-record hebt. En als dat het geval is, controleren of de versturende mailserver wel in het SPF-record aanwezig is. Wanneer dat niet zo is, wordt deze e-mail tegengehouden.

In de DNS voor een domein kunnen TXT records opgenomen worden. Door bepaalde informatie in een TXT record te plaatsen voor SPF, wordt opgegeven welke mailservers gebruikt worden voor het verzenden van e-mail. Dit kan op basis van IP adres of reeks en MX records. De ontvangende partij (als die SPF gebruikt) kan dan de SPF records opvragen en kijken of de verzendende mailserver genoemd staat.

In de strijd tegen spam is het gebruik van SPF helaas niet waterdicht. XS4ALL raadt het gebruik niet aan. We staan het echter niet in de weg als u het toch graag gebruikt. Voor het aanvragen van SPF TXT-records gebruikt u dit formulier

[Welleweerd]

Wacht even, de overheid heeft zijn digitale briefpapier voor iedereen beschikbaar met de correct afzender. Mails van de overheid waren dus mogelijk onjuist de voorgaande jaren? Hoe kan dit?

[Zebby]

Ik weet niet goed wat je bedoelt? Omdat men geen goede DMARC policy heeft kunnen bedrijven "namens" de RIVM mail verzenden en wordt deze geaccepteerd door de ontvangende mailserver.
Nu zal je mailserver controleren of SPF en DKIM correct zijn geconfigureerd (dus - RIVM heeft sleutels uitgewisseld met de zender, deze staan in de DNS). Zo niet zal de mail niet in je mailbox terecht komen, maar in quarantaine gezet worden.
Dit is soms nog leuk, want SPF policies worden nog wel eens door een zender beheerd om ook bounce afhandeling te kunnen realiseren, maar als een mail geforward wordt dan komt deze niet mee en slaagt dus de DMARC check niet waardoor de mail niet aankomt

[Reactie gewijzigd door Zebby op 23 juli 2024 21:22]

[AP3X]

Kleine aanvulling... DMARC checkt of SPF of DKIM correct zijn. Dus niet SPF en DKIM

[LeonM]

Nog een kleine aanvulling:

DMARC checkt of de SPF of DKIM aligned is.

In geval van SPF betekend alignment dat de RFC5321.MailFrom (envelope address) en RFC5322.From (afzender) hetzelfde (sub)domain gebruiken.

In geval van DKIM betekend alignment dat de DKIM public key (het DNS record) gehost moet zijn onder hetzelfde (sub) domain als in het RFC5322.From adres.

Of subdomains wel/niet toegestaan zijn kan je instellen in het DMARC record.

[freddieleeman]

DMARC checkt SPF EN DKIM, als beide niet 'aligned' zijn faalt DMARC. Als één van beide een pass genereert zal DMARC ook een 'pass' geven.

[Blokker_1999]

Wat er met de mail gebeurd is volledig afhankelijk van wat de ontvangende server ermee wenst te doen. Met spf kan je nog opgeven of je een hard fail (mail verwijderen) of een soft fail (mail behandellen als junk) wenst, maar dat is ook alleen maar een advies, niet meer dan dat. Zelfs als je als beheerder van het domein alles goed hebt ingesteld heb je dus geen enkele houvast over of zulke vaose mails gaan aankomen of niet.

En aan de ontvangende kant ben ik zelf iemand die mailservers zo instelt dat een hard fail toch wordt afgehandeld op dezelfde manier als een softfail. Mijn spamfilter mag van mij geen enkele mail zelf tegenhouden, alles moet naar de mailbox, zij het in de spamfolder.

[Zebby]

Het was een poging tot een simpele uitleg van de meest toegepaste vorm, uiteraard zijn er vele mogelijkheden en uitzonderingen. Persoonlijk hanteer ik hetzelfde, zakelijk volgen we de wensen op van de policy.

[fastedje]

Mails met virussen erin worden over het algemeen wel stilzwijgend in de quaranteen gezet, eventueel met een notificatiemail naar de oorspronkelijke ontvanger. Dat werkt in ieder geval zo met amavis/clamav/postfix.

[Welleweerd]

Vandaar dat in geforwade mailtjes geen inhoud zit

[Koffie]

Ik heb alles gewoon bij naardekloot.nl gehost, nooit last van dergelijke klote mailtjes

[e.dewaal]

1 april is al geweest hoor...

[tormentor1985]

Ik vind dit bericht wel lichtelijk overdreven. Het instellen van spf en dkim icm met dmarc om je regels te publiceren zal namelijk niet voorkomen dat iemand uit naam van deze instanties mail kan versturen. Als ik immers een mail dienst af neem bij een derde partij die de regels in dmarc of spf niet controleert en keuzes daarin afdwingt dan is het nog steeds prima mogelijk om mail te sturen met de afzender rivm.nl

Nou hebben grote partijen als Outlook of Google dit wel in orde maar het is vrij naief om te denken dat spoofing onmogelijk is. E-mail ansich is nog steeds een lek systeem met wat trucjes veiliger gemaakt kan worden. Echter als iemand die trucjes niet toepast is het nog steeds makkelijk uit naam van iemand anders te sturen. Net zo simpel als een brief met een valse afzender op de post doen.