Wat hebben marketingcampagnes en CFO-fraude met elkaar te maken?

Maakt jouw communicatieafdeling gebruik van marketingbureaus om mailcampagnes te organiseren? Hoe vaak wisselen ze van dienstverlener? En… weet je IT-afdeling daar dan van?

Steeds vaker kiezen organisaties voor SaaS-oplossingen als vervanging van hun on-premises applicaties. Dit geldt vast ook voor jouw organisatie. SaaS-oplossingen bieden vele voordelen, zoals eenvoudige schaalbaarheid, flexibiliteit, automatische upgrades en pay-per-use. So far so good. Een eigenschap van deze SaaS-applicaties is dat zij vaak e-mails, zoals notificatieberichten, naar de gebruikers sturen. Een loonstrookje, een bericht dat de vakantie is aangevraagd of goedgekeurd, of bijvoorbeeld een toegangsverzoek tot een onderdeel van de applicatie. En daar schuilt een beveiligingsrisico waar menig afdeling zich niet bewust van lijkt te zijn.

Deze notificaties vormen doorgaans geen probleem in situaties waarin de applicaties in eigen beheer zijn van je IT-afdeling, zoals bij een HR- of financieel softwarepakket. De IT-afdeling weet als het goed is waar op te letten bij de inrichting ervan. Maar de marketing- en/of communicatieafdeling gebruikt niet alleen zelf SaaS-applicaties, bijvoorbeeld bij direct mailings voor campagnes, maar zet vaak de hulp in van externe marketingbureaus in, die zonder enige twijfel ook gebruik maakt van SaaS-diensten.
Waar schuilt het probleem dan precies in?

"Je breidt gewoon het bestaande record uit met een “include ” naar het record dat de leverancier aanbiedt en alles is weer helemaal in orde. Of… toch niet?"

Standaarden om e-mail als legitiem te herkennen

Om ervoor te zorgen dat je eigen en andere organisaties jouw organisatie als legitieme afzender van de verzonden mails uit zo’n applicatie herkent, geven veel van deze SaaS-diensten een standaard instructie voor aanpassingen aan het zogenaamde ‘Sender Policy Framework’ (SPF) en ‘Domain Keys Identified Mail’ (DKIM) in de DNS (Domain Name System):

SPF is een autorisatiemechanisme dat via DNS vaststelt of het IP-adres van de versturende server toestemming heeft om namens jouw organisatie e-mails te versturen.
DKIM is een authenticatiemechanisme dat via een zelfde soort bevraging vaststelt of de betreffende mailserver gerechtigd is om mail te versturen met een private/public key combinatie.

Maar niet alle systemen die e-mail versturen, ondersteunen DKIM. Daarom zijn de meeste e-mail domeinen ingesteld om de verstuurde mail als “validated” te accepteren als tenminste één van de SPF of DKIM-protocollen succesvol is getest.

Van deze twee spam verminderende oplossingen is SFP-record (rfc7208) de oudste en meest eenvoudige oplossing. Je breidt gewoon het bestaande record uit met een “include ” naar het record dat de leverancier aanbiedt en alles is weer helemaal in orde. Of… toch niet?

Waar je eens goed over na zou moeten denken, is of het wel zo wenselijk is dat de SPF-records voor die verschillende leveranciers zomaar worden toegevoegd.

'SPF includes’ vormen een continuïteitsrisico

Regelmatig kom ik verzoeken tegen vanuit marketing- en communicatieafdelingen om voor een campagne zo’n “include:” toe te voegen. Maar bijna nooit komt er een verzoek om dit terug te draaien wanneer het contract met deze dienstverlener voorbij is. Misschien is jullie communicatieafdeling het jaar erna overgestapt naar een ander bureau voor de volgende campagne. En zo worden elke keer records toegevoegd aan SPF. Maar: dit kan niet eindeloos. Hiervoor geldt een harde limiet die in de SPF standaard is opgenomen.

Deze limiet in de standaard voorkomt dat een aanvaller met een kleine hoeveelheid mails de mailserver van een organisatie kan blokkeren. Dit kan een aanvaller in theorie doen door een kerstboom van naar elkaar verwijzende SPF-records en includes op te zetten, waardoor de e-mailserver zich eindeloos bezig moet houden met het opzoeken van deze verwijzingen. Om dit te voorkomen heeft de Internet Engineering Task Force (IETF) vastgesteld dat er per te controleren e-mailadres maximaal 10 (recursieve) DNS look-ups zijn toegestaan. Als het afzendende IP-adres hierna niet gevalideerd is, wordt het adres als niet valide vastgesteld en leidt dit tot een “permerror” in de SPF-evaluatie waardoor de ontvanger de betreffende mail als junkmail interpreteert of zelfs helemaal niet accepteert.

Het is aan de leverancier van zo’n SaaS-dienst om hun SPF-record verder te beheren. Wanneer zij zelf ook meerdere includes of andere DNS look-ups toevoegen, is de grens van 10 snel overschreden. In dat geval heb je daar zelf geen controle meer over.

Het aantal SPF-records klein houden is een eerste vereiste in goed e-mailbeheer.

"We leren onze medewerkers om op te letten en phishing te herkennen aan afwijkende afzender e-mailadressen, maar wat nou als het e-mailadres van de afzender ook echt klopt?"

Bulkmail ook een beveiligingsrisico

Maar ook de CISO van je organisatie moet een blik werpen op dergelijke verzoeken. Marketing- en reclamebureaus bedienen zich voor e-mailcampagnes van je organisatie vaak met externe bulkmail oplossingen, zoals Sendgrid, Mailgun, Flowmailer en Mailchimp. Veel van dergelijke oplossingen beschikken over meerdere grote publieke IP-reeksen om mail vanuit te versturen, waarmee ze voorkomen dat hun systemen op een blacklist komen. En als een adres tijdelijk geblokkeerd is, dan gebruiken deze oplossingen gewoon een van de andere duizenden beschikbare adressen. En daar komt de veiligheidsvraag naar voren.

Wanneer je deze include toevoegt aan je generieke SPF-record, kan de betreffende maildienst – of een ander systeem dat zich in een dergelijke IP-reeks bevindt – namens alle (bestaande en niet-bestaande!) mailadressen van je organisatie mails versturen. Oók namens bijvoorbeeld de CEO of CFO. Een toegewijd aanvaller hoeft dus niet je eigen organisatie aan te vallen, maar kan er ook voor kiezen om het algemene SPF-record uit te lezen en een bulkmailer, of andere SaaS-applicatie die daarin voorkomt, aan te vallen. CFO-fraude en phishing aanvallen liggen daarmee op de loer. We leren onze medewerkers om op te letten en phishing te herkennen aan afwijkende afzender e-mailadressen, maar wat nou als het e-mailadres van de afzender ook echt klopt?

Dat dit geen overdreven denkwijze is, werd eind maart 2022 bevestigd met een hack bij Mailchimp: een bulkmailoplossing werd gecompromitteerd waarna phishing mails via het platform naar eindgebruikers van een van hun klanten zijn verstuurd in een poging crypto currency tokens te stelen.

Verbeteren van je SPF-record

Het kan ook anders: de SPF-standaarden geven de mogelijkheid voor het gebruik van macro variabelen in je SPF-record, zie de afbeelding hieronder:

Door met deze variabelen te werken, kunnen organisaties het mailen vanuit een SaaS-applicatie beperken tot een aantal vaste e-mailadressen. Met name de geel gemarkeerde variabele leent zich hier goed voor, omdat met het gedeelte voor de @ specifieke SPFrecords kunt aanmaken per e-mailadres. Het helpdeskpakket van je organisatie mag dan alleen mails versturen namens helpdesk@bedrijf.com, het verloningspakket alleen namens loonstrookje@bedrijf.com en de bulkmailoplossing van de communicatieafdeling alleen namens klantendag@bedrijf.com.

Dit gaat misschien niet voor alle SaaS-applicaties op, maar het helpt wel aanzienlijk om het aantal look-ups in het hoofd SPF-record laag te houden én het beperkt de risico’s op CEO- of CFO-fraude. Dit laatste omdat de betreffende applicatie bij een succesvolle hack, niet geautoriseerd is om mail te versturen namens iets anders dan het vooraf gespecificeerde e-mailadres van deze applicatie.

Loop je tegen SPF gerelateerde e-mailproblemen aan of heb je veel SaaS-applicaties die namens alles en iedereen in de organisatie kunnen mailen? En wil je iets doen tegen het risico van CEO- of CFO-fraude? Neem contact op met Solvinity! We leggen met alle plezier uit hoe je deze e-mail specifieke SPF-records het beste in kunt richten en helpen je ook graag met andere security gerelateerde zaken.