Phishing en spoofing in e-mail verhinderen: SPF, DKIM en DMARC

Als een phishing-mail goed gemaakt is, maakt hij goede kans langs filters van bijvoorbeeld SpamAssassin te komen. SPF, DKIM en DMARC zijn tools die kunnen verhinderen dat een mailserver dergelijke mails überhaupt accepteert. Op die manier kunnen phishing en spoofing in e-mail worden bestreden.

Spammers, phishers en malware-verzenders vervalsen het mailadres van de afzender omdat ze gebruik willen maken van de goede naam of autoriteit van een bepaalde afzender om vertrouwen te wekken. Zo kunnen ze bijvoorbeeld toegang krijgen tot de infrastructuur van een bedrijf – maar liever nog je bankgegevens.

Daarom moet een ontvangende mailserver bij het aannemen van een mail controleren of de afzender daadwerkelijk is wie hij claimt te zijn. Een doorslaggevende bijdrage daarvoor komt van de technieken Sender Policy Framework (SPF) en Domain Keys Identified Mail (DKIM). Domain-based Message Authentication, Reporting and Conformance (DMARC) bepaalt hoe een ontvangende server de met SPF en DKIM gecontroleerde mails moet behandelen.

Alle drie de methoden richten zich op het afzenderdomein. Daarnaast zijn er andere methoden, waaronder DANE (DNS-based Authentication of Named Entities), die de TLS-versleuteling voor het ontvangerdomein controleren. Die helpen tegen man-in-the-middle-aanvallen en vallen daarom buiten het kader van dit artikel.

Met SPF kan een ontvanger controleren of de voor een domein verantwoordelijke mailserver een mail verstuurd heeft. DKIM geeft uitsluitsel over de vraag of een bericht niet vervalst is en controleert met een tweede methode of een mail afstamt van het in de header staande afzenderdomein. DMARC controleert de aangegeven afzender in de mailheader en stelt aan de hand van de SPF- en DKIM-controles vast hoe de ontvangers mails authenticeren en met berichten om moeten gaan die zich niet aan de richtlijnen van de afzender houden.

De ontvangende mailserver wordt daardoor meer handelingsbekwaam. Hij beslist niet zelf, maar gaat uit van de gegevens van het afzenderdomein, waarvan hij aan de hand van de SPF-, DKIM- en DMARC-informatie aanneemt dat die authentiek en te vertrouwen is. Veel afzenderdomeinen gebruiken alle drie de methoden op dit moment al om hun mailverkeer, hun naam en niet in de laatste plaats hun merk te beschermen.

Maar alle drie de technieken hebben hun grenzen. Ze zijn niet onbeperkt te gebruiken en sommige mogelijkheden mogen door bepaalde wetgevingen nog niet gebruikt worden.

Sender Policy Framework
Met SPF kan een ontvanger op basis van het IP-adres van de afzender en het afzenderdomein controleren of een mail is verstuurd door de voor dat domein verantwoordelijke mailserver.

Het Sender Policy Framework gaat uit van een simpele aanname: alle e-mails van een afzenderdomein worden zonder uitzondering door een daarvoor geautoriseerde mailserver verstuurd. De relatie tussen het afzenderdomein en de mailserver wordt door een systeem­beheerder aangegeven bij een DNS-server die verantwoordelijk is voor het afzenderdomein (in een TXT-record met het IP-adres van de afzenderserver). Of en welke SPF-items een domein levert, is bijvoorbeeld te zien bij de online service van mxtoolbox.com. Om het domein ct.nl te controleren, typ je ‘spf:ct.nl’ daar in het zoekveld in.

De server van een ontvanger leest bij elke verbindingsopbouw de door de desbetreffende afzender­server aangegeven domeingegevens uit. Met het commando ‘MAIL FROM’ levert hij het afzenderadres en met het commando ‘HELO’ de domeinnaam. Daarmee kan de ontvanger controleren of die gegevens overeenkomen met de SPF-gegevens in het Domain Name System. Mailservers waar geen SPF-gegevens van bekend zijn, zijn niet geautoriseerd om in naam van het aangegeven domein berichten te versturen. Daarom bepaalt SPF hoe er gehandeld moet worden bij een onverwachte afzender (bijvoorbeeld fail, softfail, neutral, pass).

Tot zover de theorie. In de praktijk worden uitzonderingen vaak regel en vanuit SPF-oogpunt moet je er rekening mee houden dat legitieme e-mails niet alleen via geautoriseerde mailsystemen in omloop komen. Als een server mails bijvoorbeeld indirect via een niet bij het domein horende mailinglijst verstuurt, mislukt de SPF-controle. Hetzelfde gebeurt bij bevestigingsmails van allerlei shopsystemen.

De conceptfout van de SPF-methode zit in de aanname dat berichten uitsluitend door bepaalde mail­systemen verstuurd worden. Een ontvangende mailserver, die legitieme berichten door een mislukte SPF-controle verwerpt, lijkt daar correct mee te handelen – maar de geadresseerden krijgen hun bericht niet en de postmasters van de afzender- en de ontvangerssystemen moeten allerlei eigenlijk onjuiste acties uitvoeren om de oorzaak te kunnen verhelpen.

SPF wordt door veel critici dan ook gezien als ‘broken by design’ (zie bijvoorbeeld ook deze discussie). Het is zeker wel bruikbaar – maar niet in alle gevallen. Een echtheidscontrole van het afzendersysteem krijg je met SPF alleen als het afzenderdomein bovendien een strikte DMARC-richtlijn heeft vastgesteld en de ontvanger die gebruikt voor het valideren.

Bij de methode Domain Keys Identified Mail berekent de versturende server twee checksums – een voor bepaalde delen van de header en een voor de body van de mail (SHA1- of liever SHA256-hashwaarden). Die onder­tekent hij cryptografisch met RSA en zet dat in de mailheader. Die ondertekening voorkomt dat mail­vervalsers de checksums achteraf aanpassen. De ontvangende mailserver berekent de checksums zelf en vergelijkt zijn resultaten met de waarden in de header. Als die overeenkomen, dan is de mail origineel en wordt hij toegelaten.

Als een bericht na het aanbrengen van de ondertekening verandert, komen de checksums niet overeen en wordt de manipulatie herkend. Daarbij is geen onderscheid te maken tussen of er bijvoorbeeld schadelijke code toegevoegd is of dat alleen maar het onderwerp veranderd is. In alle gevallen gaat de ontvangende mailserver er vanuit dat het bericht gecompromitteerd is en niet te vertrouwen. Maar ook DKIM is te manipuleren.

Om een ondertekening te kunnen valideren, heeft een ontvangende mailserver een deel van de open­bare RSA-key van het vermeende afzenderdomein nodig. Die haalt hij wederom uit de DNS-gegevens. Als die stap mislukt, dan kan hij met DKIM ook niet controleren of het afzenderdomein authentiek is. Als dat wel lukt, maar de berekening niet tot hetzelfde resultaat komt, geldt het bericht wederom als gecompromitteerd. In beide gevallen bepalen lokale richtlijnen hoe de ontvangende servers met dergelijke mails moeten omgaan.

Domain Keys Identified E-Mail
DKIM geeft met hashwaarden uitsluitsel of een bericht na het versturen is gemanipuleerd of dat het daadwerkelijk van het afzenderdomein komt.

Problemen en oplossingen

In het begin had DKIM er mee te kampen dat sommige ontvangstsystemen de in DNS achtergelaten sleutels niet konden krijgen. De oorzaak daarvan is dat sommige firewalls en gateways niet goed kunnen omgaan met bepaalde DNS-pakketten.

Het oorspronkelijke DNS-protocol gebruikt normaal gesproken de snelle levering via UDP-pakketten. Dat werkt zonder problemen, als deze tenminste korter zijn dan 512 bytes. Met de DKIM-sleutels wordt een DNS-pakket echter langer dan 512 bytes. Een DNS-­server kan dan overschakelen op twee verschillende manieren: het leveren van de DNS-gegevens via TCP-pakketten of alsnog via UDP, maar dan met de uitbreiding EDNS0. Beide manieren kunnen mislukken. TCP kan bijvoorbeeld aan de kant van de ontvanger geblokkeerd worden door zijn firewall. TCP wordt echter voor meer ingezet, zodat je dat sowieso wel zou willen vermijden.

Een betere manier, omdat het sneller is, is met de uitbreiding EDNS0 (RFC 6891). Daarmee mogen via UDP verstuurde DNS-reply’s tot 4096 bytes lang zijn. De server ziet in de header dat EDNS0 gebruikt wordt. Maar sommige firewalls kunnen niet overweg met EDNS0, hoewel die uitbreiding inmiddels al ettelijke jaren oud is. Mede daardoor hebben de makers van belangrijke DNS-resolvers zich tegen verouderde servers en netwerkapparaten gekeerd (DNS flag day).

Ontvangende mailservers die achter dergelijke verouderde netwerkonderdelen zitten, krijgen het opgevraagde sleutelmateriaal dus niet. Dan mislukt het valideren van legitieme berichten alleen maar doordat het ontvangende systeem afgesneden is van het benodigde sleutelmateriaal.

Welke uitwerking dat heeft op het verdere transport van een bericht hing in de begindagen van DKIM af van hoe de systeembeheerder zijn mailserver had geconfigureerd. Inmiddels komen dergelijke fouten nog amper voor en houden systeembeheerders wel rekening met DNS-pakketten met een grotere lengte.

Dan zijn er nog de situaties waarbij een DKIM-­ondertekening ongeldig werd omdat een bericht onderweg legitiem veranderd werd. Een ontvangende mailserver kan dat verschil echter niet herkennen, maar alleen vaststellen dat de checksums niet overeenkomen.

Dat gebeurt bijvoorbeeld bij berichten die met DKIM-ondertekening naar een mailinglijst worden gestuurd. De mailinglijstsoftware voegt normaal gesproken de naam van de mailingslijst aan het begin van de onderwerpregel toe en andere informatie die met de mailinglijst te maken heeft aan het einde van het bericht. Daardoor weten de abonnees waar de mail vandaan komt.

Maar beide veranderen het bericht, en dan kloppen de checksums van de ondertekeningen dus niet meer. In principe zou de mailinglijstsoftware een eigen ondertekening kunnen toevoegen, maar dan horen het domein en de ondertekening niet meer bij elkaar. Alleen al daarom voorziet de DKIM-specificatie daar niet in. In plaats daarvan zou je voor subdomeinen een afzonderlijke ondertekening voor dienstverleners kunnen vrijgeven.

Desalniettemin kun je mailinglijsten zodanig gebruiken dat de DKIM-ondertekeningen geldig blijven. De methodes daarvoor worden echter ook enkele jaren na de invoering nog amper gebruikt, want mailinglijstabonnees zijn erg gehecht aan hun gewoonten. Veel mensen willen bijvoorbeeld per se de naam van de mailinglijst in de onderwerpregel van het bericht hebben staan. Dat vergemakkelijkt het zoeken en filteren en sorteren naar verschillende mappen. Door het veranderen van de onderwerpregel klopt de DKIM-checksum in de header van de mail echter niet meer.

Onder de naam Authenticated Received Chain (ARC) bestaat een techniek die kan filteren zonder de onderwerpregel te hoeven veranderen. Mailinglijst­bijdragen zijn namelijk ook aan de hand van de List-ID-header te herkennen en filteren. ARC bevindt zich na twee jaar ontwikkeling echter nog steeds in de kinderschoenen.

Domain-based Message Authentication
Met DMARC stelt een afzenderdomein onder meer vast hoe een ontvanger moet reageren als hij mail krijgt die niet voldoet aan SPF- of DKIM-controles.

De methode Domain-based Message Authentication, Reporting and Conformance werd bedacht om phishing tegen te gaan. De geestelijk vaders, waar ook PayPal bij hoort, deden dat meer uit noodzaak. Aanvallers verstuurden vanuit hun naam berichten naar legio mailadressen met daarin vooral het verzoek om in te loggen. Als een ontvanger in een dergelijke mail op de ingebedde link klikte, belandde hij schijnbaar op een PayPal-webpagina met een inlogvenster. In de praktijk zaten daar speciaal geprepareerde webservers achter die de gebruikersnaam en het wachtwoord van de achteloze klanten afvingen. De op die manier binnen gehengelde gegevens werden door de aanvallers meteen gebruikt om in te loggen en het account leeg te trekken. De schade voor die klanten was aanzienlijk en de supportkosten voor ondersteuning van deze klanten was ook huizenhoog. Een tijd lang had dat een weerklank op het merk PayPal, dat een twijfelachtige naam kreeg.

Maar kort na het invoeren van de DMARC-methode, die in het begin alleen door sommige providers gebruikt werd, daalde het aantal phishing-aanvallen zodanig significant dat DMARC als nieuw wondermiddel tegen spam en phishing gold. DMARC is geen extra techniek, maar een aantal regels voor het omgaan met SPF- en DKIM-informatie. DMARC-richtlijnen leggen vast hoe er bij overtredingen tegen de SPF- en DKIM-regels gehandeld moet worden en hoe er over die overtredingen melding moet worden gedaan.

Niet alle vormen van de DMARC-rapportage zijn overal toegestaan. Het terugsturen van een volledig rapport naar het afzenderdomein na het ontvangen van een verdachte mail kan bijvoorbeeld problemen opleveren. De mailafzender en de exploitant van de mailserver zijn zelden een en dezelfde persoon. Complete mails bevatten op zijn minst gegevens over de mailafzender en de -ontvanger, en vaak ook nog vertrouwelijke content die niet zonder toestemming van de communicatiepartner aan een serverexploitant mag worden doorgegeven.

Dit doet geen afbreuk aan het primaire doel om phishing in te dammen. DMARC beschermt een afzenderdomein effectief tegen misbruik. Voorwaarden daarvoor zijn wel een correct geconfigureerde SPF- en DKIM-functie. Anders ondermijnen de geschetste problemen beide technieken.

Of dat het geval is of dat vreemden wellicht onrechtmatig proberen om mee te liften op de reputatie van het afzenderdomein, is alleen door monitoring te achter­halen. Daarvoor verwerkt een bedrijf dat SPF of DKIM toepast de reports zelf of geeft daarvoor opdracht aan een dienstverlener als dmarcian. Die slaat dan alarm bij misbruik.

(Patrick Koetter en Noud van Kruysbergen, c’t magazine)

Blijf op de hoogte van de nieuwste informatie en tips!
Schrijf je in voor de nieuwsbrief: