Artikel top billede

(Foto: Computerworld)

Sådan kommer du dig over et site-hack

Jon Thompson og Torben Okholm viser, hvordan man ved, om man er blevet ramt.

Af Torben Okholm, Alt om Data

Denne artikel er oprindeligt bragt på Alt om Data. Computerworld overtog i november 2022 Alt om Data. Du kan læse mere om overtagelsen her.

Hvad har disse foretagender tilfælles: Sony, eHarmony og Linked-In? De har alle fået deres kodeordsdatabaser hacket og videregivet i det forløbne år, enten offentligt eller til hackermiljøet.

Cybersikkerhed er ikke et nyt begreb. Hvordan kommer hackerne ind, og hvad kan man gøre for at se, om ens oplysninger er blevet misbrugt?

Et website er blot et website, ikke? Nej, ikke når det drejer sig om store kommercielle sites, der hurtigt bliver komplekse at styre og sikre. Det, der begynder som en meget sikker løsning til et websites infrastruktur, skal ændres på uventede måder, efterhånden som sitet udvikler sig og bliver udvidet.

Et eksempel på, at uventede netværksændringer kan føre til et kompromis, er det pludselige behov for direkte at udsætte en database for internettet. Det er aldrig nogen god ide, men netværksadministratorer kan se det som en hurtig løsning på et problem. Så kan de altid sikre sagerne engang i fremtiden. Men mens basen er afdækket, er den truet. Derfor er det altid klogt at antage, at en uformel hær af ondsindede hackere lus-ker rundt og venter på, at man begår en fejl.

Selv hvis et sites servere alle ligger trygt bag en sikker firewall, og man kun kan få forbindelse til interne databaser fra interne systemer, kan andre stadig få adgang til informationen. Når en normal bruger for eksempel logger på, tilgår den software, der tjekker brugernavn og kodeord, backend-databasen. Det kan sommetider lade sig gøre at narre softwaren til at tro, at man har skrevet en ægte kombination af brugernavn og kodeord, og at den skal lukke en ind.

Teknikken bliver kaldt en sql-injektion, og det er påfaldende enkelt at udføre den over for sårbar software. Vi kan forestille os, at når man logger pået website, kører softwaren denne sql-forespørgsel:

SELECT * FROM users WHERE username = ?USER’ AND password = ?PASS’

USER og PASS er de variabler, der indeholder det indskrevne brugernavn og kodeord. Denne forespørgsel returnerer alle rækker fra brugertabellen, som indeholder kolonner til brugernavn og kodeord. Hvis der ikke er nogen, der stemmer, mislykkes login, men hvis antallet af rækker er én, skal oplysningerne svare til en post i databasen. Kombinationen af brugernavn skal derfor være ægte, således at loginsoftwaren lukker en ind på sitet.

Så langt, så godt. Men hvad nu, hvis vi ikke kender brugernavnet eller kodeordet? Det er her, sql-injektionsteknikken kommer ind i billedet. Hvis man skriver et brugernavn:

‘OR 1=1 --

Bliver forespørgslen til:

SELECT * FROM users WHERE username = ‘OR 1=1’ -- AND password = ?PASS

De to bindestreger er en sql-kommentar, der betyder, at forespørgslens sidste del, der tager sig af kodeordet, bliver ignoreret. Teksten ‘username = ‘OR 1=1’’ betyder ‘søg efter et brugernavn. Hvis der ikke bliver fundet noget, gør det ikke noget. Evaluer blot 1=1, og returner det’. Da 1=1 altid er sand, returnerer det en værdi på en til loginsoftwaren, der antager, at dette er tegn på, at der er blevet anført et gyldigt brugernavn og kodeord. Vores hacker er indenfor uden at kende de gyldige adgangsoplysninger.

Det er tydeligvis uacceptabelt. Når brugernavn og kodeord bliver tjekket, er det afgørende, at loginsoftwaren rydder op i inputtet. Det indebærer at fjerne ikkealfanumeriske tegn og kun beholde bogstaver og tal.

Sql-injektioner bliver brugt på mange andre måder til at udnytte forbindelser med backend-databaser. De er farlige på grund den mængde personlige data, der relativt ubesværet kan blive afsløret, men virker angrebet i den virkelige verden? Ja, det gør det i høj grad. Det kan fungere fint over for sårbare websites, som det fremgår af adskillige højt profilerede nyhedsartikler.

Den 12. juli kom nyheden om et større sql-injektionsangreb på et Yahoo-underdomæne. Her blev over 450.000 e-mailadresser og tekstkodeord videresendt til et hackingwebsite af et hold, der er kendt under navnet D33Ds Company. Hackingen udstillede kompleksiteten ved kommercielle sites som Yahoo, idet den omfattede over 2.700 databasetabeller og næsten 300 sql-variabler. Det måske mest forstemmende ved angrebet er, at ifølge onlineanalyser var de mest populære kodeord i det hackede stadig de evige favoritter “123456” og “password” (http://bit.ly/LoYan2).

»Vi håber, at de ansvarlige for sikkerheden ved dette underdomæne betragter det her som en øjenåbner og ikke som en trussel,« stod der i en kort besked for enden af den afslør-ede database. »Mange sikkerhedshuller i webservere, der tilhører Yahoo!, har forårsaget langt større skade end vores af-sløring. Lad venligst være med at undervurdere dem. Under-domænet og de sårbare omgivelser er ikke blevet lagt ud for at undgå yderligere skade.«

Browserangreb

Det bliver ikke bedre, når man tager i betragtning, at nogle simple injektionsteknikker også virker fra en webbrowsers adres-sebjælke. Den slags enkle angreb kan afsløre uventet information.

Man kan kende en webadresse, der sender information til en backend-server, på spørgsmåls-tegnene i url’en. Den følgende url henter detaljer om produkt 100 fra domænet.

mysite.com/product.asp?id=100

Den variabel, der er sat til værdien 100, er ‘id’. Det virke tilfor-ladeligt nok, men prøv dette:

mysite.com/product.asp?id=100 AND id=101

Man kan skaffe detaljer for begge produkter. Det er praktisk, hvis man kender et produkts id eller anden information, som man vil se. Skriv blot den relevante værdi i url’en. Vi kan imid-lertid også injicere lidt sql for at få anden information fra databasen:

mysite.com/product.asp?id=100 UNION SELECT username, PASSWORD from users

Det beder databasen om at give os detaljerne for produkt 100, men det beder også vores sql-engine om at kombinere dem med brugernavn og kodeord fra en tabel, der hedder ‘users’. De fleste sites bortfiltrer sql fra url’erne, før de bruger dem, men i nogle tilfælde, hvor naive udviklere ikke har gjort det, kan resultaterne være ødelæggende. Foruden detaljerne om produkt 100 kan man få en liste over alle brugernavne og deres tilknyttede kodeord.

Saltede kodeord

Bliver kodeord og andre oplysninger ikke gemt i krypteret tilstand? Jo, det bliver de (det burde de i hvert fald), og det bør betyde, at stjålne data er ubrugelige. Kunsten at bryde kodeord har imidlertid ændret sig siden den tid, hvor man brugte massive angreb. For at forklare det må vi dykke lidt ned i krypteringens mekanik.

En kodeordsdatabase bør al-drig lagre kodeord som ren tekst. I stedet bør man kryptere hvert kodeord og derefter lagre det. Krypteringsteknikken er asymmetrisk. Det vil sige, at man ikke kan arbejde sig baglæns gennem algoritmen fra de krypterede data og tilbage til kodeordet i ren tekst. Når nogle skriver et kodeord for at logge på, bliver teksten krypteret og testet mod den krypterede version, der er gemt sammen med brugernavnet. Hvis de stemmer, er kodeordene de samme, og så kan brugeren logge på.

Denne metode er bemærkelsesværdigt nok sårbar over for angreb. Hvis en angriber kan sende kodeords-databasen til sin computer, kan han kryptere hvert af dem fra en fil med omhyggeligt udvalgte testord (en såkaldt ordbog) og teste hvert af dem over for det pågældende kodeord. Hvis et par krypterede ord stemmer, kender han det oprindelige kodeord. Det kan lyde besværligt, og det er det også, men angriberen bruger måske en række computere, der alle arbejder parallelt på en lille del af kodeordsfilen, hvilket gør det til et ret effektivt angreb. Ordbogen begynder med indlysende kodeord, og den logik, der styrer angrebet, erstatter vokaler med andre bogstaver, kombinerer store og små bogstaver, limer ord sammen og så videre.

Ordbogen er forudkrypteret til noget, man kalder en rainbow-table, og som rummer de krypterede og rene tekstversioner af alle ordkombinationerne. Med denne tabel kan den software, der bryder kodeord, hurtigt beregne forholdet mellem de krypterede kodeord og den pågældende rainbow-table og sende alle de rene tekst-kodeord.

Af den grund kan den krypteringsalgoritme, der koder kodeordene i første omgang, antage en anden værdi, en såkaldt “salt”. Saltværdien bearbejder algoritmens output yderligere, således at det at kryptere en
ordbog og sammenligne outputtet med individuelle, krypterede kodeord bliver meningsløst. En salt skal også beregnes, og for hvert kodeord skal de mulige kombinationer ganges med alle de mulige saltværdier.

For yderligere at hæmme software til at bryde kodeord kan der være mere end én salt i brug. Når man skal beregne en rainbow-table, skal angriberen bruge alle tænkelige kombinationer og lagre dem i en enorm database. De ressourcer, der kræves for at angribe kodeord, der er beskyttet af flere saltværdier, er kolossale.
Tidligere på året fik netværkssitet LinkedIn stjålet sin brugerdatabase, muligvis via en svaghed i web-interfacet. Sitet havde brugt den sikre SHA-1-algoritme, men sikkerhedskommentatorerne var chokerede over, at de 6,4 millioner stjålne kodeord ikke var blevet saltet som led i krypteringen.

Vurdering af skaden

Når der er så mange databaser, der bliver angrebet hvert år, hvordan kan man så vide, at man ikke er genstand for et angreb? Bliver ens navn brugt til at udsende spam? En måde at finde ud af det på består i at bruge et onlineværktøj til at teste konti.

Hackere elsker at prale ved at sende kodeordsdatabaser online. Man kan derfor samle dem alle på et sted og teste brugernavne op mod dem for at se, om ens eget brugernavn er der. En af disse tjenester hedder Should I Change My Password (http://bit.ly/jXSDPn). Folkene bag tjenesten scanner internettet og søger udsendte databaser. Skriv den e-mailadresse, som du vil teste, og kik på ‘Check it’.

Efter et sekund får du en boks, der enten forklarer, at adressen ikke er på listen over belastede sites, eller hvor ofte den forekommer der. Uanset om alt er i orden eller ej, kan du nu lade sitet holde dig ajour, hvis den senere forekommer i databasen. Det er nyttigt, for man kan overvåge, om man senere bliver udsat for et angreb.

Disse værktøjer er ikke ufejlbarlige, men de giver ro i sjælen, fordi man i hvert fald ikke er i nogen af de databaser, der er blevet lagt ud, så alle kan udnytte dem. Og husk at ændre dine kodeord ofte.

Hvordan kan man vide, om et website er sikkert og ikke sælger ud af ens oplysninger? Hvordan ved man, at det ikke er et svindelforetagende, der tager imod dine penge, men aldrig leverer varen? Man kan søge efter gyserhistorier på nettet, men en mere effektiv metode består i at bruge et omdømme-site.

Webutation (www.webutation.net) er sådan en tjeneste. Sitet indsamler oplysninger fra brugerne på dets lister. Det scanner også for malware og andre grim-me overraskelser i realtid, for eksempel online-sortlister, Googles Safebrowsing og Nortons Safe Web.

Foreløbig har Webutation kategoriseret over seks millioner sites, og tjenesten har også plugins til Mozilla Firefox og Google Chrome.

Din antivirusudbyder har måske en browser-plugin, der kan sikre dig på ukendte sites. For eksempel er AVG’s Secure Search en browser-bjælke, der scanner de link, du klikker på, og som siger til, hvis du beder om et sortlistet site.Den tester også bredbåndshastig-hed og åbner Windows Notepad og Explorer.

En ny tendens ved angreb på Facebook-konti består i at dele ens konto og poste inficerede link, når man ikke ser det, for eksempel midt om natten. Hvordan kan man afsløre den aktivitet, og hvordan kan man stoppe den?
Kig først på ‘Kontoindstillinger’ på den menu, der kommer frem, når du klikker på pilen øverst til højre.

Til venstre på siden klikker du på ‘Sikkerhed’. På listen bør den nederste valgmulighed for ‘Aktive sessioner’ være valgt. Der bør kun være et aktivt login (dit). Den aktuelle placering afhænger af din udbyders infra-
struktur, og man kan anslå den ud fra din offentlige ip-adresse. Hvis du ser mere end et login, skal du klikke på ‘Rediger’ og vælge ‘Stop aktivitet’ for det falske login.

Nu skal du ændre dit kodeord.Det er muligt, at den indtræng-ende allerede har ændret det. Hvis dit aktuelle kodeord bliver afvist, må du ikke logge ud! Åbn i stedet en ny browserfane, skriv www.facebook.com, klik ‘Har du glemt din adgangskode?’, og skift den. Fortæl dine venner, hvad der er sket, og bed dem ignorere eventuelle link fra dig.

Man kan bede sin browser holde rede på kodeord, men findes der en bedre metode? En kodeordsmanager kan hjælpe ved at lagre og sikre dine hyppigt brugte oplysninger, men hvilken skal man bruge?

Firefox-brugere har en indbygget kodeordsmanager, der spørger, om den skal huske oplysningerne, når man skriver dem. Men det er usikkert, medmindre man skriver et master-kodeord. Det gør man ved at klikke ‘Options > Security’ og vælge ‘Use master password’. Skriv kodeordet, gentag det, og klik ‘OK’.

En fremragende open source-løsning, der fungerer med enhver Windows-browser, er Keepass (http://keepass.info). Den har den fordel, at den gemmer en lang række kodeord, ikke kun dem til websites. Software-pakker, netværk og selv netbank kan alle sikres, og omfanget af plugins giver nem integration med en række tjenester og cloud-applikationer.

Mange vil tilgå deres ressourcer via pc’en. Det har ført til udvik-lingen af cloudbaserede kodeords-managere. De gemmer oplysning-erne i skyen, så man altid kan hente dem. Men hvis skyen går ned, har man et problem. Sørg for, at tjenesten lader dig gemme en lokal kopi på en usb-nøgle.

[themepacific_accordion]
[themepacific_accordion_section title="Fakta"]

Phishing

[/themepacific_accordion_section]
[themepacific_accordion_section title="Fakta"]

Master-login

[/themepacific_accordion_section]
[themepacific_accordion_section title="Fakta"]

Ordbøger

[/themepacific_accordion_section]
[/themepacific_accordion]