kramselund jereminsen

Advarsel: phishing emails fra e-boks

... om x dage.

Jeg har som virksomhedsejer fået pålagt at få en konto hos e-boks, yay! Det glæder mig altid at man med tvang kan få mig til at indgå aftale med en ekstern part, ligesom med NemID. Betingelserne kan jeg nok ikke gøre noget ved og klikkede mig derfor idag igennem oprettelse af to digitale postkasser. (Login tog en krig, men selve processen var for en gangs skyld ikke så ringe endda!)

Nu har jeg således modtaget bekræftelsesemail fra e-boks.dk:

Return-Path: <indgaaende@prod.e-boks.dk>
X-Original-To: hlk@kramse.org
Delivered-To: hlk@kramse.org
Received: from ebokssmtp.e-boks.dk (ebokssmtp.e-boks.dk [131.165.77.52])
  (using TLSv1 with cipher RC4-MD5 (128/128 bits))
   (No client certificate requested)
  by mail.kramse.org (Postfix) with ESMTPS id 1C5A539583
 for <hlk@kramse.org>; Mon, 28 Oct 2013 10:57:03 +0100 (CET)
Received: from eboksapp202d (172.30.38.79) by ebokssmtp.e-boks.dk
 (172.30.38.178) with Microsoft SMTP Server id 8.1.436.0; Mon, 28 Oct 2013
 10:53:42 +0100
MIME-Version: 1.0
From: e-Boks <indgaaende@prod.e-boks.dk>
To: "hlk@kramse.org" <hlk@kramse.org>
Date: Mon, 28 Oct 2013 10:54:33 +0100
Content-Type: text/html; charset="us-ascii"

Det giver jo anledning til nogle bemærkninger. Cool nok er det første man bemærker at de bruger opportunistic encryption - der er brugt TLSv1 mellem deres server og min https://en.wikipedia.org/wiki/Opportunistic_encryption Det gør Skat faktisk også via CSC, fra en anden email:

Received: from sktsens01mas02.csc.dk (skat.csc.dk [147.29.27.196])
  (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))

Det lyder jo unægteligt bedre end 128-bit - men til gengæld har NSA måske nøglen eller adgang til rå-data hos Skat. ;-)

DNS oplysninger for e-boks

Nå, tilbage på sporet med e-boks. De bruger i emailen domænet prod.e-boks.dk og opslag i DNS giver:

hlk$ host prod.e-boks.dk
prod.e-boks.dk mail is handled by 10 smtp-in.e-boks.dk.
hlk$ host smtp-in.e-boks.dk.
smtp-in.e-boks.dk has address 131.165.77.73
hlk$ host e-boks.dk
e-boks.dk has address 131.165.77.33
e-boks.dk mail is handled by 20 eboks-dk0c.mail.eo.outlook.com.
e-boks.dk mail is handled by 10 eboks-dk0c.mail.eo.outlook.com.
hlk$ host -t ns e-boks.dk
e-boks.dk name server ns-auth04.kmd.dk.
e-boks.dk name server ns-auth03.kmd.dk.
hlk$ host ns-auth03.kmd.dk
ns-auth03.kmd.dk has address 131.165.64.5
hlk$ host ns-auth04.kmd.dk
ns-auth04.kmd.dk has address 131.165.4.5

Der er lidt diverse, som er OK, der er to navneservere defineret som ligger på hvert sit /24 subnet (hos samme udbyder) og lidt SMTP indstillinger, som er forskellige. Det betyder at "prod" domænet som bruges til udsendelse bruger KMD adresse (131.165.77.73) mens de bruger outlook.com til kommunikation på e-boks.dk domænet, hmmm. Tjoeh, det kan de vel godt - men så ender der nemt emails med følsomt indhold over NSA, sorry USA!

Anti-spam SPF records

Det første jeg gerne vil checke er om domænerne der bruges er opsat nogenlunde fornuftigt. Hvis man står for udsendelse til mange modtagere forventer jeg eksempelvis SPF, og det er der:

hlk@katana:hlk$ host -t txt e-boks.dk
e-boks.dk descriptive text "v=spf1 include:spf.microsoftonline.com a mx a:mail.kmd.dk a:mail3.kmd.dk ip4:131.165.63.80/28 ip4:131.165.67.22 ip4:131.165.63.83 ip4:131.165.63.185 ip4:131.165.63.184 ip4:131.165.77.52 -all"
hlk@katana:hlk$ host -t txt prod.e-boks.dk
prod.e-boks.dk descriptive text "v=spf1 a mx a:mail.kmd.dk a:mail3.kmd.dk ip4:131.165.63.80/28 ip4:131.65.67.22 ip4:131.165.63.83 ip4:131.165.63.185 ip4:131.165.63.184 ip4:131.165.77.52 ip4:131.165.77.48 ip4:131.165.77.73 -all"

Bemærk også at der er en include på spf.microsoftonline.com og SPF record er valid, iflg. en tilfældig SPF tester jeg brugte, http://mxtoolbox.com/SuperTool.aspx?action=spf%3a+prod.e-boks.dk&run=too...

Illustration: Privatfoto

Det er for så vidt godt nok, best current practice. De kunne dog godt tilføje en DMARC, jeg brugte dmarcian.com til at checke, og de har også tools til at lave DMARC records HINTHINT

Hvorfor skulle e-boks så oprette dette? Fordi der med denne tvangsimplementering nu ender med at være ca. 450.000 mulige mål for phishing. Enten har folk oprettet en digital postkasse, hvor de formentlig får ret få emails og derfor næppe vil kunne genkende en valid email fra en forfalsket.

Alternativt er der over 300.000 aktive virksomheder der ikke har oprettet endnu og derfor muligvis kan lokkes til at trykke på links i emails med trusler. (Tal er baseret på version2 artikel http://www.version2.dk/artikel/erhvervsstyrelsen-vi-naar-ikke-digital-po... )

Lad os prøve at formulere en sådan trusselsemail:

Den er med vilje baseret på lignende emails fra Skat.dk som dog indeholder et logo, men who cares - folk skal nok trykke på den, den kommer jo fra eboks.dk!

Jeg tror meget snart vi vil se lignende forsøg, og det ville formentlig hjælpe hvis man fik DMARC på domænet. Det kunne eksempelvis hjælpe dem som bruger Gmail til post, og du kan læse hvordan Google bruger DMARC Understand DMARC

Det ville samtidig være en god ide at få smidt SPF records på nogle af de nærliggende domæner som peger på e-boks, eksempelvis eboks.dk - tak til Henrik Schack på twitter @Schack for den pointe.

Specielt fordi vi nu har flere og flere services som IKKE bruger .dk domænet. Eksempelvis NemID som er på NemID.nu. Det betyder at brugere vænner sig til at det er ok med .com, .nu og sikkert ikke vil bemærke et .us, .li eller andre som kan oprettes hurtigt.

Hvad synes du? Bør vi begynde at kræve at Skat.dk, CSC, KMD, NemID, Virk.dk, E-boks og de andre bruger den anti-spam metoder som Google Gmail checker? (eller andre populære email services, men Gmail er MEGET udbredt blandt virksomheder, som netop er fokus for dette indlæg.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Henrik Schack

De fleste store firmaer som phishes ser ud til at bruge en del krudt på at oplyse kunderne om hvordan man genkender phishing email. De phishes dog stadig med success som vi kunne se i Operation-X: Den perfekte forbrydelse.

Så ja, det ville nok være en god ide hvis de store firmaer gjorde alt hvad der er teknisk muligt for at forhindre phis i at nå frem til kundernes inbox.

Med andre ord, lad os komme igang med at implementere DMARC i DK.

  • 7
  • 0
#2 Anders Kvist

Enig - alle mails fra det offenlige bør indeholder alt den slags sikkerhedsfeatures. De burde også benytte sig af signing af mailen via DKIM - det kræver nogle udbydere (f.eks. Yahoo)...

  • 3
  • 0
#3 Henrik Schack

Danske Banks Mobilepay brugere kunne også være et oplagt mål for phishing. Så vidt jeg husker har man passeret 500000 brugere på løsningen.

Den nuværende konfiguration af mobilepay.dk domænet gør det super simpelt for hele verden at afsende @mobilepay.dk emails.

  • 8
  • 0
#4 Baldur Norddahl

Jeg er ikke nogen fan af SPF. Det smadrer email forwarding og der findes ikke noget acceptabelt fix. Den angivne løsning SRS http://www.openspf.org/SRS er horribel. Hvis der bruges SPF bør det være soft fail, så at det kun er en indikation som spamfilteret kan tage i betragtning.

DKIM http://www.dkim.org/ er derimod en god ide og burde være et krav for alt post fra det offentlige.

Hvis de endvidere har en DMARC der angiver at DKIM er et krav på alle offentlige domæner, så er det i praksis umuligt for svindlere at forfalske en mail med originalt domæne. SPF vil her kun tilføre minimalt ekstra.

  • 0
  • 0
#6 Sune Marcher

Hvad synes du? Bør vi begynde at kræve at Skat.dk, CSC, KMD, NemID, Virk.dk, E-boks og de andre bruger den anti-spam metoder som Google Gmail checker? (eller andre populære email services, men Gmail er MEGET udbredt blandt virksomheder, som netop er fokus for dette indlæg.

...og vi bør kræve at alt der bare lugter en LILLE smule af infrastruktur foregår via et .dk domæne.

  • 4
  • 0
#8 Baldur Norddahl

SPF og DKIM er "backup" for hinanden i DMARC sammenhænge.

Hvis man følger Henrik Kramshøj anbefaling om at bruge -all i SPF så er der ikke meget backup i det:

https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1

15.2. Issues Specific to SPF ... Some receiver architectures might implement SPF in advance of any DMARC operations. This means a "-" prefix on a Sender's SPF mechanism, such as "-all", could cause that rejection go into effect early in handling, causing message rejection, before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.

Derfor er det bedre at bruge SOFTFAIL (~all). Googles Gmail bruger ~all.

Man kan så bruge en reject policy på DMARC.

En modtager der har DMARC support vil tjekke om enten SPF eller DKIM er god og enten tage imod eller afvise mailen hårdt. Mail forward er ok da DKIM reder dagen.

En modtager der kun har SPF (ingen DMARC eller DKIM support) vil effektivt lave fail back til enten at godkende mailen eller lave SOFTFAIL. Det er den foretrukne løsning idet SPF fail kunne skyldes at mailen er blevet forwardet.

Så det er to gode grunde til at droppe -all og bruge ~all i stedet.

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