E-mails vervalsen: Waarom is het überhaupt mogelijk

Soms is het makkelijk om phishing-e-mails te spotten door simpelweg naar het veld van de afzender te kijken. Dat is echter niet altijd het geval; het maken van een nep-e-mail die niet van een echte is te onderscheiden  is echt mogelijk. Als een aanvaller weet hoe dat moet, zit de organisatie waar de aanval op is gericht echt in de problemen. De meeste mensen zouden niet twee keer nadenken voor ze op een schadelijke link of een bestand klikken dat ze in een e-mail hebben ontvangen dat ogenschijnlijk van hun eigen baas of een belangrijke klant komt. En je kunt het ze moeilijk kwalijk nemen, zeker als het echt niet te zien is dat de e-mail nep was.

Maar waarom is het eigenlijk mogelijk om de perfecte nep-e-mail te maken? De lezing van Andrew Konstantinov over e-mailverificatie voor pentesters bij het 36e Chaos Communication Congress geeft antwoord op deze vraag en biedt tevens inzicht in de effectiviteit van bescherming tegen nep-e-mails.

Probleem 1: E-mail moet vloeien

E-mail is een belangrijke communicatiemethode in de moderne wereld, en alle organisaties ter wereld zijn sterk afhankelijk van e-mail bij het uitvoeren van hun dagelijkse operaties. Hoewel we niet veel over de technologie nadenken als alles soepel verloopt, zult u zien dat zodra er plotseling e-mails kwijtraken, iedereen dit ongetwijfeld zal opmerken. Daarom geniet betrouwbaarheid normaal gesproken de hoogste prioriteit bij elke administrator van e-mailservers. E-mail moet simpelweg verzonden en afgeleverd worden, hoe dan ook.

De implicatie hier is dat de e-mailserver van elke organisatie zo compatibel mogelijk moet zijn met al het andere in de wereld. En daar zit nou net het probleem: e-mailstandaarden zijn ontzettend verouderd.

Probleem 2: Het e-mailprotocol zonder authenticatie

Het hoofdprotocol dat zowel wordt gebruikt voor client-naar-server- en server-naar-server-e-mailcommunicatie is SMTP. Dit protocol werd in 1982 voor het eerst geïntroduceerd en in 2008 voor het laatst geüpdatet. Dat is dus meer dan 10 jaar geleden. Net als vele andere verouderde standaarden is SMTP een nachtmerrie wat betreft beveiliging.

Laten we eerst eens kijken naar waar een normaal e-mailbericht uit bestaat:

• SMTP-envelop. Dit gedeelte wordt gebruikt voor server-naar-server-communicatie en wordt nooit weergegeven in e-mailclients. Het specificeert de adressen van de afzender en de ontvanger.
• E-mailclients geven dit gedeelte weer. Dit is waar je de bekende velden “Van”, “Naar”, “Datum” en “Onderwerp” vindt, zoals bij elke e-mail het geval is.
• De tekst van de e-mail en andere inhoud.

Wat zit er in een e-mailbericht. Image source

Het grootste probleem is dat de standaard geen middelen voor authenticatie biedt. De verantwoordelijkheid voor het adresveld van de verzender — in zowel de SMTP-envelop en de header — ligt volledig bij de server van de verzender. Sterker nog: het adres van de verzender in de SMTP-envelop hoeft niet overeen te komen met het adres in de header (en de gebruiker ziet alleen dat laatste adres).

Maar hoewel de standaard één header per e-mail specificeert, wordt deze limiet niet daadwerkelijk door SMTP gehandhaafd. Als een bericht meer dan één header bevat, dan kiest de e-mailclient er simpelweg één uit om aan de gebruiker te tonen.

Je hoeft geen professioneel hacker te zijn om te zien dat dit problemen kan opleveren.

Het e-mailprotocol biedt geen enkel middel om te verzekeren dat een e-mail ook daadwerkelijk van de aangegeven verzender kwam

Probleem 3: Inkomende én uitgaande nep-e-mails — het mes snijdt aan twee kanten

Om het nog ingewikkelder te maken zijn er bij elke communicatie via e-mail twee partijen betrokken, dus dit probleem qua gebrek aan authenticatie is eigenlijk onder te verdelen in twee subproblemen.

Aan de ene kant wilt u er zeker van zijn dat ontvangen e-mail ook daadwerkelijk van het adres komt dat wordt vermeld. En aan de andere kant wilt u waarschijnlijk ook voorkomen dat andere mensen e-mails versturen die van uw adres lijken te komen. Helaas kan de standaard hier niet bij helpen.

Het is geen verrassing dat het SMTP-protocol zo vaak misbruikt werd dat mensen begonnen met het bedenken van nieuwe technologieën om de bovenstaande problemen op te lossen.

Poging tot oplossing 1: Sender Policy Framework (SPF)

Het idee achter het Send Policy Framework is vrij eenvoudig: de ontvangende server zou moeten kunnen controleren of het adres van de server die de e-mail daadwerkelijk heeft verzonden overeenkomt met het adres van de echte e-mailserver die met het domein geassocieerd is.

Helaas is dat makkelijker gezegd dan gedaan. De SMTP-standaard heeft geen middelen om zo’n controle uit te voeren, dus een eventuele authenticatiemethode zou als aanvulling moeten worden toegevoegd. Ervoor zorgen dat zulke technologie de “voorgestelde standaard” werd, duurde 10 jaar. Vandaag de dag gebruikt slechts 55% van de top 1 miljoen servers SPF, en de meeste daarvan gebruiken vrij soepele beleidsmaatregelen.

SPF zorgt tevens voor tal van andere problemen, zoals een rommelige architectuur die makkelijk onjuist geconfigureerd kan worden, bepaalde manieren om hem te omzeilen met gebruik van andere servers die op hetzelfde adres worden gehost, enzovoorts. Maar het grootste gebrek van SPF is dat het alleen het adres controleert dat is aangegeven in de SMTP-envelop, en het “Van”-veld in de header volledig negeert. En dat is het veld dat de gebruiker ook daadwerkelijk ziet.

Resultaat:

• SPF helpt bij het controleren of een e-mail van een echte server komt.
• Het adres dat gebruikers zien kan nog altijd nep zijn.

Poging tot oplossing 2: DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail pakt het probleem op een andere manier aan: DKIM ondertekent de header van het bericht en een gedeelte van de tekstinhoud cryptografisch met een privésleutel, waarvan de handtekening kan worden geverifieerd door een openbare sleutel die gepubliceerd is in het Domain Name System.

Het is echter de moeite waard om te vermelden dat DKIM niet het hele bericht hoort te versleutelen. Er wordt eigenlijk een cryptografisch ondertekende bijlage aan toegevoegd. Dat is een probleem. Het crypto-gedeelte is lastig te modificeren, maar het volledig verwijderen van de handtekening en het opstellen van een nepbericht is eenvoudig, en de resultaten zijn onzichtbaar.

DKIM is moeilijk te implementeren omdat er cryptografische sleutels moeten worden uitgegeven en beheerd. En onjuist geconfigureerde DKIM kan ook een aanvaller in staat stellen om de echte DKIM-handtekening in een bericht te behouden terwijl de header en inhoud wel volledig worden gewijzigd.

Resultaat:

• Dankzij DKIM kunt u berichten digitaal ondertekenen, wat helpt om de ontvangende server te verzekeren dat het bericht echt van u kwam.
• Het is moeilijk te implementeren vanwege het beheer van cryptografische sleutels.
• Oplichters kunnen de handtekening simpelweg verwijderen als ze een nep-e-mail namens u willen versturen.
• Onjuiste configuratie kan leiden tot nepberichten die daarentegen wél echte DKIM-handtekeningen bevatten.

Poging tot oplossing 3: Domain-based Message Authentication, Reporting and Conformance (DMARC)

Ondanks de vrij lange naam is het Domain-based Message Authentication, Reporting and Conformance-protocol een stuk eenvoudiger te begrijpen dan SPF of DKIM. Het is eigenlijk een uitbreiding van deze twee oplossingen met een oplossing voor de meest flagrante tekortkomen.

Ten eerste helpt DMARC de domein-administrator specificeren welk beschermingsmechanisme, SPF, DKIM of beide, de server gebruikt, wat het DKIM-mechanisme oplost. Ten tweede lost het SPF ook op door een controle van het adres dat in het “Van”-veld in de header is vermeld uit te voeren (het veld dat zichtbaar is voor de gebruiker), bovenop de controle van het adres van de verzender in de SMTP-envelop.

Het nadeel is dat het DMARC-protocol relatief nieuw is, nog geen echte standaard is (RFC 7489 definieert het niet als een norm of zelfs als voorgestelde norm, maar slechts als “Informatief”), en het wordt nog lang niet zo veel gebruikt als dat het geval zou moeten zijn. Volgens dit onderzoek van 20.000 domeinen had slechts 20% DMARC überhaupt ingevoerd in 2019, en slechts 8,4% hield er ook nog eens een strikt beleid op na.

Helaas is de invoering van DMARC nog niet erg wijdverspreid, en in veel gevallen wordt het gebruikt met een policy of none. Image source

Resultaat:

• Lost de belangrijkste problemen van SPF en DKIM op.
• Nog niet veel gebruikt, en daarom niet zo effectief als het zou kunnen zijn.

Hoe beschermt u zichzelf tegen nep-e-mails?

Kortom: het versturen van nep-e-mails is nog altijd mogelijk omdat het SMTP-protocol niet werd ontworpen met de juiste beveiligingsmaatregelen, dus hierdoor kan een aanvaller welk adres dan ook als verzender invoeren in een nep-e-mail. In de afgelopen decennia zijn er verschillende beveiligingsmechanismes opgedoken: SPF, DKIM en DMARC. Maar voordat deze mechanismes effectief zijn, moeten ze door zo veel mogelijk e-mailservers gebruikt worden (en correct geïmplementeerd zijn), en dat is nog niet het geval. Idealiter zouden ze op elke e-mailserver op het internet geïmplementeerd zijn.

Daarnaast is het belangrijk om rekening te houden met het feit dat het kan gebeuren dat een relay server iets aan de mails toe begint te voegen door configuratiefouten, en dit valt automatisch in de DKIM-controle. We moeten ook niet vergeten dat deze technologieën zullen helpen om met massadreigingen om te gaan, maar uw bedrijf tegen geavanceerde e-mailaanvallen te beschermen, heeft u aanvullende beveiligingsmaatregelen nodig, zowel op werkstations als op de e-mailserver.

Hier zijn wat aanbevelingen voor e-mailbeveiliging:

• Gebruik op zijn minst SPF. Zorg ervoor dat dit goed is ingesteld. Houd er ook rekening mee dat handige aanvallers SPF kunnen omzeilen (meer details in de lezing).
• Implementeer DKIM voor betere bescherming. Het is wellicht wat lastiger, maar het is de moeite van het overwegen waard. Zorg er ook hier voor dat het goed is ingesteld (wat tips over waar aanvallers naar op zoek zijn).
• Voer DMARC in, aangezien het de zwakke plekken van SPF en DKIM kan oplossen.
• Controleer ook uw configuratie voor inkomende e-mail.
• Gebruik beveiligingssystemen die moderne authenticatiemechanismes ondersteunen. Gebruik bijvoorbeeld Kaspersky Security for Mail Servers of Kaspersky Security for Microsoft Office 365.