Zendesk-ændring efterlod kunder med ugyldige SPF-records

13. februar 2019 kl. 05:112
Zendesk-ændring efterlod kunder med ugyldige SPF-records
Illustration: Bigstock.
En ændring hos helpdesk-leverandøren Zendesk efterlod adskillige kunder med ugyldige SPF-records.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Et skifte i den bagvedliggende infrastruktur hos helpdesk-udbyderen Zendesk har bevirket, at adskillige kunder en overgang fik problemer med mail-validering.

Henrik Schack står bag sitet status.dmarc.dk, som løbende scanner diverse domæner i forhold til, hvorvidt de bruger mail-beskyttelsesteknologien DMARC og de underliggende mekanismer DKIM og SPF.

Fra 22. januar og til 23. januar registrerede en automatiseret scanner på status.dmarc.dk pludseligt en masse nye domæner med en defekt SPF-record.

Remote video URL

SPF bruges til at validere, at ip-adressen for en server, der har sendt en mail fra et givet domæne, nu også har lov at sende på vegne af domænet. Formålet er at stoppe spam, svindel og anden ondskab i brugernes indbakker.

DMARC

DMARC sætter en politik for to andre protokoller, SPF og DKIM.

SPF (Sender Policy Framework) er et simpelt system til validering af mails og er designet til at detektere spoofing. Modtageren af en mail kan kontrollere, at indgående mails fra et domæne kommer fra en server (IP-adresse), der er godkendt af domæne-ejeren (afsender). Listen over godkendte servere for et domæne publiceres via domænets DNS-oplysninger.

DKIM (DomainKeys Identified Mail) beskriver, hvordan der kan knyttes et domæne-specifikt id til en mail. Domæne-ejeren kan signere den enkelte mail med en privat signeringsnøgle og dermed give modtageren mulighed for at verificere, om mailen er afsendt fra en server, der er registreret i DNS (Domain Name System).

Verifikationen sker på baggrund af afsender-serverens offentlige signeringsnøgle, der er tilgængelig via DNS.

Kilde: 'Reducér risikoen for falske mails, Center for Cybersikkerhed (PDF)


En SPF-record kan indeholde hostnames - eksempelvis mail.zendesk.com - og ip-adresser. Disse oplysninger fortæller mail-modtageren, hvem der har lov at sende mails på vegne af et domæne.

Det bliver eksempelvis brugt i forbindelse med udsendelse af nyhedsbreve via en tredjeparts-tjeneste som Mailchimp.

Artiklen fortsætter efter annoncen

Det vil sige, at mens en mail ser ud til at komme fra en virksomheds domæne, så er mailen sendt fra Mailchimps-server.

Sådan en situation kan se mistænksom ud set fra mail-modtagerens perspektiv, men fordi Mailchimp er føjet til virksomhedens SPF-record, så kan mail-modtageren validere, at alt faktisk er ok.

Højst 10 opslag

Standarden tilsiger, at der højst må være 10 DNS-opslag forbundet med et et kig i SPF-recorden tilknyttet et domæne.

Mens mail.zendesk.com kræver et opslag, så gør en ip-adresse det ikke. Der kan altså være mange ip-adresser, men ikke så mange domæner.

Artiklen fortsætter efter annoncen

Henrik Schack forklarer til Version2, at det smarte ved at have domæner i stedet for ip-adresser i sin SPF-record er, at en tredjepart - eksempelvis Zendesk - kan ændre i sine ip-adresser og infrastruktur uden at alle kunder behøver opdatere deres SPF-records. Så længe, der står mail.zendesk.com, så er alt i udgangspunktet fint.

Hvis ellers tredjeparten har styr på sin del.

»Du er nødt til at stole på, at tredjeparten har fuldstændig styr på, hvad de laver, ellers kan du pludseligt stå med en invalid konfiguration,« siger Schack.

Tilbage til Zendesks ændring, der bevirkede, at kunder fik en ugyldig SPF-record. Henrik Schack forklarer, at et sted omkring 22. og 23. januar skete der en ændring, så mail.zendesk.com ikke længere kun pegede på en stribe ip-adresser, men også inkluderede en henvisning til et andet domæne, spf1.mail.zendesk.com

Artiklen fortsætter efter annoncen

Det bevirkede, at mail.zendesk.com, der i kunderners SPF-records tidligere udløste et enkelt DNS-opslag, nu resulterede i to opslag som følge af spf1.mail.zendesk.com

Det er ikke i sig selv et problem, da der jo må være 10 opslag i en SPF-record. Men ifølge Henrik Schack kører flere allerede med 10 opslag i deres SPF-records.

»Der er mange, der ligger på grænsen på 10. Når Zendesk laver sådan et nummer, så er de (kunderne, red.) oppe på 11,« siger han.

Og med 11 opslag er SPF-recorden ikke længere gyldig.

Ifølge Henrik Schack har en del organisationer unødige opslag i deres SPF-records, fordi der aldrig rigtigt bliver luget ud i forhold til tjenester, der ikke længere bliver brugt og den slags.

Intet fallback

Når SPF-record ikke længere er gyldig kan det betyde, at næste et ellers legitimt nyhedsbrev bliver udsendt af en tredjepart på vegne af en virksomhed, så ryger mailen direkte i spam-mappen, fordi modtagerens mail-server ikke længere kan validere, at alt er ok.

Hvis en organisation har implementeret og aktiveret DMARC, herunder SPF og en anden mail-validerings-mekanisme, DKIM, så kan de to sidstnævnte løsninger tjene som en fallback for hinanden, forklarer Henrik Schack.

Men mange anvender ikke DMARC, hvilket et kig på status.dmarc.dk bevidner.

»Hvis SPF er det eneste, du har, hvilket er tilfældet for de fleste, så har du ødelagt den eneste autentifikation, du har til rådighed,« siger Henrik Schack.

Problem løst

Af en debattråd hos Zendesk, hvor Henrik Schack også har blandet sig, fremgår det, at helpdesk-virksomheden har løst problemet, så mail.zendesk.com ikke længere udløser to opslag, men et.

I samme tråd skriver en af Zendesk kunder, at de er »seriously affected by this action,« med henvisning til ændringen, der udløste de to opslag i første omgang.

Baseret på udsnit af domæner på status.dmarc.dk, der pludseligt havde ugyldige SPF-records, gætter Henrik Schack på, at en del Zendesk-kunder har været ramt af ændringen.

»Jeg tror ikke, det er overdrevet at sige, det har påvirket tusindvis af firmaer.«

I en mail oplyser PR-manager Maria Di Martino fra Zendesk, at virksomhedens SPF-record faktisk plejede at udløse to DNS-opslag, men de seneste par år har der kun været tale om et enkelt. Altså indtil for nyligt.

»Den utilsigtede midlertidige stigning, tilbage til to opslag, kan have medført, at nogle domænes SPF-poster overskrider de 10 tilladte DNS-opslag. Vi beklager dette dybt, og enhver negativ indvirkning dette måtte have haft på mail-aflevering,« skriver står der i mailen fra Maria Di Martino, som fortsætter:

»Dette var ikke et sikkerhedsproblem. Vi erkender imidlertid ulejligheden, det har medført for vores kunder, og derfor vigtigheden for, at vi straks handler på det.«

Maria Di Martino oplyser, at Zendesk 24. januar havde justeret i systemerne igen, så mail.zendesk.com atter udløste blot et enkelt opslag.

»Vi arbejder nu på at tilføje monitorering af mail.zendesk.com SPF-recorden, som vil gøre os i stand til at få omgående alarmer, såfremt antallet af opslag siger,« oplyser hun.

Center for Cybersikkerhed anbefaler danske organisationer at bruge DMARC. CFCS har udgivet om DMARC, SPF og DKIM. Vejledningen ligger her (PDF).

2 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
13. februar 2019 kl. 10:41

Lige præcis MailChimp er lidt defekt konstrueret, der bliver du altid tvunget til at oprette en SPF record. Anvender du et subdomæne skal den dog oprettes på subdomænet istedet for i roden af domænet. Det er en god ting, idet der slet ikke er tale om SPF understøttelse, men derimod den afdøde Sender ID standard.

1
13. februar 2019 kl. 09:53

Og tænk sig: Her troede jeg at folk havde taget ved lære ved at sende nyhedsbreve fra et subdomæne lad os kalde det: newsletter.domain.com og tilføjet en TXT-record i DNS serveren på formen (selector)._domainkey.newsletter.domain.com som indeholder følgende værdi: "v=DKIM1; t=s; p=(... indsæt relevant værdi);"

Sådan som jeg forstår det var pointen at man behøver ikke at tilføje MailChimp og lignende til ens SPF-record, når man har allerede givet nyhedstjenesten en autoriseret kryptografisk nøgle, som de kan signere mailen med.

Ideen er så, at hvis der bliver sendt mails ud som er ikke signeret kryptografisk, så kan man via DMARC fortælle modtageren at disse mails skal ikke leveres til modtageren.