Derfor fik Bo og Frederik på 15 skældud for at finde sikkerhedshul

Der var ingen fare på færde, selvom to skoleelever opdagede passwords i klartekst i et stykke software. Det fortæller Københavns Kommune.

Da to it-kyndige skoleelever kiggede nærmere på et printerværktøj fra Københavns Kommune, fandt de passwordet til en database liggende i klartekst i koden.

Men der var ikke noget sikkerhedsproblem i den forbindelse, fortæller leder af Pædagogisk IT i kommunen, Karl-Erik Andersen.

»Det var en gammel database, de fik lov at arbejde med, ikke en aktiv en. Og det var kun de to, som fik adgang, ikke alle 36.000 elever i kommunen. Vi gav dem adgang til meget mere, end andre ville få, fordi de er dygtige,« siger han til Version2.

Opdagelsen blev gjort, fordi Thomsen og Frederik Lassen, der går i 9. klasse, gerne ville videreudvikle deres program Computerinfo, som hjælper skolerne med at registrere alle computerne automatisk.

Læs også: Mød fremtidens it-talenter: To 15-årige udvikler software til kommunen

Derfor fik de lov til at dekompilere printerværktøjet for at se, om de kunne integrere Computerinfo med kommunens software.

»Så vælger de at hacke ned der, hvor der lå nogle passwords. Og det syntes vi ikke var meningen,« siger Karl-Erik Andersen som forklaring på, hvorfor kommunen skældte Bo og Frederik ud, i stedet for at takke for hjælpen.

Læs også: Skoleelever fandt grumt sikkerhedshul i Københavns Kommunes software

Ifølge de to unge udviklere lå der passwords i klartekst i en MySQL-connect-string i koden, som enhver ’der er lidt nørdet’, ville kunne finde frem til.

Og Karl-Erik Andersen erkender da også, at det ikke er en god idé at have passwords i klartekst.

»Det var en fejl, som blev rettet med det samme, vi fik besked om det. Men det var ikke et alvorligt sikkerhedshul. Der skete ikke noget ved det,« siger han.

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
Lasse Boisen Andersen
  1. Fedt at du personligt kommenterer herinde Frederik. Bring os gerne den sande historie!
  2. HVIS drengene fik ballade for at finde sikkerhedshuller på bedste white-hat manér, så trænger Karl-Erik Andersen til en fyring. Det er fandme ikke i orden - tag dog imod det med åbne arme, lær af det, og giv eleverne et klap på skulderen for at finde et potentielt hul og holde nysgerrigheden.
  3. Rock on Bo og Frederik. Har i brug for et praktik ophold med sjove webprojekter så smid mig en mail på la@konscript.com
  • 22
  • 0
Steen Krøyer

Karl-Erik Andersen padler febrilsk. Uanset om det var en "gammel database" eller ej, er det sgudda' ikke i orden at skælde ungerne ud! Vi ved jo allesammen at grunden til at de fik skældud var at de fik kommunens folk til at fremstå som inkompetente klamphuggere. Gammel database .... prrrrrtttt, min bare ...

  • 21
  • 0
Jacob Christian Munch-Andersen

Hvis de finder et password i en dekompilering er der vel ikke rigtigt tale om at hacke, så er der blot tale om et password som er givet væk sammen med programmet.

I øvrigt, dekompilere værktøjet? Hvordan foregår softwareudvikling egentlig i Københavns Kommune? Når man vil ændre i et program så dekompilerer man bare exe filen, retter, og kompilerer igen, eller hvad? Er der ikke nogen som ligger inde med en original kildekode?

@Frederik, kunsten at beskylde andre for at lyve inkluderer ikke at råbe LØGN. Påpeg i stedet blot stille og roligt den logiske sandhed og bed derefter modparten om at redegøre for hvorledes hans udlægning passer ind, det virker langt bedre.

  • 15
  • 0
Frederik Lassen

@Jacob, du har helt og aldeles ret i at der ikke er tale om decideret "hacking". I forhold til dekompilering, ville vi bare se hvordan de gjorde det, ikke kompilere den samme kode igen.... Og ja jeg ved godt at råbe løgner ikke er den bedste måde at udtrykke sig på, men det var min første reaktion.

  • 11
  • 0
Frederik Lassen

Tjah, vi er nået frem til i vor "gruppe" at vi ikke får noget ud af at "flame" over PIT. Når det så er sagt så er det rent tekniske i artiklen sandt nok. Der er dog bare lige det ved det at vi fik ikke "lov" til at arbejde med database(af PIT). De gav os ikke adgang, man kan sige at vi "skaffede os adgang"(dette betyder ikke at vi målrettet giv efter at får adgang, tværtimod). Og vi fik ikke særlig "adgang", så alle ville kunne gøre det vi gjorde. That being said, ikke et ondt ord om PIT. De har tidligere vist stor interesse for vores projekter, men hånteringen af en sag som denne har ikke været god nok. Måske er grunden manglende erfaring om hvordan man takler sådanne situationer?

  • 10
  • 0
Henrik Rathje

Og så er det ikke et sikkerhedshul??

Hmm... ikke særligt intelligent sagt af vedkommende.. suk.

Frederik og Co. .. way to go!
Nu er connectstrings med password ikke i sig selv en fejl, men det er seføli altid en fejl hvis uvedkommende får adgang til den del af koden hvor den står!
Men seføli ikke jeres fejl..

Jeg har dog set LANGT større sikkerheds risici hos væsentligt mere udsatte offentlige institutioner.. så det her er vand. Og en prut i et glas ymer.

I skal nok få et godt job senere ;-)

  • 2
  • 0
Brian Clemmensen

Jeg synes i hvert fald at det er super godt gået at jer - Frederik og Bo. Et er at I fandt hullet, men noget andet er at I også rapporterede det ind. Og oftest er der vel sådan, at hvis man prikker til noget, som ikke er så godt, så bliver den man prikker til sur og tvær ;-)

Vi har snakket om det før og I har en fantastisk indstilling til tingene. Og man kan bare sjældent undgå at træde nogen over tæerne engang imellem... I er fantastisk dygtige begge to så fortsæt med den ilhu I har og I skal nok nå langt...

  • 2
  • 0
Søren Schack Hansen

Ikke særlig pædagogisk.
Hvis jeg (lærer i 35 år) skældte elever, der viste faglig opfindsomhed og dygtighed ud, ville jeg opnå meget dårlige resultater.
Jeg indrømmede altid eventuelle fejl. Derfor troede mine elever på mig.
Ikke for at pudse fjer; det var et helt bevidst pædagogisk princip. Jeg har altid mistro til mennesker, der ikke vil indrømme fejl.

  • 2
  • 0
Sune Marcher

Hvis værktøjet skal automatisk skal kunne tilgå databasen uden indtastning af credentials, er connection strengen nødt til at være tilgængelig (eller bedre: data skal udstilles gennem service, og databasen skal ikke tilgås direkte).

Det nytter intet at kryptere (eller på anden måde obfuskere) en connect-string hvis en potentiel angriber blot kan lave memory dump af processen, eller på anden måde komme frem til connect-string. Så er det smartere at have den stående direkte synlig i plaintext, men være sikker på at de givne database credentials ikke giver mulighed for hærværk.

Security 101.

  • 5
  • 0
Peter Lind

Så er det smartere at have den stående direkte synlig i plaintext, men være sikker på at de givne database credentials ikke giver mulighed for hærværk.


De givne database credentials gav - ifølge de unge herrer - adgang til RIGTIG meget (det står beskrevet i den tilknyttede artikel hvor sikkerheds-fadæsen er fremstillet: http://www.version2.dk/artikel/skoleelever-fandt-grumt-sikkerhedshul-i-k... ).

Som du påpeger ville det være en mere intelligent måde at håndtere tingene på hvis databasen ikke blev tilgået direkte. Men sådan blev det ikke gjort. Og bagefter forsøger en IT-tåbe sig med:

Så vælger de at hacke ned der, hvor der lå nogle passwords. Og det syntes vi ikke var meningen

Mage til idioti skal man lede længe efter.

  • 6
  • 0
Sune Marcher

De givne database credentials gav - ifølge de unge herrer - adgang til RIGTIG meget (det står beskrevet i den tilknyttede artikel hvor sikkerheds-fadæsen er fremstillet: http://www.version2.dk/artikel/skoleelever-fandt-grumt-sikkerhedshul-i-k... ).

Ah, den havde jeg ikke set - HVOR mange artikler er der om de to knægte? ;-)

Det var da sådan - relativt - meget ups. Én ting er at connecte til en database direkte... men ikke at have app- og funktionsspecifikke credentials? Og så have "lettere følsomt" data tilgængeligt sammen med whatever printinfo? Flot.

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