Zendesk-ændring efterlod kunder med ugyldige SPF-records

En ændring hos helpdesk-leverandøren Zendesk efterlod adskillige kunder med ugyldige SPF-records.

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.


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.

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.

Læs også: CFCS i DMARC-smutter: »Det er selvfølgelig en ren tilståelsessag«

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

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.

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

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.

Læs også: Nets melder om heftigt fald i forsøg på NemID-phishing efter aktivering af DMARC

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.«

Læs også: Center for Cybersikkerhed: Organisationer bør bruge DMARC

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).

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lasse Mølgaard

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.

  • 0
  • 0
Henrik Schack

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.

  • 2
  • 0
Log ind eller Opret konto for at kommentere