300.000 navne og mailadresser lå sammen med gaveønsker i åben PostNord-database

PostNord-database med mail-adresser og navne har stået åben for uvedkommende.

En database med oplysninger fra PostNords Ønskeskyen har stået ubeskyttet åben ud mod internettet.

Ønskeskyen er en tjeneste, hvor brugerne kan oprette digitale ønskesedler, som de kan dele med familie og venner op til eksempelvis jul.

Databasen rummer omkring 300.000 personnavne med tilhørende mail-adresser. I nogle tilfælde har der også være knyttet postnumre og fødselsdatoer til navnene. Også brugeres gaveønsker har været tilgængelige i den åbne database.

»Det er vi kede af, og den fejl, som er sket hos vores underleverandør, er helt uacceptabel. Vi er selvfølgelig glade for, der ikke er personnumre eller bankkonti i denne forbindelse,« siger marketingchef hos PostNord i Danmark Brian Jakobsen og fortsætter:

»Det, der har været muligt at se, er navn, mail og deres ønsker - og så er der nogle brugere, der har oplyst et postnummer og en fødselsdato. Deres kodeord har selvfølgelig været krypteret.«

En Version2-læser, der ønsker at være anonym, fandt databasen via en søgning på sårbarheds-søgemaskinen Shodan.io. Herefter gjorde han PostNord opmærksom på problemet.

»Personen, der har gjort opmærksom på det her, har vi været i dialog med. Han siger selv, han har lavet to besøg, hvor det er lykkedes ham at hente lidt data. Og det er også det, som vores underleverandør kan se på serverloggen,« siger Brian Jakobsen.

Han fortæller desuden, at de pågældende data har været en del at et setup til at stressteste opsætningen i forhold til Ønskeskyen.

Hentede data på 10.000

I en opfølgende mail oplyser PostNord, at antallet af brugere, »der der reelt har været eksponeret, er i omegnen af 10.000«.

Dette tal knytter sig ikke til antallet af brugere i den ubeskyttede database, der altså har haft data for ca. 300.000, men til det antal brugere, som personen, der fandt databasen, ifølge PostNords oplysninger har hentet data på.

»Han har underskrevet en erklæring, hvor han siger, at han har slettet de data, han har hentet,« siger Brian Jakobsen.

Desuden kan PostNord fortælle, at databasen stået åben i tre dage. I den periode er man hos Postnord »ret sikre på«, det kun er den pågældende person, der har tilgået oplysninger i databasen.

Ønskeskyen

Ifølge Version2's oplysninger er der tale om en MongoDB-database, som ikke har været beskyttet med login. Databasen rummer data fra Ønskeskyen.

Udover oplysninger om blandt andet mailadresse og navn har der også ligget et kodeord i krypteret format. Altså ikke i klartekst. Kodeordet er brugervalgt.

Som bekendt er det ikke usædvanligt, at brugere genbruger et kodeord i flere sammenhænge. Og derfor kan der ved datalæk være en risiko for, at de lækkede kodeordsoplysninger ikke bare giver adgang til - i dette tilfælde - Ønskeskyen, men også kan bruges til at opnå adgang til eksempelvis en netbank eller en mailkonto.

Obfuskering af kodeord

Ikke mindst derfor er det i udgangspunktet altid en god idé at køre kodeord gennem en algoritme, så de ikke ligger i klartekst - eksempelvis i en MongoDB-database, som kan findes via Shodan.io

På den måde kan en angriber ikke uden videre bruge oplysningerne til at skaffe sig adgang til andre systemer.

Det er dog ikke helt ligegyldigt, hvilken algoritme kodeordene bliver kørt gennem, inden de bliver lagret i databasen.

I takt med at der dukker sårbarheder op, og hardwaren bliver kraftigere, så er nogle algoritmer i dag fuldstændig ubrugelige til lagring af kodeord. Det gælder for eksempel hash-funktionen MD5.

Derudover skal et såkaldt salt anvendes. Og på den rigtige måde. Det står der mere om i denne anbefaling fra The Open Web Application Security Project.

I forhold til lagringen af kodeord og Ønskeskyen ønsker PostNord ikke at oplyse nærmere om lagringen, men fortæller, at »best practice er benyttet med en sikker hash-algoritme«.

Det samme skulle være tilfældet med saltet.

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

Det er vel efterhånden en klassiker: En MongoDB uden nogen form for beskyttelse.

Som udvikler kender jeg det godt. Jeg skal bruge den og den funktionalitet, men jeg bekymrer mig ikke om det operationelle i at skulle drive en MongoDB-server. Devops var tænks som en mulighed for at udviklere og driften skulel tage fælles ansvar, men med cloud og serverless er drift blivet kørt ud på et sidespor og resultatet blevet "Devops, bare uden ops".

  • 23
  • 0
Lasse Hillerøe Petersen

Devops var tænks som en mulighed for at udviklere og driften skulel tage fælles ansvar, men med cloud og serverless er drift blivet kørt ud på et sidespor og resultatet blevet "Devops, bare uden ops".

Man skal helt sikkert ikke give sig i kast med DevOps, uden at være bevidst om at "drift" og "udvikling" har diametralt modsatte motivationer, hhv stabilitet og forandring. Ellers bliver det Dev-Oops!

  • 16
  • 0
Mikkel Rostved
  • 4
  • 0
Niels Buus

DevOps skulle gerne betyde at softwaren udvikler og driftes af et team som har et ben i begge verdener og forstår at ramme et fornuftig kompromis, så både udviklingen og driften spiller og changes som i en adskilt verden ville tage uger at implementere, nu kan indfases på få timer.

  • 1
  • 0
Michael Christensen

Det er jo desværre også en indikation på, at der ikke er opsat tilstrækkelige quality gates for udviklingen, og at sikkerhed ikke har været bagt ind i udviklings processer eller projektmodeller. DevOps er for mig OK set fra et sikkerhedsperspektiv, såfremt det håndteres korrekt. Den nye persondatalovgivning, GDPR, som træder i kraft næste år kræver at systemer designes sikre "by design and by default". Det betyder, at de sikkerhedsmæssige ting skal være en del af opskriften, ingredienserne og hævetiden i dejen. Hvis man ikke kan bevise det, så er man på lidt gyngende grund, og skal til at bide til bolle med datatilsynet.

Passwords i klartekst, i usaltet hash eller på gamle hash algoritmer bør ikke kunne forekomme i 2017, og så ser man det alligevel fra tid til anden. Man kan selvfølgelig helt lade være med at beskytte sinde data og sende dem til kineserne, så er man ude over de trivialiteter.

I dette tilfælde hæfter jeg mig ved, at man tilsyneladende anvender live data til en stresstest i et miljø eksponeret på internettet. Jeg er heller ikke overmåde imponeret af bemærkningen om, at de er »ret sikre på«, at det kun er den pågældende person, der har tilgået oplysninger i databasen.

Det fik mig til at tænke på en gammel march sang: Here we go again. Same old stuff again. Marching down the avenue. FIVE more months the GDPR is through. I'll be glad and so will you. (Marching Cadence, slightly changed with a touch of GDPR)

  • 3
  • 0
Peter Makholm

Det er jo pænt træls at blive politianmeldt for hacking når man i bedste tro afslører sårbarheder.


Det ser ud til at personen har været i dialog med PostNord og det må derfor antages at de kender til personens identitet eller på anden måde have nok oplysninger til at politianmelde hændelsen.

Derfor læser jeg det mest som et ønske om at holde sig uden for offentlighedens søgelys ̣̣̣– det er altså os læsere der frygtes. Det kan jeg iøvrigt ikke fortænke personen i.

  • 6
  • 0
Thue Kristensen

I takt med at der dukker sårbarheder op, og hardwaren bliver kraftigere, så er nogle algoritmer i dag fuldstændig ubrugelige til lagring af kodeord. Det gælder for eksempel hash-funktionen MD5.

Det har ikke noget at gøre med at hardware bliver kraftigere, at MD5 er ubrugelig til lagring af kodeord. MD5 er ikke og har aldrig været en key stretching algoritme, og man skal og har altid skulle bruge key stretching algoritmer til at lagre passwords.

  • 0
  • 0
Finn Christensen

Burde det ikke være common sense i 2017 at beskytte brugeres..

Beskyttelse og datasikkerhed etc. er på grund af manglende konsekvenser vist endnu ikke indarbejdet i diverse kvaseoffentlige og offentlige organisationer.

En ny undersøgelse[1] (Rambøll) fortæller også, at der ikke eksister det fornødne personalemæssige beredskab på området datasikkerhed, samt ikke mindst er der fremover heller ikke planlagt en øget aktivitet - fokus, uddannelse, ansættelser - på området.

[1] ..http://www.ramboll.dk/medier/Publikationer/rapporter/it-i-praksis
[1] 'IT i praksis' ..https://www.version2.dk/artikel/offentlige-virksomheder-persondatalov-st...

  • 1
  • 1
Christian Schmidt

PostNord skal i det mindste have ros for at kontakte de berørte brugere og informere om problemet.

Mange virksomheder havde nok bare valgt at lade som ingenting. Det var fx den strategi, som Statens Serum Institut benyttede sig af, dengang de lækkede CPR-numre og diagnoser for alle danskere.

  • 4
  • 0
Peter Makholm

Burde det ikke være common sense i 2017 at beskytte brugeres oplysninger?


Jo, målet om at beskytte brugernes oplysninger er almindelig fornuft. Men forudsætningen for at opnå dette mål er at den rette faglighed er til stede og her kræves både udviklerens og operations faglighed.

I et miljø hvor man har sparet operations væk (fordi cloud og serverless) mangler man som udgangpunkt den faglighed der skal sikre operationel sikkerhed.

  • 1
  • 0
Finn Christensen

for at opnå dette mål er at den rette faglighed er til stede og her kræves både udviklerens og operations faglighed.

Det er pt. nok ikke muligt iflg. 'IT i praksis' nævnt ovenfor ..https://karriere.jobfinder.dk/da/artikel/medarbejdere-offentlige-virksom...

Især "kommunerne som de offentlige arbejdspladser, der oplever den største mangel på it-kvalifikationer" - et stort efterslæb, som skal indhenters.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize