Patent- og Varemærkestyrelsen hacket af ACTA-aktivister – stjal passwords

Illustration: Virrage Images/Bigstock
17.000 profiloplysninger blev stjålet fra styrelsens hjemmeside og offentliggjort på internettet.

Den danske Patent- og Varemærkestyrelsen opdagede torsdag 1. marts, at det var lykkedes hackere at få adgang til to af styrelsens it-systemer. Det oplyser styrelsen på hjemmesiden.

Ifølge styrelsen er der udelukkende tale om systemer, der indeholdt offentligt tilgængelige oplysninger, men for at få adgang til oplysningerne skal man bruge et login og password.

De login-oplysninger er det lykkedes hackerne at stjæle. Derfor opfordrer styrelsen brugerne til at skifte deres adgangskoder, hvis de har anvendt de samme oplysninger til login på andre tjenester.

Ifølge Computerworld er der tale om 17.000 brugeroplysninger.

Oplysningerne er ifølge Computerworld blevet offentliggjort på tjenesten Pastebin, hvor det er koblet med et budskab om, at hackingen og offentliggørelsen er sket som en protest mod den omstridte ACTA-aftale.

Afsenderne slutter budskabet med samme signatur, som bliver benyttet til den nye bølge af politisk motiveret hacking, eller 'hacktivism', som har fundet sted det seneste års tid under 'Anonymous'.

Ifølge Patent- og Varemærkestyrelsen er der også tegn på, at hackerne forsøgte at få adgang til flere systemer hos styrelsen, men uden held.

»Det her er foretaget af folk, der ved, hvad de gør, og der er blevet gået til vaflerne,« siger direktør Jesper Kongstad fra Patent- og Varemærkestyrelsen til Computerworld.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Lundin

Når man er ansvarlig for et web-sted, der er blevet offentligt kompromitteret, så er man nødt til at hævde at indbruddet er foretaget af 'folk, der ved, hvad de gør'.

For hvis det var nemt at bryde ind, så fremstår man ikke selv som særlig dygtig.

Men der er ingen garanti for at indbruddet var andet end at prøve et default-kodeord.

Og hvis det skulle være dygtige folk, der har skrevet budskabet, så har de gjort sig umage for at bruge et rigtigt dårligt engelsk.

  • 14
  • 0
Henrik Pedersen

Baaaah noget pladder. I har ikke engang hashet (og saltet) jeres passwords, så kan den resterende sikkerhed godt nok ikke havde været særlig høj.

Btw hvis politikkerne skulle indføre en ny dum internetlov en dag, så burde det kunne straffes hvis hjemmesider gemmer dit kodeord uden at hashe og salte den ordentligt.. om ikke andet skal det kræve ens samtykke før de gør det ukrypteret (hvis de nu har en god grund).

  • 6
  • 1
Henrik Pedersen

Det ville nok være lidt besværligt :)

Men pointen var jo bare at så skulle hjemmesiderne sige at de opbevarede mit password i klartekst og det skulle kunne straffes hvis de gjorde det uden at sige det.

Så igen, det her var nu mest ment som en lille sjov kommentar i forhold til alle de utallige ligegyldige initiativer som politikkerne tager. Her ville der i det mindste forekomme en smule mening med galskaben.

  • 3
  • 1
Peter Mogensen

Men pointen var jo bare at så skulle hjemmesiderne sige at de opbevarede mit password i klartekst og det skulle kunne straffes hvis de gjorde det uden at sige det.

Men hvis den server hjemmeside X bliver hostet på bliver kompromiteret, hvad er så forskellen på at de kigger i dens database med passwords, eller de tager det fra den PLAIN authentikering, der foregår i den trafik, der går til og fra serveren?
... altså ud over at databasen giver dig alle passwords på en gang og "sniffing" kun giver dig dem fra dem, der logger ind?

  • 0
  • 0
Peter Mogensen

At hvis du bruger PLAIN-authentication, så er al kommunikation med dit site pakket ind i SSL (no-brainer - ligesom hashede/saltede passwords burde være det)

Hvordan er det lige at SSL beskytter imod en kompromiteret host, der kører den applikation, der skal bruge password i klartekst?

Og ang. no-brainer - så spørger jeg igen: Hvordan vil du lave "ikke-PLAIN" authentifikation med hashede passwords?
(og nu antager vi at public/private-key authentikering ikke er aktuel).

PS: Vi er enig i at PLAIN authentikering med passwd gemt i klartekst ikke er heldigt. Men det besvarer ikke spørgsmålet.

  • 1
  • 0
Erik Løth

Jeg syntes at det offentlige skulle finde på noget hvor man ikke gemmer login lokalt,
Sådan et fælles login system, eller lignende. Det ville være nemt.

De kunne jo kalde det Nem id.

Pokkers det er lavet og dur heller ikke øv.
/Erik

  • 4
  • 0
Allan Høiberg

Hvordan er det lige at SSL beskytter imod en kompromiteret host, der kører den applikation, der skal bruge password i klartekst?

Spørgsmålet er vel i lige så høj grad, hvorfor en applikation har brug for at kende brugerens password i klartekst?

Jeg kan umiddelbart komme på ét behov: Et "jeg har glemt mit password - send det til mig"-link på loginsiden (hvor man i de fleste tilfælde så genererer et nyt og sender det, men husker det gamle til der er logget ind med det nye, så det ikke kan misbruges til at ødelægge en anden brugers loginmulighed).

/Allan

  • 0
  • 0
Peter Mogensen

Spørgsmålet er vel i lige så høj grad, hvorfor en applikation har brug for at kende brugerens password i klartekst?

Det har en vilkårlig applikation heller ikke. Men et eller andet sted skal der foregå en authentikering og så spørger jeg igen:
Hvordan vil du lave en authentikering uden at få tilsendt brugerens password/shared-secret i klartekst (PLAIN) hvis du har gemt de shared-secrets hashet?

Vi er helt enige i at der er massere af måder at authentikere brugere på, der ikke kræver at vilkårlige web-applikationer får password mellem hænderne - men nævn mig en af dem, der tillader at man kun gemmer password hashet i sin database.

  • 0
  • 0
Allan Høiberg

Hvordan vil du lave en authentikering uden at få tilsendt brugerens password/shared-secret i klartekst (PLAIN) hvis du har gemt de shared-secrets hashet?

Generér et tilfældigt stykke salt, send det til klienten, der først hasher det indtastede med standardmetoden, det også er hashet i databasen med, derefter en gang til salted med det tilsendte, og sender resultatet retur. Serveren hasher det hashede password fra databasen med samme salt og sammenligner.

Alt efter sikkerhedsniveau kan en simpel usaltet md5/sha1 eller lignende af passwordet måske bruges - det afhænger af sikkerhedsniveauet om formålet primært er at sikre at ingen kan aflytte brugerens plaintext-password og prøve om det virker på et andet site, eller om autentificeringen af brugeren også er vigtig.

Webapplikation med hashed-only-lagring: phpMyAdmin så vidt jeg husker. ;-)

/Allan

  • 0
  • 1
Peter Mogensen

Generér et tilfældigt stykke salt, send det til klienten, der først hasher det indtastede med standardmetoden, det også er hashet i databasen med, derefter en gang til salted med det tilsendte, og sender resultatet retur. Serveren hasher det hashede password fra databasen med samme salt og sammenligner.

... hvilket er ækvivalent med en challenge-reponse authentikering hvor passwordet reelt blot er det hashede password.
Hvordan ville du i et sådant system beskytte dig imod at det i databasen gemte hashede password blev leaket? ... Hvad har du så fået ud af at gemme password hashet?

  • 1
  • 0
Allan Høiberg

Hvordan ville du i et sådant system beskytte dig imod at det i databasen gemte hashede password blev leaket? ... Hvad har du så fået ud af at gemme password hashet?

Hvis det er salted i databasen, kræver det et brute force-angreb at finde frem til de originale passwords hvor hverken længde eller kompleksitet er kendt. Forudsat at brugerne har (efter tvang eller oplysning) fulgt de almindelige råd om valg af password i stedet for at bruge "1234" & co., er det en smule (læs: Ret meget) mindre sandsynligt at de bliver regnet ud end hvis der slet ingen kryptering var.

Man kunne selvfølgelig forestille sig at en angriber derefter var i stand til at bruge det hashede password til et fingeret login - men dels har han i sådan et tilfælde sandynligvis allerede skaffet sig så meget adgang til serveren at han ikke behøver at udgive sig for at være en bruger, dels har han stadig ikke den store chance for at regne det oprindelige plaintext-password ud og dermed forsøge at bruge det på andre sites.

Det største problem ville nok være at sitets admin heller ikke ville være i stand til at skifte hashing-algoritme når han heller ikke har det oprindelige password - men på den anden side ville man nok alligevel for en sikkerheds skyld bede alle bruger om at skifte password og/eller sende dem et nyt autogenereret midlertidigt, hvis et sådan angreb blev opdaget.

/Allan

  • 1
  • 0
Peter Mogensen

Man kunne selvfølgelig forestille sig at en angriber derefter var i stand til at bruge det hashede password til et fingeret login

Det kunne man ja.

  • men dels har han i sådan et tilfælde sandynligvis allerede skaffet sig så meget adgang til serveren at han ikke behøver at udgive sig for at være en bruger,

Det kommer vist an på det konkrete setup. Man kan sagtens forestille sig at den ene server ikke er alt brugeren kan få adgang til med de credentials. Hvis f.eks. din mail og ftp er hosted på forskellige servere, så skal du stadig authentikere dig overfor mail-serveren selvom du har kompromiteret ftp-serveren.

dels har han stadig ikke den store chance for at regne det oprindelige plaintext-password ud og dermed forsøge at bruge det på andre sites.

Det er selvfølgelig rigtigt... men - det ville jo kræve at andre sites brugte en anden hash-metode til dit klartekst password. Og du forudsatte jo i dit eksempel at der blev brugt noget du kaldte "standardmetoden".
Du kunne selvfølgelig sige at, hvis der logges ind via en hjemmeside, så definerer du selv hvad "standardmetoden" er og dermed kan du lave en unik til det realm du laver authentication for, men det vil jo kun virke for situationer hvor du server-side definerer klientens "standardmetode" hashalgoritme og når du gør det, så har folk, der har kompromiteret serverne også principielt mulighed for at give klienten noget andet (f.eks. Javascript) kode til det.

Hvis du vil gemme password hashet efter en metode, der også kan udføres i klienten med det formål at den metode skal være unik for hvert realm, (så password opnået ved kompromitering af et realm ikke kan bruges på et andet), så skal du finde en hash-metode der kan standardiseres samtidig med at den kan parametiseres unikt for hvert realm.
Findes den?

  • 0
  • 0
Allan Høiberg

, så skal du finde en hash-metode der kan standardiseres samtidig med at den kan parametiseres unikt for hvert realm.
Findes den?

Hvis du bruger en standardmetode til hashing, er det bare et spørgsmål om at have et unikt salt for hvert realm.

Men du har ret i at en angriber vil kunne smide en anden kode ud til klienten, der sender brugernes passwords tilbage ukrypteret efterhånden som de logger ind.

Men stadigvæk - og nok den vigtigste grund til at hashe alle passwords så vidt muligt, også selvom de i værste fald (simpel POP3, for eksempel) sendes i klartekst til serveren, der så selv hasher og sammenligner med et lagret hash, forhindrer dét at nogen ved at tømme databasen på én får udleveret samtlige brugeres passwords til at forsøge på andre sites. Sony er vist det populære eksempel på sådan et uheld...

/Allan

  • 0
  • 0
Peter Mogensen

Hvis du bruger en standardmetode til hashing, er det bare et spørgsmål om at have et unikt salt for hvert realm.

Men så skal serveren sende det salt den har anvendt da den gemte password til klienten for at klienten kan generere den samme hashede shared secret og dermed er du ude i at du A) mangler klientunderstøttelse for at tage imod det salt, og anvende det til at hashe brugerens password med kode IKKE leveret af serveren og B) ikke har beskyttelse imod at folk der gerne vil udnytte at have kompromiteret realm X til at bruge til password på realm Y kan gøre følgende:

1) Forsøge at logge ind på realm Y og dermed få at vide hvilket salt der der er anvendt.
2) Vente på at du logger ind på realm X og udnytte at have kompromiteret det site til at sende dig saltet fra realm Y.
3) Modtage dit password haset med salt fra realm Y fra din klient.
4) Bruge det til at fingerere det føromtalte login på realm Y
5) Profit

  • 0
  • 0
Allan Høiberg

dermed er du ude i at

Korrekt. :-)

Jeg antager at vi arbejder i f.eks. et app- eller websystem hvor loginsiden bliver sendt af serveren inklusiv en stump kode til at lave hashingen (vel vidende at det kan give problemer hvis brugeren har slået scripting fra - det er alligevel svært at lave ret meget civiliseret web2.0 hvis det er tilfældet, så...).

Der er masser af situationer der stadig kan udnyttes, ikke mindst dit eksempel - men for at komme tilbage til udgangspunktet var min oprindelige pointe egentlig kun at det ikke er nogen nødvendighed for serveren at kende brugernes klartekstpasswords - methinks det bør undgås fordi det som i Sony-tilfældet (tilfældene) udleverer alt på én gang uden at angriberen skal vente på at brugerne forsøger at logge ind efter angrebet. Hvis der kun er hashede (og saltede) passwords på serveren, er skaden voldsomt mindre hvis vi antager at angrebet opdages inden alle brugere har logget på.

/Allan

  • 0
  • 0
Peter Mogensen

... og min pointe er at du grundliggende står med valget mellem at kun lade serveren gemme hashede passwords og dermed kræve at de hver authentikering præsenteres i klartekst - eller at gemme en shared secret på serveren (som f.eks. password i klartekst, men krypteret symmetrisk "on disk") og så istedet beskytte passwordet hver gang det anvendes on-the-wire.
Personligt ville jeg foretrække det sidste afhængig af infrastruktur. Hvis man f.eks. er et universitet med 1000-vis af maskiner, der skal authentikere, så er det nemmere at sikre sin password-database end samtlige maskiner. Det er IMHO det værd at fjerne klartekst password totalt fra nettet og istedet at beskytte en database i modsætning til at have en hashet database og så have password på nettet alle steder. (og TLS beskytter kun indtil den første host, der håndterer klartekst passwords er kompromiteret).
De forskellige schemes du har foreslået giver IMHO ikke nogen nævneværdig beskyttelse imod det.

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