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

25. oktober 2017 kl. 05:1015
PostNord-database med mail-adresser og navne har stået åben for uvedkommende.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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:

Artiklen fortsætter efter annoncen

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

Artiklen fortsætter efter annoncen

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.

Artiklen fortsætter efter annoncen

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.

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
26. oktober 2017 kl. 23:48

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-virksomheder-spaender-ben-it-projekter-10786

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

14
26. oktober 2017 kl. 09:23

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.

13
26. oktober 2017 kl. 09:20

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.

11
25. oktober 2017 kl. 18:03

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-staar-vejen-vores-digitalisering-1082075

10
25. oktober 2017 kl. 17:39

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.

9
25. oktober 2017 kl. 16:40

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.

8
25. oktober 2017 kl. 13:01

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

6
25. oktober 2017 kl. 11:16

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)

5
25. oktober 2017 kl. 10:18

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.

2
25. oktober 2017 kl. 09:35

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

1
25. oktober 2017 kl. 09:08

Kryptering ≠ hashing