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

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