Er din Exchange-server sikret godt nok mod phishing?

Mange virksomheder sikrer ikke deres e-mailsystemer tilstrækkeligt mod phishing-angreb. Det mener 30-årige Henrik Svendsen, der arbejder med perimetersikkerhed hos Region Syddanmark.

Har du sikret din Exchange-server godt nok mod de såkaldte phishing-angreb, hvor en e-mail-afsender med onde hensigter udgiver sig for at være en anden person, end han egentlig er?

Dét spørgsmål mener den 30-årige Microsoft Certified Systems Engineer Henrik Svendsen, at alle virksomheder bør stille sig selv, hvis de benytter Microsofts mailløsninger internt i virksomheden.

Han arbejder til daglig i it-drift hos Region Syddanmark, hvor han har speciale i perimetersikkerhed.

Alt for mange lader nemlig et potentielt sikkerhedshul, der kan udnyttes til phishing-angreb, stå på vid gab, siger Henrik Svendsen.

»Jeg kan sende en e-mail, der fremgår at være fra en kontakt internt i firmaet, og man vil kun kunne se forskellen ved at kigge på afsenders IP-adresse. Det gør, at mailen ser ud til at komme eksempelvis fra chefen, men i virkeligheden kan den indeholde et viruslink eller et phishinglink,« forklarer Henrik Svendsen.

I en længere skriftlig redegørelse, som Version2 vælger kun at offentliggøre uddrag af, viser Henrik Svendsen, hvordan en tænkt person, Phisher-Philip, spreder et ondsindet link til alle medarbejdere i en kommune ved at udgive sig for at være servicedesk@kommune.dk.

Afsender kontrolleres ikke

Kernen i demonstrationen er, at mailsystemet siger god for en e-mail og anser den for at stamme fra internt hold, hvis blot navn og e-mailadresse genkendes i systemet.

Phisher-Philip udgiver sig altså for at være en officiel afsender internt i kommunens eget e-mail-system, som kommunens medarbejdere er vant til at stole på.

I virkeligheden har han afsendt e-mailen fra sin egen SMTP-server og blot anskaffet sig e-mailadresserne på medarbejderne i kommunen ved at gennemsøge kommunens hjemmeside med et særligt program.

Når Phisher-Philip kan lykkes med sit forehavende, skyldes det ifølge Henrik Svendsen en indbygget sårbarhed i Microsofts mailarkitektur, der normalt består af én eller flere Exchange-servere og et Active Directory med et indbygget Global Directory.

Når Exchange-serveren modtager en e-mail til aflevering, laver den et opslag i sit Active Directory, som besvarer Exchange-serverens spørgsmål om, hvorvidt navn og e-mailadresse kendes i systemet.

Men ved som Phisher-Philip at sætte afsenderen til at have et navn og en e-mailadresse, som i forvejen eksisterer i Microsoft-systemet, kan Exchange-serveren og Active Directory snydes til at tro, at e-mailen kommer fra en intern konto.

»Kernen i problemet er, at det kun kontrolleres, om modtageren eksisterer i mailsystemet, mens afsenderen ikke kontrolleres,« siger Henrik Svendsen.

Han mener derfor, at mailløsninger som eksempelvis Microsofts burde have en indbygget sikkerhed mod den slags angreb.

Microsoft: En 'svaghed' i SMTP

Hos Microsoft Danmark bekræfter sikkerhedschef, Morten Juul Nielsen, at det kan lade sig gøre at udgive sig for at være end anden e-mailafsender.

Det skyldes dog ikke en sårbarhed i Microsofts mailprodukter, men derimod den måde, SMTP-protokollen er designet på fra begyndelsen, siger han.

»Det er en styrke - eller en svaghed, om man vil - som er generel for mailløsninger, der benytter SMTP-protokollen. Styrken er, at protokollen frit tillader, at alle kan sende e-mails til hinanden. Svagheden er så, at protokollen tillader, at man via e-mailadressen kan udgive sig for at være en anden afsender,« siger Morten Juul Nielsen.

SMTP ? Simple Mail Transfer Protocol - blev første gang defineret som en internetstandard for e-mailafsendelse i 1982 og er i dag stadig de facto-standarden for e-mailudveksling. Protokollen benytter TCP port 25.

Morten Juul Nielsen fortæller, at mange i it-branchen tilbage i 1990'erne brugte 'svagheden' i SMTP-protokollen til at sende morsomme e-mails rundt internt i virksomheden ? for eksempel omkring juletid, hvor e-mails med afsenderen julemanden@microsoft.com blev rundsendt til medarbejderne.

Ifølge Morten Juul Nielsen er det muligt at sikre sig internt mod disse ?morsomheder?, hvis man anser dén egenskab ved SMTP-protokollen for at udgøre et it-sikkerhedsproblem.

Men det er ikke et sikkerhedstjek, der bør ligge på mailserver-niveau, mener sikkerhedschefen.

»Der er generel konsensus blandt de softwarefirmaer, der udvikler email-løsninger, at det ikke er i selve e-mail-løsningen, at den sikkerhed skal placeres fra begyndelsen,« siger Morten Juul Nielsen.

Han peger på, at flere af Microsofts infrastrukturpartnere fremstiller add-ons til både Exchange og Outlook, som sikrer mod den omtalte sårbarhed.

»Det er vi naturligvis meget taknemmelige for, fordi vi ikke kan gardere os mod alle tænkelige scenarier i produktet ud af boksen,« siger Morten Juul Nielsen.

Sikkerhedschefen påpeger også, at de fleste phishing-angreb i dag kræver, at offeret for angrebet foretager sig noget aktivt for at aktivere en ondsindet kode. Det kan for eksempel være at klikke på et link i en e-mail eller på Facebook, en bannerreklame eller udfylde en særligt konstrueret formular.

Morten Juul Nielsen fastslår, at langt de fleste phishing-angreb, der for eksempel har til hensigt at høste kreditkortnumre fra intetanende brugere, når at blive standset med de eksisterende sikkerhedsværktøjer, e-mail-udbyderne anvender i dag, før de når frem til e-mail-brugerens pc.

»Man skal se på, hvor stort problemet er, i forhold til hvor mange et phishing-angreb rent faktisk rammer. Der mener jeg, det er vigtigere at oplyse brugerne om, at de ikke skal klikke på den slags links, end at lægge flere lag af sikkerhed ind i mailløsningerne. Det kan gøre e-mail-trafikken mindre smidig og mere besværlig at tilgå for brugerne,« siger Morten Juul Nielsen.

Hostingfirma principielt enig

Hos hostingfirmaet Solido Networks bekræfter sikkerhedschef Henrik Kramshøj, at Henrik Svendsens bekymringer omkring SMTP-protokollen i princippet er reelle nok.

»SMTP er en gammel protokol, der ikke har nogen indbygget sikkerhed. Den er baseret på, at man ganske enkelt stoler på de e-mails, der kommer ind,« siger Henrik Kramshøj.

Sikkerhedschefen er også enig med Henrik Svendsen i, at det er en god idé at verificere afsenderen af en e-mail. Specielt hvis e-mail stammer fra ens eget domæne - eller måske blot ser ud til at stamme fra det.

Henrik Kramshøj mener dog, at der findes flere gode bud på sikkerhedsforanstaltninger, som den it-ansvarlige for virksomhedens e-mailløsning bør kende.

Det gælder for eksempel Sender Policy Framework, SPF, der netop er sat i verden som et bolværk mod phishing og spam.

SPF giver administratoren mulighed for at opsætte en såkaldt SPF-record i DNS, hvori det angives, hvilke hosts der må afsende e-mails fra et bestemt domæne.

Det kan bruges til at tjekke, at en e-mail afsendt fra eksempelvis servicedesk@kommune.dk også stammer fra en host, der er godkendt at domænets administratorer.

»Derudover findes der sådan noget som DomainKeys, som er mere avanceret end SPF. Og det er noget, Microsoft både implementerer og benytter,« siger Henrik Kramshøj.

Efter Henrik Svendsens erfaring er det dog langt fra alle virksomheder, der i praksis gør sig ulejligheden med at sætte sikkerheden omkring e-mailløsningen ordentligt op.

»Det er mit indtryk efter at have arbejdet som konsulent, at mange virksomheder nøjes med den rene e-mailløsning og ikke bruger penge og resurser på at sikre den yderligere,« siger Henrik Svendsen.

Har du selv en holdning til, hvordan virksomhedens e-mailløsning sikres bedst muligt mod phishing? Giv dit besyv med i debatten nedenfor.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Niels Dybdahl

De seneste måneders phishingforsøg hvor nogen udgav sig for at sende fra hhv TDC og PBS viser at SPF faktisk virker. De fleste spamfiltre fjernede emailsne fordi TDC og PBS har SPF-records så det var nemt at se at der var tale om svindel. SPF-records er stort set gratis at sætte op og spamfiltre har de fleste i forvejen. Indtast dit firmas domæne på http://tools.bevhost.com/cgi-bin/dnslookup og se om der står noget med v=spf et sted. Hvis der gør, så har I allerede en SPF-record. Hvis ikke, så sørg for at få det.

  • 0
  • 0
#4 Martin Kofoed

Nej, problemet er vel, at for de fleste MCSE'er er indgangsvinklen til SMTP netop Exchange. Tvivler egentlig på, at man overhovedet behøver at kende de bagvedliggende protokoller.

Det er helt gængs viden, at der med lethed kan dæmmes op for de nemmeste spoofs (lavthængende frugter). SPF-records kombineret med at kræve korrekt HELO-adresse, strict rfc821 envelope, rejecte ukendte hosts, rejecte ens eget hostname som afsender, når mails kommer udefra etc. etc. ... Dertil kan man slå op i CBL'er for til sidst naturligvis at spam-checke. Hvis man kører det ordentligt, er det forbløffende lidt, der ryger igennem til spam-checkeren.

Måske savner Exchange muligheden for at sætte den slags op på en nem måde? Så må det i givet fald være DET, MS skal rette op på.

  • 0
  • 0
#6 Henrik Svendsen

Som jeg forslog Mikkel Meister da vi snakkede sammen, har Microsoft tidligere brugt mange resourcer på at lave en antispam løsning. Både med reverse domain lookup, og med host header value. Dette er selvfølgelig ikke en løsning mod spam, men mod spoofing. Man kunne løse problemet rimlig simpelt. Hver gang exchange modtager en mail fra dens eget domæne, eller alias skal den kontrollerer afsenders ip og sammenligne med sin database over egne mail servere. Er afsender ip ikke på den godkendte liste over mailservere der må sende, kan mailen afvises.

  • 0
  • 0
#7 Henrik Høyer

Som jeg forstår dit forslag så vil du have at mails fra og til samme server skal checkes? Så istedet for at sætte det op via SPF så skal en exch server automatisk kun tillade at mails kommer fra samme server?

Det vil måske gøre det lidt sværere at fishe kolegaer, men det det hjælper jo intet på samarbejdspartnere, kunder, leverandører osv osv.

Under alle omstændigheder forstår jeg ikke at du vil konfigurere det på din egen mailserver, når du kan lave en dns ("v=spf1 mx ~all") TXT record - det tager ikke længere tid???

  • 0
  • 0
#8 Henrik Svendsen

Henrik lad os lige blive enige her ! Jeg taler FOR at man opretter SPF. Min pointe er blot at mange firmaer aldrig får oprettet SPF da de ikke vil betale for det. Derfor mener jeg at Microsoft burde lave dette simple check. Og du har ret angående at man stadig kan phishes fra andre sider, men nu handler det ikke om den problemstilling. :o)

  • 0
  • 0
#9 Martin Kofoed

Hver gang exchange modtager en mail fra dens eget domæne, eller alias skal den kontrollerer afsenders ip og sammenligne med sin database over egne mail servere.

Skal jeg forstå det derhen, at Exchange ikke kan dette ud af æsken? I så fald er det jo DET, du med rette kan bede Microsoft om at implementere.

Det er en one-liner i Postfix' main.cf.

  • 0
  • 0
#11 Rene Madsen

Microsoft mente "desværre" ikke at det var deres problem. :o(

Det er netop fordi det IKKE er deres problem. Det er da jordens dårligste undskyldning at virksomhederne ikke vil betale for at sætte en SPF record ind i deres DNS opsætning. Det er bundet i at de har en leverandør som tydeligvis ikke er deres opgave voksen, da indsættelse af et SPF record tager under 10 min i et hvilket som helst DNS setup.

Hvorfor skal Microsoft løse noget som den IT ansvarlige kan løse, hvis vedkommende var kompetent nok til at løse eller få sin underleverandør til at løse?

  • 0
  • 0
#13 Henrik Svendsen

Det kan være... Jeg havde faktisk ikke forstillet mig at det ville blive så personlig et emne rettet mod mig. Forsøgte faktisk at skabe lidt debat, men jeg kan se at det ikke er lykkedes. Desværre... :o( Men i har selvfølgelig ret til en anden mening end jeg. Dog mener jeg stadig at man skal være opmærksom på svagheden og NETOP sørge for at få vedkommende der vedligeholder serverparken til at opsætte SPF. Det ER værd at betale for... :o)

  • 0
  • 0
#14 Niels Dybdahl

Min pointe er jo netop at mange firmaer ikke vil betale deres it folk for at bruge tid på at opsætte SPF eller Domain keys.

Det burde bare være en selvfølge at når man specificerer hvilke maskiner der kan modtage emails til et domæne (MX), så skriver man også hvilke maskiner der kan sende emails for det domæne (SPF). Det burde ikke koste ekstra.

Der er selvfølgelig ekstra arbejde med at ændre SPF når man ændrer sine mailservere, men ændring af mailservere er normalt forbundet med væsentligt højere omkostninger end tilpasning af SPF-recorden.

Problemet er nok mest af få firmaer til at indføre SPF på et tidspunkt hvor de ikke alligevel skal lave noget om i maskinparken. Men det er stadig meget billigere at tilføje en SPF-record end at opgradere til en nyere mailsoftware som så understøtter en anden form for check af afsender.

  • 0
  • 0
#16 Henrik Høyer

Jeg havde faktisk ikke forstillet mig at det ville blive så personlig et emne rettet mod mig

Jeg undskylder hvis du har opfattet det som angreb mod dig, det er det ikke. Men når man stikker snuden frem skal man jo også kunne tåle lidt kritik ikk ;-)

Forsøgte faktisk at skabe lidt debat, men jeg kan se at det ikke er lykkedes.

Jo da! Jeg vil bare hellere dreje debatter over mod hvordan du, jeg og alle andre kan hjælpe med at få opsat spf på danske domæner.

Og jeg mener det skam seriøst; grib knoglen og ring til KL, med din titel burde du da kunne få deres ansvarlige it folk i tale

  • 0
  • 0
#17 Per Laursen

Der er desværre ikke mange som benytter SPF på deres indgående mailservere.

Der er ydermere mange af dem som benytter SPF som har konfigureret til 'Softfail' og ikke 'Fail'.

SPF nytter desværre ikke meget når 90% af alle servere end ikke checker for SPF records og de som checker så ikke blokerer fordi SPF er sat til Softfail. Fedt nok at få en advarsel i loggen, men man har desværre allerede brugt båndbredde og CPU på at få den defekte mail ind i antivirus og spamfiltre osv. før den stoppes.

Det er synd at dette simple værktøj benyttes så lidt. Argumentet om at firmaer ikke vil betale for det køber jeg ikke. Det er ikke et spørgsmål om at de skal tage stilling til om de skal have det eller ej. IT afdelingen skal bare tage det for givet at de vil have det og indregne det i tilbuddet fra starten.

Tænk tanken : Der ikke er nogen som kan modtage en mail med falsk afsender.

Man fristes til et lille WOW ;-)

  • 0
  • 0
#18 Daniel Schledermann

Jeg døjer lidt med at se hvorfor dette er et problem i SMTP, og ikke blot et udtryk for en naiv opsætning.

Eksemplet med at en ekstern udgiver sig for at være en bestemt intern person burde kunne undgås på flere måder. For det første burde man kun acceptere relay fra ip-adresser man kender. Det er slet ikke nødvendigt med SPF i dette tilfælde.

Er det af forskellige årsager ikke praktisk, fx. fordi man har for mange lokationer, hjemmearbejdspladser mv., bør man kun acceptere relay fra en SMTP-klient der er logget ind. Hvis man endelig er nervøs for at medarbejderne udgiver sig for at være hinanden, så findes der også midler mod det. Man bør stadig have SPF-kontrol og SPF-records, men da ikke for at blokere for "intern fishing".

Nu kender jeg ikke så meget til Exchange, så jeg skal ikke kunne udtale om hvorvidt det lader sig gøre overkommeligt der, men i Postfix er det meste af dette ganske trivielt.

Man behøver jo ikke skifte Exchange helt ud. Man kan jo nøjes med at beskytte den med en Postfix som mailrelæ.

  • 0
  • 0
#19 Henrik Svendsen

Det har intet med relay rettigheder at gøre på Exchange siden. Det der er problemet er at man fra et hvilket andet sted i verden kan få lov til at sende mail til modtageren, og når exchange modtager mailen laver den et opslag i Global Catalog. Her verificerer den at brugeren eksisterer, og får mailen til at se ud som om at den kom fra en intern bruger. Relay har noget at gøre med om du må bruge exchange serveren som afsender server, og det er ikke tilfældet her.

  • 0
  • 0
#20 Daniel Schledermann

Problemet ville ikke være der hvis man havde korrekt kontrol på, om folk der sender mails ud på dine (dit DNS-domænes) vegne, til dig selv(!), på en server du selv kontrollerer (!!!), kommer fra et godkendt netværk eller er logget ind. Det kan ordnes uden SPF.

Om modtageren er lokal eller ej er jo en detalje.

Som jeg ser det: 1. Godkendte netværk -> pass 2. Godkendte brugere -> pass 3. Helo = ..ditdomæne.dk -> reject 4. Sender = .@ditdomæne.dk -> reject ... herefter kan man behandle mailen på normal vis.

Er dit setup mere indviklet end som så eller overser jeg noget?

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