Pixabay

Zoo kundedata hacket

Via Version2 -

En softwareingeniør fandt et gabende stort hul i Zoos kundedatabase

Det gik op for softwareingeniør Søren Louv-Jansen, at et fortløbende kundekommer og predefineret postnummer som kodeord (man ikke kunne ændre), ikke kunne være særlig sikkert.

Ved at bygge en forholdsvis simpel tester, lykkedes det ham derfor at få adgang til hundredevis af Zoo-kunders loginoplysninger, ved at køre de fortløbende kundenumre og tilfælde postnumre, igennem.

Zoo har allerede reageret ved at tilføje en Captcha på login-boksen – men altså ikke ændret hverken brugerenes kodeord eller metodik. Til trods for at Zoo melder at ingen data er lækket, foreligger der ingen reel dokumentation for om det er sandt.

Hvorvidt Søren Louv-Jansen ender med at blive politianmeldt for at finde hullet, som tidligere har været eksemplet, vides endnu ikke.





Gå til bund
Gravatar

#1 Ni 3. jan. 2020 10:30

Det der med at dokumenteret, at man IKKE har haft indbrud. Er den ikke lid svær?

Det lyder lidt som et projekt chefen har givet til sin teenagesøn som er lidt ferm med it. Det er jo ikke fordi en Zoo vælter sig i penge :-)

Derudover, så kan jeg godt tvivl på, at der står noget i deres kundedatabase, som man ikke kan købe af FB, google eller en hvilken som helst anden databroker :-)
Gravatar

#2 larsp 3. jan. 2020 10:41

Hvorvidt Søren Louv-Jansen ender med at blive politianmeldt for at finde hullet, som tidligere har været eksemplet, vides endnu ikke.

Se, kejseren har ingen tøj på! .. neej hvor pinligt, se at få smidt den dreng i fængsel.

Jeg begriber ikke at man politianmelder den slags (ikke at det nødvendigvis sker i denne sag). Man burde give hackere en dusør i stedet for, hvis de vælger at offentliggøre sikkerhedsproblemer i stedet for at udnytte dem og slå mønt på det.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#3 Sn3akr 3. jan. 2020 11:55

#1 Resultatet af virksomhedernes arrogance og fremgangsmetoder med anmeldelser, gør bare at folk ikke længerer gider advare dem, hvilket efterlader hullerne åbne til personer med mindre heldige intentioner.. Så kan de jo så tude når de til den tid risikerer sagsanlæg og bøder selv, i stedet for at få lukket hullerne.

Personlig erfaring fra Yousee (ikke at de er indblandet i denne sag), var en nabo som blot ringede ind og fik ændret vores wifi-kode.. Flere gange.. På en erhvervsløsning.. Rigtig flot sikkerhed, hvor mange flere informationer de har givet ud, aner vi ikke.
Gravatar

#4 CBM 3. jan. 2020 13:57

Præcis som KMD så tager de nok bare chancen og politianmelder den arme gut

Problemet er så at med KMD vælger man ikke selv om de har ens oplysninger

https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gravatar

#5 zymes 3. jan. 2020 22:25

Jeg meldte for længe siden en dansk side til Datatilsynet, fordi de havde en fejl i deres login.

Nogle gange blev man bare logget ind som en tilfældig bruger, når man åbnede siden, og havde så adgang til alt (navn, evt. adresse, telefon, mail, private beskeder, ændre kode osv.) - ingen kortoplysninger eller andet "vigtigt" (medmindre der var noget i private beskeder).

Dette gjorde jeg efter at siden flere gange havde ignoreret alle henvendelser - gennem næsten et år.

Der gik så næsten fire måneder mere, før jeg fik et svar tilbage, om at Datatilsynet havde "udtalt kritik" af sidens behandling af oplysninger og givet et påbud om at få deres login lavet.

Så blev login fjernet fra siden, og kom tilbage et par uger senere med beskeden "nu er alt godt" - men det var så stadig ligesom før.
Forfra igen med henvendelser der blev ignoreret - indtil lige inden jeg ville skrive til Datatilsynet igen. Så forsvandt login, igen, med beskeden "grundet opdateringer er login midlertidigt fjernet" - og nu har siden været stille i tre måneder..

TL;DR
Hvis man melder ting til Datatilsynet, tager det åbenbart utrolig lang tid - og er helt uden opfølgning..
Gravatar

#6 CableCat 4. jan. 2020 10:19

Bestilligesstymmmet til Bio i Aalborg har noglelunde samme fejl. Jeg ved ikke om den er rettet.

Se også: https://wiki.iptables.dk/Sikkerhedsproblemer_hos_E...
Standardisering gennem tvang, giver frihed.
Gravatar

#7 dugfrisk 5. jan. 2020 06:35

.
Dewayne "Lee" Johnson
Queensland cotton farms

Gravatar

#8 kblood 5. jan. 2020 08:00

#5 Næste skridt er vel så bare at meldte det til EU som brud på GDPR i stedet?

Men måske starte med først at melde det til dem som styrer hjemmesiden... selvom det så måske kan få en anmeldt til politiet. Burde egentlig være strafbart at prøve at anmelde folk for at finde sikkerhedshuller. Det er jo altså ikke 90erne vi lever i længere og vores lovsystem burde være blevet mere klar på denne slags...
Gravatar

#9 zymes 5. jan. 2020 16:04

kblood (8) skrev:
Men måske starte med først at melde det til dem som styrer hjemmesiden...


zymes (6) skrev:
Dette gjorde jeg efter at siden flere gange havde ignoreret alle henvendelser - gennem næsten et år.


Det hjalp ingenting at melde det ejeren, fik en enkelt gang et svar i retning af "modtaget". Derfor jeg prøvede at gå videre til at starte med :p
Gravatar

#10 arne_v 6. jan. 2020 14:56

#5

Datatilsynet/registertilsynet har altid været en særdeles tandløs tiger.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#11 arne_v 6. jan. 2020 14:59

kblood (8) skrev:

#5 Næste skridt er vel så bare at meldte det til EU som brud på GDPR i stedet?


Skal overtrædelser af GDPR i Danmark ikke meldes til datatilsynet?

:-)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#12 arne_v 6. jan. 2020 15:08

larsp (2) skrev:
Hvorvidt Søren Louv-Jansen ender med at blive politianmeldt for at finde hullet, som tidligere har været eksemplet, vides endnu ikke.

Se, kejseren har ingen tøj på! .. neej hvor pinligt, se at få smidt den dreng i fængsel.

Jeg begriber ikke at man politianmelder den slags (ikke at det nødvendigvis sker i denne sag). Man burde give hackere en dusør i stedet for, hvis de vælger at offentliggøre sikkerhedsproblemer i stedet for at udnytte dem og slå mønt på det.


Sn3akr (3) skrev:
#1 Resultatet af virksomhedernes arrogance og fremgangsmetoder med anmeldelser, gør bare at folk ikke længerer gider advare dem, hvilket efterlader hullerne åbne til personer med mindre heldige intentioner.. Så kan de jo så tude når de til den tid risikerer sagsanlæg og bøder selv, i stedet for at få lukket hullerne.


kblood (8) skrev:

Men måske starte med først at melde det til dem som styrer hjemmesiden... selvom det så måske kan få en anmeldt til politiet. Burde egentlig være strafbart at prøve at anmelde folk for at finde sikkerhedshuller. Det er jo altså ikke 90erne vi lever i længere og vores lovsystem burde være blevet mere klar på denne slags...


Der er en del sager hvor virksomheder har anmeldt den slags og det virker noget malplaceret da der ikke har været nogle onde hensigter bag.

Men jeg tror at lovliggørelse vil være en katastrofe for IT sikkerhed.

Hacking vil blive ren win win.

Ondsindet hacker forsøger at hacke bank X uden held og bliver opdaget. Politiet banker på hans dør men får at vide "jeg testede bare sikkerheden - skrid".

Ondsindet hacker forsøger at hacke bank X med held men bliver opdaget lige før han overfører 100 millioner til en bankkonto i udlandet. Politiet banker på hans dør men får at vide "jeg testede bare sikkerheden - skrid".

Ondsindet hacker forsøger at hacke bank X med held og overfører 100 millioner til en bankkonto i udlandet og bliver opdaget. Politiet banker på hans dør men han er ikke hjemme, fordi han sidder i en flyver på vej mod et land uden udleveringsaftale.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#13 fastwrite_1 6. jan. 2020 16:12

Det er virkelig skræmmende så ofte man hører om brud på sikkerheden, og om hvor lemfældigt systemer er lavet.

Lærer programmører ikke noget om sikkerhed i dag? Fra allerførste gang jeg lavede en hjemmeside, dengang internet var så nyt at dr.dk blot et par måneder inden havde lavet deres hjemmeside, tænkte jeg sikkerhed ind.

Da jeg lavede min første .asp side, tænkte jeg sikkerhed ind (og ja, vi er stadig mange, mange år tilbage i de glade midt-halvfemsere)

Og nu er jeg bare full blown paranoia security freak når jeg laver hjemmesider for andre, fx hvis nogen forsøger at logge på med "admin" username, bliver de blokeret for tid og evighed!!
Gravatar

#14 arne_v 6. jan. 2020 16:23

#13

Jeg tror ikke at udviklere er ved mindre om sikkerhed idag end for 25 år siden - snarere tværtimod.

Men matematikken er imod.

Lad os sige at vi for 25 år siden havde 10000 web apps af gennemsitlig 5000 linier med gennemsnitlig 1 grov sikkerhedsfejl per 100000 linier. Så er det forventede antal grove sikkerhedsfejl 500. Hvis 5% bliver fundet af ondsindede hackere så er det 25 om året.

Hvis vi idag har 10 millioner web apps af gennemsnitlig 50000 linier med gennemsnitlig 1 grov sikkerhedsfejl per 200000 linier. Så er det forventede antal grove sikkerhedsfejl 2.5 million. Hvis 5% bliver fundet af ondsindede hackere så er det 125000 om året.

Hvis mine fiktive tal var rigtige så havde udviklere som lavede halvt så mange grove sikkerhedsfejl alligevel resulteret i 5000 gange så mange successfulde hackinger.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#15 fastwrite_1 6. jan. 2020 18:14

#14

Du har en fornuftig pointe. Det hele er ekskaleret voldsomt siden dengang vi (jeg formoder du også er et 70'er barn ;-) var ung.. yngre.

Men synes også bare man får opfattelsen at sikkerhed ikke er SÅ voldsomt på tapetet, at den ene sikkerheds-paranoid-geek der er på holdet måske bliver set lidt ned på, for hvordan kan fx ZOO få programmeret "fortløbende kundekommer og predefineret postnummer som kodeord (man ikke kunne ændre)", hvordan kunne den kode overhovedet få liv? Hvorfor var der ikke nogen der råbte op?

Nogen gange tror jeg at tiden er en faktor. Tingene går så hurtigt at der ikke er så meget "tid" til at "sikkerhedsificere" det.
Gravatar

#16 arne_v 6. jan. 2020 18:34

#15

Der er naturligvis inkompetente web udviklere. Nogle værktøjer idag er så nemme at bruge at enhver kan bruge dem - med det resultat at enhver bruger dem. PHP verdenen lever med en hel del af disse.

Men jeg tror at de fleste web udviklere godt ved hvad de burde gøre. Og de får det gjordt rigtigt næsten altid. Men "næsten altid" er ikke "altid".

Skrappe deadlines der får udviklere til at haste for at nå deadline er sikkert en af de helt store syndere.

Men udviklere er også mennesker og selvom konteksten er fin, så kan udviklere have en dårlig dag - babyen har grædt hele natten, de har skændtes med konen over morgenmaden, deres kollega er sygemeldt så de skal laves to personers arbejde - og nu skal de lige programmer bruger login check.

Og moderne web applikationer ofte meget store og komplekse. Det er svært at teste det hele uden at det bliver sindsygt dyrt i test. Med en stor kode base (millioner af linier af kode), så er det håbløst at lave code review af det hele. Der er faktisk gode værktøjer til at lave automatiseret check, men de er dyre og ikke så udbredte igen.



The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#17 arne_v 6. jan. 2020 18:37

#15

Det konkrete problem med fast gætbart password er naturligvis et totalt fejldesign.

Og jeg finder det svært at tro at det er en prof som står bag det.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#18 Yakuzing 6. jan. 2020 19:41

Synes denne artikel ser mega mystisk ud når der ingen steder er nævnt hvilken Zoo den handler om. Ingen steder står der Zoo.dk eller Københavns Zoo. Det står i første linie i kilden. Er det kun københavnere der læser Newz?
Gravatar

#19 arne_v 6. jan. 2020 19:59

#18

Alle ved at jorden er flad og at man falder ud over kanten når man forlader storkøbenhavn.

:-) :-) :-)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#20 fastwrite_1 6. jan. 2020 23:05

#16

Du virker som en insider "tell-me-about-it"-erfaring omkring programmering og korte deadlines :-)

Men ja, du har ret, der er mange faktorer der kan spille ind men hvor økonomien/tiden nok er en afgørende faktor.
Gravatar

#21 arne_v 7. jan. 2020 00:14

#20

Jeg har arbejdet med software udvikling siden 1987.

Jeg har set lidt.

:-)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#22 fastwrite_1 7. jan. 2020 14:35

#21

Det var omkring det tidspunkt jeg fik min C64 og straks gik igang med at lære programmering. Som 12 årig.

Sikke tider... Husker du den ballon man kunne programmere med en masse DATA numre, som var med i manualen til 64'eren?.. nostalgi on...


Gravatar

#23 arne_v 7. jan. 2020 14:52

#22

Jeg har aldrig arbejdet med C64. Og jeg fik først egen PC i 1998.

:-)

Jeg startede på en CDC Cyber maskine med NOS styre system, da jeg startede på uni. Men skiftede efter kort tid til en VAX 8650 med VMS.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#24 arne_v 7. jan. 2020 15:00

arne_v (23) skrev:

Jeg startede på en CDC Cyber maskine med NOS styre system,


Og det er en lidt usædvanelig maskine:

60 bit integers
60 bit single precision floating point
120 bit double precsion floating point
18 bit ord adresser
6 bit characters

Og et lidt usædvaneligt styre system:

ingen directories
kun midlertidige og permanente filer

Og en meget picky Fortran V (77) compiler:

en blank linie efter sidste END var en fatal fejl

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#25 fastwrite_1 20. jan. 2020 00:25

#22 først egen PC i 1998?... der røg kæben lige ned på bordet.

Gravatar

#26 arne_v 20. jan. 2020 00:39

#25

-91 var jeg på Uni fra morgen til kl. 10-12 om aftenen, så ingen brug for PC derhjemme.

92-97 boede jeg i gå afstand fra arbejde, så ville jeg lave noget om aftenen så gik jeg bare op på arbejde.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#27 arne_v 20. jan. 2020 00:49

#26

Og jeg har egentligt aldrig været en PC mand.

Jeg har lavet en del Compass assembler for CDC Cyber. Rigtigt meget Macro+32 assembler for VAX (30-50 KLOC). Ingen x86 assembler.

Da jeg begyndre at udvikle med x86/x86-64 som mål platform var det Java.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#28 arne_v 20. jan. 2020 00:52

arne_v (24) skrev:

Og det er en lidt usædvanelig maskine:

60 bit integers
60 bit single precision floating point
120 bit double precsion floating point
18 bit ord adresser
6 bit characters


Og one's complement ikke two's complement for integers.

Hvilket betyder at der er både +0 og -0.




The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login