Teleselskabs webformular misbrugt til at bombardere Version2 med smæde-mails

24. januar 2017 kl. 05:1515
Både 3 og Oister er igang med at opdatere deres hjemmesider, efter en webformular er blevet brugt til at sende hundredvis af mails til Version2.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Da Version2's medarbejdere i går, mandag, åbnede deres indbakker, blev de mødt af hundredvis af spam-lignende mails. De er sendt ved at misbruge en webformular hos teleselskabet Oister.

»Dette er et værk af en ukendt person, som har begået en bevidst chikanerende ondsindet handling. Vi kan konstatere, at han/hun ikke har haft adgang til vores systemer, men har påført os chikanen udefra. Lige nu er vi i gang med undersøgelser for at identificere den pågældende person,« oplyser Rikke Juul Hansen, pressechef hos Oisters moderselskab, 3, i en mail til Version2.

Sagen er indberettet til Center for Cybersikkerhed, hvilket ifølge Rikke Juul Hansen skulle være standardprocedure i den slags sager.

Emne-feltet i de pågældende mails, som Version2 er blevet bombarderet med, har indeholdt forskellige negative udsagn om Oister, mens selve mail-indholdet har haft karakter af en kvittering for modtaget mail.

Artiklen fortsætter efter annoncen

Et kig i de tekniske mail-info viser, at de mange mails har bestået et tjek i forhold til både DKIM og SPF.

Ifølge en beskrivelse hos Google er DKIM (DomainKeys Identified Mail) et tjek, der gør det muligt for en modtagende server via en private/public-key-struktur at verificere, at en mail faktisk er afsendt fra det domæne, der fremgår af mail-headeren.

Sender Policy Framework

Sender Policy Framework (SPF) benytter DNS til at udgive en liste over de servere, der er godkendt til at sende mails fra det pågældende domæne.

Modtagerens mailserver kan dermed kontrollere via DNS, om en mail er sendt fra én af de servere, der er registreret.

Uden SPF indebærer e-mailprotokollen SMTP, at afsenderen kan angive en vilkårlig mailadresse som afsender og sende den fra en vilkårlig server. Med SPF er det muligt at tjekke, om afsender og server passer sammen.

Kilde: Wikipedia Tekst: Jesper Stein Sandal

DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) kan verificere afsenderen ved hjælp af en digital signatur. En offentlig nøgle knyttes til domænet i DNS.

Både e-mailens indhold og header bruges til at generere kryptografiske hash-værdier, som signeres af afsenderens mailsystem. På den måde er det muligt at validere, at den pågældende mail er blevet signeret af det rigtige mailsystem.

Modtageren kan validere den digitale signatur ved hjælp af den offentlige nøgle, der er udgivet via DNS.

Kilde: Wikipedia Tekst: Jesper Stein Sandal


SPF (Sender Policy Framework) er ifølge en anden beskrivelse hos Google en type DNS-record, der identificerer, hvilke mailservere der har lov til at sende mails på vegne af et domæne.

Formålet er at forhindre spammere i at sende beskeder med en forfalsket FROM-adresse, der misbruger et legitimt domæne.

Men i det konkrete tilfælde har hverken SPF eller DKIM altså forhindret et mail-bombardement, der uden videre er strøget gennem spam-filteret.

Webformular til kundeservice

Forklaringen er, at de mange mails med negative udsagn rettet mod Oister faktisk er sendt via en legitim mail-service hos teleselskabet.

Artiklen fortsætter efter annoncen

Det er sket ved at misbruge en kontaktformular på Oisters hjemmeside, der er tiltænkt henvendelser til kundeservice.

»En kontaktformular på oister.dk har søndag aften været udsat fra chikane fra en ukendt person. Her har vedkommende sat en ’bot’ op til at udfylde hundredvis af henvendelser i en webwidget til hjælp og kontakt på forsiden af sitet med forskellige e-mailadresser,« fortæller Rikke Juul Hansen og fortsætter:

»Kontaktformularen har automatisk sendt en bekræftelse på modtagelsen tilbage til den indtastede mailadresse med samme emnefelt, som blev indtastet i formularen, og med Oisters Kundeservice som afsender.«

Hun fortæller videre, at den pågældende kontaktformular på oister.dk blev pillet ned mandag morgen.

Artiklen fortsætter efter annoncen

»Formularen lå i en widget i form af en gul knap, hvor der stod ’Hjælp’, og som poppede op, når man bevægede sig rundt på sitet,« oplyser Rikke Juul Hansen.

I den forbindelse har Oister også lukket andre webformularer på oister.dk, fortæller hun.

Ingen Captcha

Når misbruget i første omgang har kunnet lade sig gøre, skyldes det, at den pågældende kontaktformular ikke har haft en Captcha-lignende funktionalitet.

Captcha står for Completely Automated Public Turing-test to tell Computers and Humans Apart og har til formål at forhindre, at eksempelvis en webformular kan udfyldes af automatiseret computerkode og misbruges til eksempelvis spam-udsendelse.

Flere kender nok Captcha i form af diverse bokse med mere eller mindre ulæselig tekst, som skal indtastes manuelt, for at webformularen kan sendes af sted. Google har en lignende løsning, der har vundet udbredelse flere steder, som virksomheden kalder reCaptcha

Her er det nok at hakke af i et felt med teksten 'Jeg er ikke en robot'. Google fortæller mere om projektet her.

Oister bruger faktisk reCaptcha i forbindelse med en anden kontakt-formular på sitet, men det har altså ikke været tilfældet i forbindelse med den formular, der er blevet misbrugt.

I forhold til, hvorfor denne formular ikke har været beskyttet, oplyser Rikke Juul Hansen:

»Oister har valgt dette for at levere en bedre kundeoplevelse og hurtigere adgang til hjælp eller kontakt. På baggrund af dagens episode er Oister nu i gang med at indsætte en sådan robot-beskyttelse på alle kontaktformularer. I mellemtiden er der lukket for henvendelser til Oister via forsidens webwidget.«

Også hos moderselskabet 3 er der sat gang i en lignende opdatering i forhold til webformularer på 3.dk, oplyser Rikke Juul Hansen.

15 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
15
25. januar 2017 kl. 09:31

Når det så er sagt, så er det mærkeligt at nævne at mailen gik igennem SPF og DKIM, det er jo logisk, mailen kommer jo fra Oister, hvilket de jo også selv siger... i samme omgang kan i evt. nævne om serveren var opdateret til seneste version, og om Oister sysadmin drikker gevalia kaffe.

I modsætning til kaffemærker og versionen på en unavngiven server, så har både SPF og DKIM direkte relation til mail-sikkerhed. I det lys synes jeg egentlig det giver fint nok mening at nævne, at de to sidstnævnte teknologier var implementerede i forbindelse med det mail-bombardement, vi blev udsat for, og som - sikkert fordi SPF og DKIM passede - ikke blev stoppet af vores mail-filter.

Desuden gjorde SPF- og DKIM-informationerne det lidt lettere at ringe til Oister/3 og med nogen overbevisning sige noget i retning af: »Vores gæt er, at nogen har misbrugt en webformular på oister.dk«

Når det er sagt, så medgiver jeg gerne - jeg mener heller ikke artiklen påstår andet -at nøgleteknologien her ikke er SPF/DKIM (eller DMARC), men snarere en velfungerende Captcha-implementering. Jakob - V2

13
25. januar 2017 kl. 02:36

Morer mig over diskussionen om SPF, DKIM og DMARC... som er fuldstændig irrelevant i dette tilfælde. Der er ikke tale om spoofing, det er bare en formular som nemt kunne udnyttes til at oprette tonsvis af sager, som automatisk sender en mail fra Oister. Alting fungerede som det skulle, der var bare en spade der ikke kunne nære sig, så nu må de indføre en captcha eller lign.

Når det så er sagt, så er det mærkeligt at nævne at mailen gik igennem SPF og DKIM, det er jo logisk, mailen kommer jo fra Oister, hvilket de jo også selv siger... i samme omgang kan i evt. nævne om serveren var opdateret til seneste version, og om Oister sysadmin drikker gevalia kaffe.

12
24. januar 2017 kl. 23:55

I forhold til de pågældende Oister-mails, som er modtaget via Gmail, så giver et kig i 'vis oprindelig'-mail-informationerne umiddelbart kun oplysninger om pass af SPF og DKIM - ikke noget om DMARC, som det er tilfældet med dit screenshot-eksempel. Jakob - V2

Men burde I så ikke forholde Jer kritisk til det der mangler og ikke det de har styr på? Hvis kun Spf og Dkim kommer frem, men ikke Dmarc - så vil det da være et oplagt udgangspunkt som journalist at stille et spørgsmål. "Jeg kan se at I har nogle udfordringer med jeres email setup og samtidigt at I ikke har implementeret Dmarc. Ville det ikke hjælpe Jer at kunne få Dmarc feedback fra fx Hotmail og Google for at få et bedre overblik over afsendte mails fra jeres domæne? Som teleselskab må I jo have mange forskellige systemer der afsender mails fra jeres domæne?"

11
24. januar 2017 kl. 23:37

@Jan

Det er ikke så irreterende for Version 2, men jeg formoder at Zendesk har noget sagsstyring, og det er jo så flere hundrede sager som de skal sidde og rydde op i, de kan jo ikke slette dem alle, der kunne være nogen rigtige sager imellem, så en medarbejder skal bruge tid på det, det koster penge. Så en form for ondsindet handling/vandalisme syntes jeg godt man kan kalde det.

9
24. januar 2017 kl. 15:59

Helt enig - men du siger ikke hvorfor I aldrig nævner DMARC. Gmail, Hotmail, Yahoo og flere understøtter det fint og nu du selv nævner Google som kilde, så er de da meget pro Dmarc. Hvis du åbner kilden til en mail i Gmail, så er det netop spf, dkim og dmarc de skriver om er valid eller ej.

Tak for et konstruktivt input. Det kunne sagtens give mening at gå i detaljer med DMARC, SPF og DKIM i en selvstændig artikel om emnet.

Når Oister-artiklen kommer ind på SPF og DKIM er det fordi, disse informationer dukkede op i forbindelse med vores opklaringsarbejde. Og så virkede det naturligt kort at omtale de to teknologier.

I forhold til de pågældende Oister-mails, som er modtaget via Gmail, så giver et kig i 'vis oprindelig'-mail-informationerne umiddelbart kun oplysninger om pass af SPF og DKIM - ikke noget om DMARC, som det er tilfældet med dit screenshot-eksempel. Jakob - V2

8
24. januar 2017 kl. 15:06

Dermed ikke sagt, at du ikke har en pointe, men desværre fortaber den sig i den skingre tone, som igen og igen præger dine debatindlæg på Version2, så snart DMARC ikke nævnes i en artikel.

Helt enig - men du siger ikke hvorfor I aldrig nævner DMARC. Gmail, Hotmail, Yahoo og flere understøtter det fint og nu du selv nævner Google som kilde, så er de da meget pro Dmarc. Hvis du åbner kilden til en mail i Gmail, så er det netop spf, dkim og dmarc de skriver om er valid eller ej.

https://goo.gl/Q4vGlX

Nu er det hverken første eller sidste artikkel omkring emails - hvorfor har I ikke noget grund research I kan trække på til den slags artikler? Hvis det var en enkelt artikkel omkring et emne, så fair nok at I ikke afsætter en masse tid. Jeg kan ikke se grunden til her at nævne 2 ud af 3 teknologier, når det netop er den 3. der gør de 2 første brugbare.

Dog er mit frustrations niveau over jeres niveau ikke på niveau med Henrik Schack :-)

7
24. januar 2017 kl. 13:22

Man må da håbe sådan en taber får en straf som kan mærkes - Kunne dog ikke lade være med at smågrine for mig selv over at der findes sådan personer som ikke selv kan se de er syge i hovedet.

Hold nu op en taber!!

6
24. januar 2017 kl. 12:36

Et forsøg på et svar mest til Peter Makholm: Jeg forstår artiklen derhen, at nogen har sat en robot til at rapportere problemer til Oyster via bemeldte webformular. Som afsender-adresse har man så sat Version2.

Funktionen i Oysters system er så at de sender en kvittering til afsenderen - sikkert noget i retning af 'Tak for din henvendelse'. Denne kvittering sendes så til Version2, der jo står som 'afsender', selv om det ikke er dem, der indskrevet formularen.

I og med at denne kvittering sendes fra Oysters systemer, vil ingen af de bemeldte mail-sikkerhedssystemer fange kvitteringen - det er jo en legitim kvittering fra en legitim afsender og med et indhold, som vil passere enhver spam-tjeneste.

Sandsynligvis har nogen haft lyst til at sætte fokus på risikoen ved at have webformularer, der ikke laver bot-kontrol (Captcha eller lignende). Og så er det da en god joke at sætte netop Version2 på som afsender - på den måde sikrer man sig, at de tager emnet op.

Så nu skal Oyster igang med at gennemgå deres weblogs for at finde den IP-adresse, der er brugt til at indskrive henvendelser. Om de er heldige at 'forbryderen' har brugt sin egen maskine fra sin egen IP-adresse til formålet skal jeg naturligvis ikke kunne sige - at sætte et BOT-netværk til at løse opgaven synes som en større opgave, men jeg har egentlig aldrig prøvet denne arbejdsmetode, så måske er det meget let.

At Rikke Juul Hansen så omtaler sagen som 'en bevidst chikanerende ondsindet handling' virker som overkill - 'hundredevis af mails' kan være alt fra 100 til 999 mails - og selv om det da er irriterende at skulle slette 1000 mails, så er det altså ikke nogen 'ondsindet' handling. Hvis 'forbryderen' findes, kan han jo passende få lov at sende et tilsvarende antal mails - indskrevet én af gangen. F.eks. med teksten 'Jeg må ikke genere andre med spammails' :)

Jan Ferré

5
24. januar 2017 kl. 11:26

Det ville være interessant at høre fra Zendesk, som Oister benytter, hvad de har tænkt sigt at gøre.

Lidt research viser at Zendesk ikke tilbyder captcha på formularer til oprettelse af tickets - faktisk kun på formularer til oprettelse af brugere.

Oister er ikke de eneste der har større problemer med mange spam posts. Se f.eks. https://support.zendesk.com/hc/en-us/community/posts/205564218/comments/226361868.

4
24. januar 2017 kl. 10:27

I så fald forstår jeg ikke hvor DKIM og SPF kommer ind i sagen. Der bliver ikke sendt en mail på vegne af version2.dk, men version2.dk modtager en mail der reelt set er afsendt af oister.dk.

Hej Peter. Det kommer som sådan ikke ind i sagen på anden vis end en konstatering af, at de sendte mails med Oister-kundeservice som afsender har bestået et DKIM og et SPF pass. Som det fremgår af artiklen, så skyldes det, at de pågældende mails er sendt via en legitim Oister-mail-tjeneste - den sårbare webformular. Jakob - V2

3
Redaktionschef -
24. januar 2017 kl. 09:43
Redaktionschef

Kære Henrik,

Artikelteksten, som den fremstår, lader ikke til at være i modstrid med beskrivelserne hos hverken Google eller Wikipedia. Begge kilder, som vi anser som troværdige i forhold til det specifikke emne.

Hvis du mener, der er noget, der er lost-in-translation i den forbindelse, er du velkommen til at ringe eller sende en mail til redaktionen, så kan vi tage en konstruktiv dialog.

Dermed ikke sagt, at du ikke har en pointe, men desværre fortaber den sig i den skingre tone, som igen og igen præger dine debatindlæg på Version2, så snart DMARC ikke nævnes i en artikel.

Og det er uden for diskussion rigtig dårlig stil, når du opfordrer til misbrug af Version2's domæne, hvorfor vi har slettet den del af dit debatindlæg.

Vh Henning Mølsted, redaktør Version2

2
24. januar 2017 kl. 09:33

Jeg er ikke helt sikker på at jeg forstår hændelsesforløbet.

Er det korrekt forstået at "angriberen" har udfyldt en formular på oister.dk og i denne formular har skrevet en version2.dk-adresse som kontakt-adresse. Dernæst har Oisters system sendt en kvitering til kontakt-adressen?

I så fald forstår jeg ikke hvor DKIM og SPF kommer ind i sagen. Der bliver ikke sendt en mail på vegne af version2.dk, men version2.dk modtager en mail der reelt set er afsendt af oister.dk.

1
24. januar 2017 kl. 08:01

Kære version2 I burde få jeres artikler der omhandler email authentication faktatjekket af en person med kendskab til email authentication... inden i offentliggør dem. Denne artikel er i sin nuværende form mere vildledende end oplysende.

SPF har relation til MAIL FROM også kaldet Senderenvelope eller returnpath adresse. SPF kan på ingen måde ved egen kraft gennemtvinge en sammenhæng mellem den synlige From: adresse og MAIL FROM adressen. SPF er derfor uden værdi i forhold til at forhindre spoofing/phishing.https://tools.ietf.org/html/rfc7208#section-1.1.3

Jeres beskrivelse er DKIM er egentlig fin nok.

I glemmer det væsentlige, nemlig hvordan man i praksis forhindrer spoofing/phishing. DMARC gør op med de mangler SPF og DKIM har, og etablerer en sammenhæng mellem MAIL FROM, FROM og det domæne der anvendes i DKIM signaturen.

[forkortet af redaktionen]