‘Sikker’ dansk mailtjeneste stod pivåben for enhver: »Jeg kan kun stå med bøjet hoved«

Illustration: Jane Kelly, BigStock
Et sikkerhedshul i en dansk mailløsning, der bruges af blandt andet kommuner, forsikringsselskaber og advokater, gjorde det muligt for enhver at tilgå dokumenter og filer. Sagen er meldt til Datatilsynet.

Alle og enhver har kunnet tilgå dokumenter og filer med følsomme informationer fra et stort antal kommuner, forsikringsselskaber, advokatfirmaer og mange andre virksomheder og institutioner, der har benyttet den danske tjeneste sikker@mail til at sende krypterede og signerede mails.

Selv uden at være logget på en af tjenestens servere har det været muligt at åbne vedhæftede dokumenter og filer ved at manipulere med URL’en.

»Det er rigtig, rigtig trist og kedeligt. Jeg kan kun stå med bøjet hoved, andet kan jeg ikke sige,« siger Jens Winther Wullf, der er CEO i virksomheden Logiva, som står bag mailtjenesten, til Version2.

Logiva blev 16. januar omkring kl. 11.00 gjort opmærksom på sikkerhedshullet i sin webtjeneste SikkerMailBox (en del af sikker@mail, red.) og lukkede kort tid efter ned for alle sine servere, der senere på dagen kom op at køre igen.

Mailtjenesten har ifølge Logiva mere end 350.000 brugere fordelt på en lang række kunder – herunder 48 kommuner – og Logiva driver i alt 46 servere til mailtjenesten, hvoraf lidt mere end 30 servere kører med SikkerMailBox.

Ifølge Jens Mønster Sørensen, der er ansvarlig for udviklingen af sikker@mail, kan man ikke nødvendigvis udlede antallet af berørte kunder fra antallet af servere, da antallet af kunder pr. server varierer meget.

Han afviser med henvisning til kontraktforhold at oplyse, hvor mange kunder der er berørt.

»Det er langtfra alle kunder, der har været berørt af sikkerhedshullet. Kunderne er fordelt på flere servere, og den berørte feature har ikke været slået til på alle,« siger Jens Mønster Sørensen til Version2.

Anmeldt til Datatilsynet

I en mail, som Version2 er i besiddelse af, og som blev sendt rundt til de berørte kunder, da sikkerhedshullet blev opdaget, opfordrer Logiva til at melde sikkerhedshullet som et »potentielt sikkerhedsbrud« til Datatilsynet.

Logiva oplyser desuden til Version2, at man også selv har anmeldt sikkerhedshullet.

Kan ikke se, om sårbarhed har været udnyttet

Sikkerhedshullet har eksisteret siden i hvert fald midten af 2018, og Logiva har reelt ikke mulighed for at sige noget kvalificeret om, hvorvidt nogen har udnyttet det til at få adgang til kundernes oplysninger.

Data på serverne slettes løbende, og det er kun muligt at tilgå vedhæftede filer og dokumenter fra serverne fra 30 dage tilbage i tiden.

Det samme gør sig gældende for logfilerne. Logiva vurderer på baggrund af analyser af disse logfiler, at der i de 30 dage, før sikkerhedshullet blev opdaget, ikke har været tegn på, at uvedkommende har udnyttet det.

Logiva afviser, at Google har indekseret indholdet, selvom det har kunnet tilgås af alle og enhver, der indtastede et korrekt URL.

It-sikkerhedsvirksomheden Improsec opdagede sikkerhedshullet den 16. januar og kontaktede kort efter Logiva. CEO i Logiva, Jens Winther Wulff, er glad for, at det var en »god hacker«, der gav den ellers kedelige information om sikkerhedshullet videre.

»Det har givet anledning til at kigge på vores interne processer og på, hvordan vi internt kan stramme op, og så vil vi få nogen udefra til at angribe vores system. Man kan aldrig give 100 procent garanti for, at det ikke vil ske igen, men vi vil gøre vores bedste for det,« siger Jens Winther Wulff.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (27)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
René Nielsen

.. Nu havde ingen heldigvis noget at skjule, lucky us ! :-)

Som overskriften lyder, er jeg lidt forundret over hvad konsekvenserne egentlig er ved disse fejltrin. Hvornår bliver det stort nok, til der også er tale om fængelsdomme oveni millionbøderne*?
(hvis det da ikke hedder milliard nu om dage)

Med et retmæssigt setup med stråmænd og hvad jeg ellers ikke ved, kan det da syntes at være en ret lukrativ forretningsmodel og ikke mindst produkt, som efterhånden har større værdi end sølv og guld.

Jeg mener blot, det jo ikke kun hr. og fru. hvem-som-helst man får informationer ud af her, der tale om større offentlige og private foretagende og dermed information (data) som kan have altafgørende betydning ifht. forretningens strategi eller ultimativ sikkerhed.

  • 17
  • 0
Christian Nobel

.... hvis ikke "foregangslandet" Danmark i al sin forhippelse på at blive "verdens bedste til digitalisering" hvorved man har bragt sig selv ned på et tredjeverdens plan, så kunne de forgangne 20 år være blevet brugt til noget fornuftigt --- eksempelvis at indføre en ægte digital signatur.

  • 15
  • 0
Thomas Nielsen

Det som igen igen er værd at bemærke og forhåbentlig bemærke højt nok til at politikerne faktisk hører det, er at systemer ikke er sikre. Period. Der er altid en eller anden fejl. Uanset om konsekvensen så er personlig skamfølelse eller millardbøder, så forbliver disse systemer fejlbehæftede. Derfor er genbanker og overvågning og [indsæt din egen IT-kæphest her] og, og, og... bare ikke gangbare dagsordener. At det er så svært at forstå, kan kun henføres til at politikerne er tonedøve og vi ikke er i stand til at hæve stemmen nok.

  • 18
  • 0
Mogens Lysemose

Men der er da forskel på om det er en nybegynder-tåbelighed som dette design elleren ukendt sikkerhed i et tredjeparts krypteringsmodul som man ikke havde en chance for at forudse.

Du kan heller ikke beskytte din bil fuldstændig mod indbrud, men alligevel det er da tåbeligt at lade den stå ulåst med nøglerne i tændingen...

  • 6
  • 3
Mogens Lysemose

google-indeksering kræver blot at
1) googles crawlere støder på linket et sted og
2) at sitet ikke har lagt en fil på websitet som høligt beder crawlere om ikke at indeksere hele eller dele af sitet. Ikke alle crawlere er høflige og imødekommer den slags, men google plejer.

Der findes mange blackhat crawlere og scriptkiddies som trawler sites for at finde sårbarheder. Da jeg var webserveradmin i 2006 blev serverne "testet" systematisk med scrpts/bots flere gange i minuttet; det er eksploderet siden.

  • 14
  • 0
Anne-Marie Krogsbøll

Tak for svar, Mogens Lysemose.

Hvis jeg forstår det rigtigt, så er Logiva nok ude i noget ønsketænkning her?

at sitet ikke har lagt en fil på websitet som høligt beder crawlere om ikke at indeksere hele eller dele af sitet. Ikke alle crawlere er høflige og imødekommer den slags, men google plejer


Mon det er almindelig praksis i danske offentlige myndigheder og firmaer at sikre sig på den måde?

  • 5
  • 0
Povl H. Pedersen

Når så mange højtprofilerede kunder anvender dem, så undrer det mig at der ikke har været brugt kompetente kræfter til at teste løsningen tidligere. Eksterne kræfter er dog ingen garanti for at fejlen ville være fundet.

Og SMS koden burde da have forhindret adgang til uautoriserede dokumenter.

Fet er vel netop disse store kunder der forlanger en ISO 27001, som er et dokument der er langt fra den tekniske løsning, og intet siger om den reelle sikkerhed. Og hvis bare dette papir er OK, og man måske endog er certificeret, så mener alle at de har vasket hænder.

Når det er sagt, så er det også svært at kontrollere sine underleverandører. Hvornår er deres sikkerhed tilstrækkelig ? Eksterne auditører og standarder er typisk ikke i stand til at vurdere tekniske løsninger, kun processor og retningslinier. CIS 20 (tidligere SANS 20) er det tætteste man kommer på noget der måler på implementering af reel sikkerhed. Deres punkt 20 er faktisk pen-test og red-teaming. Den har tidligere været en del af krav-katalog fra statens IT til oursourcing leverandører. Det er dog de færreste der har fuld styr på hele CIS 20.

Hvis man vil lave gæt-en-url, så skal den være vilkårlig, og UUID anvendes mange steder med stor success. Der er så stort et udfaldsrum, og så bred en distribution at brute-force typisk ikke vil give et udbytte der står mål med indsatsen, selvfølgelig afhængig af data.

UUID er dog "kun" 128 bit (32 betydende oktetter). Men der kan implementeres request throttling og andet sikkerhed ovenpå, ligesom en kort levetid for data også hjælper. Men så er vi ude hvor supporterende teknik nok er udenfor den rene udviklers ansvarsområde, og devsecops en nødvendighed.

  • 4
  • 1
Martin Storgaard Dieu

Blot lige for at tilføje en reference.

Threat Agents/Attack Vectors: Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.
Security Weakness: Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers. Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs PUT, etc), controller, direct object references, etc.
Impacts: The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record. The business impact depends on the protection needs of the application and data.

  • 1
  • 0
Martin Storgaard Dieu

Hvis man vil lave gæt-en-url, så skal den være vilkårlig, og UUID anvendes mange steder med stor success. Der er så stort et udfaldsrum, og så bred en distribution at brute-force typisk ikke vil give et udbytte der står mål med indsatsen, selvfølgelig afhængig af data.

Hvis man følger RFC 4122, så er det ikke det bedste råd:

Do not assume that UUIDs are hard to guess; they should not be used
as security capabilities (identifiers whose mere possession grants
access), for example. A predictable random number source will
exacerbate the situation.

  • 8
  • 0
Mogens Lysemose

Hvis jeg forstår det rigtigt, så er Logiva nok ude i noget ønsketænkning her?


mjah, de kan have ret mht google hvis de har lagt den fil på websitet. Det svarer det til at skrive "adgang forbudt for uvedkommende", og det holder nysgerrige men lovlydige personer væk (google etc), men næppe indbrudstyve osv.

Do not assume that UUIDs are hard to guess; they should not be used
as security capabilities (identifiers whose mere possession grants
access)

præcis, hvis sessionen/ forespørgslen f.eks. flytter fra danmark til Kina på få timer er der nok noget galt... vi overvejede helt at blokere for Kina og Rusland eftersom vi kun havde danske kunder og næsten kun havde suspekte forepørgsler derfra... men der kunne jo være en på ferie eller forretningsrejse, så det virkede urimeligt.

  • 4
  • 0
Dennis Krøger

mjah, de kan have ret mht google hvis de har lagt den fil på websitet. Det svarer det til at skrive "adgang forbudt for uvedkommende", og det holder nysgerrige men lovlydige personer væk (google etc), men næppe indbrudstyve osv.


For at en crawler finder noget, kræver det stadig at der har været en måde at finde et link til stedet. Og med mindre der linkes internt mellem dokumenter, er det kun gældende for det link.

Worms åbner heller ikke tilfældige sider, de prøver allerede kendte sårbarheder (og eventuelle variationer heraf). Ellers ville de bruge timer eller dage på hvert site, i stedet for at inficere så mange som muligt.

Med mindre der har været omstændigheder der gør at en crawler har har haft grund til at tjekke links, har Logiva temmelig sikkert ret.

... Det gør det dog ikke til en mindre tåbelig sårbarhed.

  • 3
  • 0
Mogens Lysemose

For at en crawler finder noget, kræver det stadig at der har været en måde at finde et link til stedet.

jeg mener vi opdagede at en af gratis-mailsne satte bots til at besøge links i mails. jeg husker ikke om det var gmail eller hotmail eller andre, men de begyndte at besøge "skjulte" demosites når vi udviklede nye websites til kunder og sendte dem linket...
jeg ved ikke om de stadig besøger links i kunders mails, jeg syntes det var ufint at "skjulte" sites dukkede op som søgeresultater pga indhold i en personlig mail...

  • 4
  • 0
Martin Storgaard Dieu

de begyndte at besøge "skjulte" demosites når vi udviklede nye websites til kunder og sendte dem linket...

Det er typisk "preview" funktionen på samme måde som LinkedIn, Twitter og Facebook gør det. Jeg ved at hotmail/outlook har gjort det. Microsoft Teams gør det stadig som standard, når man sender links til hinanden. Før at man kan se et preview, så bliver den nødt til at besøge websitet.

  • 4
  • 1
Daniel Lindholm

Glem ikke at mange brugere frivilligt har installeret et eller flere plugins i deres browser som indsamler alle de url’s som de besøger til brug for statistik og/eller videresalg. Det være sig Avast, WOT eller andre ‘sikkerheds’-plugins. Der har tidligere været flere artikler om det på Version2.
Så derfor må en ‘hemmelig’ url ALDRIG stå alene som en sikkerhedsmekanisme.

  • 9
  • 0
Jørgen Elgaard Larsen

Når så mange højtprofilerede kunder anvender dem, så undrer det mig at der ikke har været brugt kompetente kræfter til at teste løsningen tidligere


Kunder med kompetente kræfter behøver ikke usikker@mail.

Jeg kiggede på et tidspunkt på deres Outlook-løsning. Den lod primært til at være en plugin, der kan spørge usikker@mail, om modtagerens domæne også er kunde hos usikker@mail - eller om deres mailserver understøtter SSL.

Det lader til, at deres definition af "sikker" er, at mailserverne taler sammen krypteret.

Det er bedre end klartekst, men jeg ville ikke selv betegne det som "sikkert".

Mit indtryk er, at usikker@mail er en fin løsning til dem, der gerne vi kunne fraskrive sig ansvaret og sige, at de sender "sikker" mail - men egentlig ikke interesserer sig for det.

  • 4
  • 0
Simon Mikkelsen

Det er rigtig skidt at en så fremtrædende tjeneste som sælger sig selv på sikkerhed har haft en så banalt hul. De burde have haft kørt penetration tests som havde fanget den. Måske har de haft gjort det, men hullet er nyt?

Når det er sagt har de reageret korrekt: Lukke ned, lukke hullet hurtigt og gøre de rigtige opmærksomme på hullet. Ikke noget med at benægte eller sagsøge.

Vi kan håbe at man tilige har lært af episoden - det vil det være nød til for.

  • 4
  • 0
Sune Marcher

jeg mener vi opdagede at en af gratis-mailsne satte bots til at besøge links i mails. jeg husker ikke om det var gmail eller hotmail eller andre, men de begyndte at besøge "skjulte" demosites når vi udviklede nye websites til kunder og sendte dem linket...
jeg ved ikke om de stadig besøger links i kunders mails, jeg syntes det var ufint at "skjulte" sites dukkede op som søgeresultater pga indhold i en personlig mail...


Det synes jeg nu egentligt er helt fint - preview-funktionalitet og malware-scanning er helt legitime grunde.

Hvis kommunikation (inklusiv indhold af websites) ikke tåler dagens lys, skal man ikke kommunikere ukrypteret gennem tjenester man ikke selv kontrollerer :-)

Derudover er det kun godt at disse legitime optræder nok i logfiler, til at folk er blevet bevidste om at man skal overveje hvad man sender af links... og hvad metadata kan bruges til.

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