Dette indlæg er alene udtryk for skribentens egen holdning.

Advarsel: phishing emails fra e-boks

28. oktober 2013 kl. 12:538
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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

  1. Return-Path: <indgaaende@prod.e-boks.dk>
  2. X-Original-To: hlk@kramse.org
  3. Delivered-To: hlk@kramse.org
  4. Received: from ebokssmtp.e-boks.dk (ebokssmtp.e-boks.dk [131.165.77.52])
  5. (using TLSv1 with cipher RC4-MD5 (128/128 bits))
  6. (No client certificate requested)
  7. by mail.kramse.org (Postfix) with ESMTPS id 1C5A539583
  8. for <hlk@kramse.org>; Mon, 28 Oct 2013 10:57:03 +0100 (CET)
  9. Received: from eboksapp202d (172.30.38.79) by ebokssmtp.e-boks.dk
  10. (172.30.38.178) with Microsoft SMTP Server id 8.1.436.0; Mon, 28 Oct 2013
  11. 10:53:42 +0100
  12. MIME-Version: 1.0
  13. From: e-Boks <indgaaende@prod.e-boks.dk>
  14. To: "hlk@kramse.org" <hlk@kramse.org>
  15. Date: Mon, 28 Oct 2013 10:54:33 +0100
  16. 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:

  1. Received: from sktsens01mas02.csc.dk (skat.csc.dk [147.29.27.196])
  2. (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:

  1. hlk$ host prod.e-boks.dk
  2. prod.e-boks.dk mail is handled by 10 smtp-in.e-boks.dk.
  3. hlk$ host smtp-in.e-boks.dk.
  4. smtp-in.e-boks.dk has address 131.165.77.73
  5. hlk$ host e-boks.dk
  6. e-boks.dk has address 131.165.77.33
  7. e-boks.dk mail is handled by 20 eboks-dk0c.mail.eo.outlook.com.
  8. e-boks.dk mail is handled by 10 eboks-dk0c.mail.eo.outlook.com.
  9. hlk$ host -t ns e-boks.dk
  10. e-boks.dk name server ns-auth04.kmd.dk.
  11. e-boks.dk name server ns-auth03.kmd.dk.
  12. hlk$ host ns-auth03.kmd.dk
  13. ns-auth03.kmd.dk has address 131.165.64.5
  14. hlk$ host ns-auth04.kmd.dk
  15. 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:

  1. hlk@katana:hlk$ host -t txt e-boks.dk
  2. 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"
  3. hlk@katana:hlk$ host -t txt prod.e-boks.dk
  4. 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=toolpage

Artiklen fortsætter efter annoncen

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-post-deadline-54451 )

Artiklen fortsætter efter annoncen

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.

8 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
7
1. november 2013 kl. 07:56

Man må vel som minimum kunne forvente, at e-mail fra e-boks var signeret med en gyldig digital signatur? ;-)

Det samme gælder for skat, banker og andre, som er i risiko for at blive misbrugt til phishing.

6
31. oktober 2013 kl. 22:01

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
29. oktober 2013 kl. 21:28

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.

5
29. oktober 2013 kl. 21:39

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

8
1. november 2013 kl. 14:36

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.

3
28. oktober 2013 kl. 19:20

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.

1
28. oktober 2013 kl. 13:44

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.

2
28. oktober 2013 kl. 14:34

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