Hackere på Version2

Det vrimler dagligt med hackere her på Version2 - it-professionelle med dyb indsigt i og forståelse for, hvordan it-baserede systemer fungerer. Samt lysten til at udforske og lege med disse systemer.

I nat havde vi så besøg af en hacker af en anden type - den type, som gerne vil omgå sikkerheden i it-systemer med det formål... ja, det formål, at man kan.

Resultatet var, at forsiden af version2.dk fra et tidspunkt fredag nat til fredag morgen dirigerede besøg videre til hackerforummet shellsec.org, som selv var hurtig til at omtale episoden.

Jeg ville gerne fortælle en spændende historie om kompleks social engineering, hvor folk i telefonen har udgivet sig for at være vores hosting-leverandør, eller udnyttelse af 0-day exploits på vores server.

Den kedelige sandhed er, at der i knap to år har eksisteret et sikkerhedshul i vores kalender-funktion, hvor brugere i lokations-feltet har kunnet skrive tekst, som er gået rent igennem til vores forside - også kendt som et cross-site scripting-hul (XSS).

Man siger normalt, at man aldrig skal stole på brugerinput, men i dette tilfælde er det altså glippet.

I nat benyttede en person så hullet til at indsætte Javascript, som sendte besøgende videre til et andet site.

Illustration: Privatfoto

Det var heldigvis en relativ harmløs udnyttelse, selv om det selvfølgelig er voldsomt, at al forsidetrafik fra Version2 dirigeres videre.

Vi arbejder nu på at lukke hullet og har i mellemtiden deaktiveret kalender-funktionen.

Vi havde da klart foretrukket, at personen bag udnyttelsen af dette sikkerhedshul havde skrevet til os først, så vi kunne have lukket det, før det blev udnyttet. Vi har et par e-mail-adresser og nogle IP-adresser, men formentlig intet, som kan bruges til at finde frem til personen, og vi har derfor ikke tænkt os at forfølge det yderligere. Men skriv alligevel til os, når du læser dette - vi vil da gerne lige snakke med dig.

Til alle jer, der fik morgenkaffen galt i halsen, da I besøgte Version2 - vi beklager selvfølgelig fejlen.

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kristoffer Mortensen

Det var da forfriskende, at høre en ærlig forklaring på hvad der er sket.
Ingen bortforklaringer, eller snakket uden om.
Sådan er det sket, sorry, vi arbejder på det. BAM. ikke andet.

Det er rart for en gangs skyld.
Jeg tror at mange vil opfatte dette positivt, selvom det er en meget uheldig fejl i kalendersystemet, der ikke burde være der.

Tak for ærligheden, og den ligefremme artikel, det er forfriskende

  • 57
  • 1
Pelle Söderling

Kender I det at man sidder lidt søvnig og forsøger at åbne øjnene med en gang morgen-kaffe og pludselig befinder man sig på et hacker forum og tænker "hvordan pokker endte jeg her?" :-)

Heldigvis virker det til at være ret uskyldigt i dette tilfælde.
Man kunne f.eks. have injected scripts til at stjæle login-cookie information.
Eller man kunne have redirected til en side der indeholdte 0-day exploits til populære browsere og så havde det været en langt mere alvor sag.

Heldigvis var der blot tale om den slags "hackere" der søgte lidt opmærksomhed :-)

  • 3
  • 0
Martin Exner

Version2 har jo en sær dobbeltrolle i sådanne situationer. Først tages der kontakt til Danish LulzTeam (dem der hackede NemID) og så gutten der hackede borger.dk og giver dem et anonymt talerør... Hvordan Version2 så reagerer når det er dem der rammes, kan nemt blive hyklerisk og dobbeltmoralsk. Jeg synes dog at I vælger den rette approach: Ærlighed og erkendelse af egne fejl. Hvis I så samtidig kunne lave et interview med hackeren...win/win?

  • 13
  • 0
Klavs Klavsen

Godt håndteret - rart at høre når der har været sikkerhedshuller - alle bør være så åbne som i er.

Jeg vil altid anbefale at have flere lag af sikkerhed. En simpel måde at sætte et lag foran websitet, er f.ex. at sætte mod_security op foran (da i kører apache) - og sætte den op til at filtrere ihvertfald de mest "almindelige" ting - såsom javascript i POST/GET osv.

Derudover så skulle i måske overveje at sætte ServerTokens OS i apache - så i ikke fortæller alle at i kører CentOS 6, med php v5.3.3 osv... Det er selvf. bare lidt information disclosure - men jeg er altid fan af at fortælle så lidt som muligt :)

  • 1
  • 1
Lars Tørnes Hansen

Apropos sikkerhedshuller så har Linux kernen et sikkerhedshul, der af en almindelig bruger kan udnyttes til at blive superbrugeren root.

Det blev fikset igår for Ubuntu 12.04 LTS, 12.10, og 13.04 - Fedora og Debian har vist nok også fikset det med en opdatering.

Der er en artikel på h-online.com om det

  • 0
  • 0
Klavs Klavsen

Nu er der en VÆSENTLIG forskel på et remote-exploit (som det der ramte version2) og en local-exploit - hvor en eksisterende bruger (på SAMME computer - ikke på et site) kan blive root. locale exploits er væsentligt sværre at udnytte, da man i sagens natur, lige skal have en shell som en lokal bruger først :)

Derudover er der intet nyt - local-exploits er ikke nyt territorie :)

  • 1
  • 0
Henrik Pedersen

Kan I ikke autoloade PHP IDS ind i alle jeres sider?

Så kan I selv skrive koden til at tage stilling til hvad der skal ske når der er mistænkelig adfærd. Jeg har brugt det på et par sider, og bruger det også på en ny større side jeg er ved at skulle lancere.

Det er IKKE en "drop in" erstatning for reel input validering og sikkerhed i ens kode, men hvis det er loadet ind ved alle side indlæsninger og får lov at gennemgå al data som bliver sendt ind, så er det suverænt til at fange de få ting som måtte slippe igennem.

Havde I f.eks. afvist alle request med trussel-score over 10-15 stykker, med en statisk side der sagde at man var "ondskabsfuld" og skulle kontakte redaktionen hvis man mente den klascificering var en fejl, så er jeg ret sikker på at et simpelt XSS angreb ikke var kommet ind. Så havde det været ligemeget om selve kalenderen havde håndteret det korrekt eller ej, PHP IDS havde gået amok før der skete noget og afbrudt det hele.

Som bonus kommer det også med log moduler til at logføre al mistænkelig aktivitet, inklusive data omkring side og GET/POST variabler.

Link: http://www.phpids.org/

Kudos for god håndtering af angrebet ellers!

  • 0
  • 0
Lars Tørnes Hansen

... da man i sagens natur, lige skal have en shell som en lokal bruger først :)


Det er forkert.

Når du bruger en server via eksempelvis TCP/IP stakken, så afvikles der kode på serverens styresystem. Koden der afvikles køres som var du en bruger af styresystemet på computeren.
Det sker f.eks når din browser sender en HTTP GET forespørgsel til en web server.

Er der så et sikkerhedshul i serveren, så skal du kun køre exploitet for at blive superbrugeren.

  • 0
  • 0
Hans-Michael Varbæk

Klavs Klavsen:

Derudover så skulle i måske overveje at sætte ServerTokens OS i apache - så i ikke fortæller alle at i kører CentOS 6, med php v5.3.3 osv... Det er selvf. bare lidt information disclosure - men jeg er altid fan af at fortælle så lidt som muligt :)

ServerTokens OS? Nej... De skal bruge ServerTokens Prod i Apaches konfigurationsfil, og expose_php = Off i php.ini hvis den variabel er "On".

Dit forslag sender ikke kun "Apache" afsted i "Server" headeren, men mere end nødvendig information. Hvis de bruger mod_security kan "Apache" ændres til hvad som helst, uden at de skal ændre og "compile" kildekoden selv.

  • 0
  • 0
Hans-Michael Varbæk

Version2 burde overveje at få en Web Application Penetration Test lavet på et tidspunkt. Det kan dog hurtigt blive dyrt, alt efter hvilken type rapport format og hvor dybdegående testen skal være. (Vi snakker mindst 10 til 20'000DKK for et par dages arbejde med nogle sikkerhedsfirmaer, og det er jo en pæn sjat penge. Der findes dog alternative løsninger, såsom crowd sourced penetration testing, f.eks. HatForce https://www.hatforce.com/ )

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