Informasjonsikkerhet på norsk

Jeg har flyttet

2009-02-22T12:40:00.002+01:00

Men jeg har ikke flyttet lenger enn hit: http://infosik.net

Hvordan unngå brute force angrep

2009-02-18T21:10:00.002+01:00

Brute force, eller prøv og feil angrep som vi kan kalle det (i mangel på et bedre alternativ) er en veldig enkel metode å knekke krypto nøkler eller passord. Angrepsmetoden er ikke sett på som en stor trussel når det gjelder kryptonøkler siden det finnes raskere og bedre metoder å angripe kryptografi på.
Når det gjelder å knekke passord, kan metoden være svært effektiv dersom man ikke tar forhåndsregler når man designer systemet.

Så hva går egentlig brute force angrep ut på?
Brute force angrep vil si at man rett og slett prøver og feiler med tilfeldige passord helt til man finner det rette. Slike automatiske programmer er temmelig enkle og lage, og kan kjøre i bakgrunnen helt til man finner rett passord. Man kan velge å generere tilfeldige passord med alle mulig kombinasjoner av tegn, eller man kan bruke ordbøker eller lister over vanlige passord. Gjerne i kombinasjon med hverandre.

Så, hvordan beskytter man seg?
Tidsforsinkelse
En av de første tingene man bør tenke på er tid. Jo lenger tid angriperen bruker på å kontrollere om hvert passord er riktig, jo lenger tid bruker han på å finne passordet. Dette gir deg bedre tid til å oppdage et pågående angrep, og handle deretter. Dersom en bruker skriver inn feil passord, legg inn en pause på et sekund eller to før du gir brukeren tilbakemelding om at passordet er feil.

Varsling av administrator
Dette punktet bør man vurdere litt ut i fra hvilket system det er snakk om. Men en idè er å automatisk varsle en administrator dersom en bruker skriver inn feil passord mer enn feks. tre ganger. Jo mer kritisk system, jo mer pågående varsling. SMS er et fint alternativ. Men for all del husk på at det gjerne kommer 1000 flere forsøk. Ikke send SMS for hvert trede forsøk. Da det fort blir dyrt.

Skille mennesker fra roboter
Her er det nok stoff til å skrive en hel bok. Men poenget er å prøve å skille mennesker fra roboter. Her finnes det flere metoder som jeg ikke skal gå inn på nå. Men om du bestemmer deg for feks. bildegjennkjenning husk at dete øker terskelen for at brukeren logger seg på, så det kan være et poeng å ikke dra denne frem før etter første feilede påloggings forsøk.

To-stegs autentisering
Her ligger nettbanker milevis forran de fleste. Poenget her er å be om informasjon som er veldig vanskelig å "gjette" seg frem til og som endres for hvert påloggings forsøk. Dette gjør "prøv og feil" veldig mye vanskeligere. Igjenn er det et poeng å ikke plage brukeren dersom man ikke mistenker noe snusk. Dersom en bruker logger inn etter et eller flere (her må man vurdere) misslykkede innlogginsforsøk, kan man for eksempel sende en SMS til brukeren med en engangskode man må skrive inn. Man kan også spørre etter annen informasjon man har på brukeren, som e-post adresse, postnummer eller lignende.

Låse bruker
Man kan etter x antall misslykkede påloggingsforsøk låse en bruker slik at det ikke er mulig å logge seg på med denne. Her må man være veldig forsiktig så man ikke blir sårbar for "denial of service (tjenestenekt)" angrep. Dette er ikke noe jeg ville anbefalt til for eksempel en nettside.

Hold brukernavn skjult
En annen ting er å holde brukernavn skjult, og her slurves det fryktelig mye. Men for å si det slik: skal man gjette seg til både brukernavn og passord blir alt fryktelig mye vanskeligere. E-post kan brukes til å logge seg inn med, noe som gjør ting hakket bedre.
Et annet poeng er å ikke fortelle brukeren at han har skrevet inn et brukernavn som ikke finnes. Det at kombinasjonen brukernavn og passord er feil får holde. Ellers er det lett å finne frem gyldige brukernavn.

Bekrefting av passordbytte
Dersom en angriper skulle få tilgang til en konto så er det viktig at han ikke klarer å ta over kontoen ved å bytte passordet. Her bør man kreve e-post godkjenning, eller for eksempel en engangskode på SMS før passordet byttes.

Konklusjon
De fleste av tingene beskrevet over er enkle tiltak som vil øke sikkerheten betraktelig uten å gå for mye ut over brukervennligheten. Hvert tiltak bør såklart vurderes opp mot trusselnivå for å sette en grense for når hvert tiltak skal aktiveres. Fakta er at brute force angrep blir brukt, og alt for ofte er de skrekkelig effektive.
Har du andre tiltak, eller kommentarer høre jeg gjerne fra deg i kommentarfeltet.

Hvorfor jeg ikke har troen på in-session-phishing

2009-01-15T16:59:00.002+01:00

Det nye store på phishing fronten er altså in-session-phishing, noe som utnytter en bug i javascript motoren til alle de store nettleserene. Metoden krever at du allerede er logget inn på en nettside, og deretter åpner en ny fane og går inn på en annen side som er infisert med ondsinnet kode.

Grunnen til at jeg ikke har noe tro på at dette kommer til å bli en stor trussel er for at det er for mange tilfeldigheter som skal til for at angrep skal bli vellykket. Det er også lite å tjene på å benytte seg av denne metoden, i forhold til tradisjonell phishing.

SSL like sikkert som før

2009-01-07T19:27:00.003+01:00

De fleste har nok helt sikkert fått med seg at en gruppe forskere har klart å knekke en av de grunnleggende teknologiene for sikker kommunisering på internett, nemmelig Secure Sockets Layer. Dette er teknologien alle nettbanker i dag bruker for å kryptere trafikken mellom din nettleser og nettbanken slik at andre ikke kan lese eller manipulere denne. SSL sørger også for at du får en verifikasjon på at serveren du snakker med faktisk er din nettbank.

Når har ikke forskerene enda klart å knekke selve SSL protokollen, men en et av de underliggende prinsippene for identifikasjon av servere. Det betyr at man fremdeles ikke kan lytte eller manipulere på trafikk som benytter seg av SSL protokollen.

Problemet oppstår når man skal verifisere at den serveren man snakker med faktisk er den som den utgir seg for å være.

For å gjøre dette, er det opprettet en del Certificate Authorities (CA) som kan signere SSL sertifikater når de har verifisert at eieren av sertifikatet, er den rettmessige eieren av nettadressen som sertifikatet er bestilt til. Svakheten forskerene benyttet seg av ligger i hash (eller signerings) metoden som noen få CA benytter seg av for å signere sertifikater. Et ordinært og guldig sertifikat ble kjøpt av en CA som benyttet md5 til signering, og deretter ble et falsk sertifikat opprettet som hadde samme signatur som det gyldige. Dermed fremstod det falske sertifikatet som gyldig.

Verisign som var offeret for dette (proof of concept) angrepet sluttet nesten øyeblikkelig å signere sine sertifikater med å bruke md5 algoritmen.

Forskerene fant også ut at i løpet av 2008 var det bare 6 CA som benyttet seg av md5:

RapidSSL
FreeSSL
TC TrustCenter AG
RSA Data Security
Thawte
verisign.co.jp

Det ser også ut som alle disse har gått bort fra å benytte md5 til signering av sertifikater, og dette minsker rissikoen for at en angriper vil klare å generere et falskt sertifikat med identisk signatur til et gyldig sertifikat.

Den teknologisk utfordringen ved et slikt angrep er også fryktelig høy, samt fortjenesten er liten, da flesteparten av nettbrukere i dag ikke vil merke om et nettsted har et gyldig sertifikat eller ikke, så hvorfor gå gjennom arbeidet med å generere et falskt?

Det heldig med dette er at vi som faktisk vet hvordan vi skal verifisere et sertifikat, og et nettsted kan leve i trygghet på at vi snakker med riktig server og at ingen tapper eller manipulerer informasjon på veien.

Hvorfor er Cross Site Scripting farlig

2008-12-28T11:49:00.005+01:00

Cross Site Scripting, eller XSS er sammen med SQL injection ett av de vanligste sikkerhetshullene i webbasert programvare.

Enkelt forklart går XSS ut på å manipulere innholdet på en nettside ved ulike metoder. Hvis du vil lese mer om XSS, ta en titt i Wikipedia.

Selv om den vanligste typen av XSS sårbarheter er midlertidlige (Non-Persistent) så er dette faktisk noe man bør ta alvorlig.

Mange hevder at midlertidlige XSS sårbarheter ikke er alvorlig, siden eventuell kode som injiseres på siden må komme fra brukeren selv, som også er offeret for angrepet (i motseting til Persistent der nettsiden er offer).

Jeg rapporterte nettopp et slikt sikkerhetshull til Webhuset, der deres webmail løsning var sårbart for et midlertidlig XSS angrep. Sikkerhetshullet ble tettet ganske fort, men svaret fra webhuset var tankevekkende.

Cross-Site Scripting (XSS) in WHMail

Dette er ikke en veldig kritisk bug da man ikke er autensiert og det er begrenset hvor stor skade man kan gjøre med XSS i login-skjermen, men siden det var en enkel fiks tettet jeg dette hullet.

Han har jo selvfølgelig rett i at man ikke er autensiert, men det er faktisk halve poenget. Det geniale med akkurat slike sikkerhetshull som dette er å benytte de til phishing. Ved å injisere et javascript på siden, kan man bruke dette til å manipulere login skjemaet, slik at i tillegg til å logge inn brukeren så sendes også brukernavn og passord til en e-post adresse (for eksempel). Dette er enklere, og innebærer mindre rissiko enn ordinære phishing angrep der man må ha en webserver til sitt falske innloggingsskjema.

Et phishing angrep basert på en midlertidlig XSS sårbarhet vil også være vanskeligre å gjennomskue, da man faktisk ser (i dette tilfellet) www.webhuset.no i adresselinjen.

Vi kan i samme slengen ta med nok et eksempel på XSS hull

Cross-Site Scripting (XSS) at musiq.no search

Sikker deling av filer mellom flere maskiner

2008-12-22T18:04:00.001+01:00

Mange bruker i dag usb disker eller minnepinner for å overføre filer mellom arbeidsplass og hjemme PC. Dette er spesielt fordelaktig dersom innholdet er av den typen du ikke vil at andre skal få tak i, og dermed ikke ønsker å lagre det på nett. Men, det er tungvindt, og mister du lagringsmedia, så har du ofte ikke bare mistet filene dine (for backup er jo litt mye å forlange) men du må også anse innholdet på diskene for komprimitert.

Flere har kanskje hørt om Dropbox , en tjeneste som lar deg enkelt synkronisere filer fra din maskin til ditt eget private område på internett. Tjenes ten støtter både Windows, Mac, og Linux. Filene lagres kryptert på serveren til Dropbox, men siden det er de som sitter på kryptonøkkelen og ikke du, gir dette liten ekstra beskyttelse. Dropbox gir deg 2GB lagringsplass gratis, med mulighet til å oppgradere til 50GB for $9.99 pr. mnd eller $99 for et år.

Hele konseptet blir ikke genialt før du setter det sammen med TrueCrypt, et program som lager en virtuell disk der alle data lagres kryptert, kryptert med algoritmer og nøkler du selv bestemmer. TrueCrypt finnes også til Windows, Mac og Linux. Det hele blir et vakkert samspill mellom forskjellige plattformer.

Å komme i gang med Dropbox er såpass enkelt at jeg ikke kommer til å bruke tid på å forklare det her. Så snart du har ditt Dropbox område oppe å gå, og du har installert og startet TrueCrypt trykker du bare på "Create Volume". I første bildet velger du "Create an encrypted file container", deretter når du kommer tilplasseringen av filen så velger du bare Dropbox mappen på maskinen din.

Et tips kan være å ikke lage en for stor virtuell disk. Lager du en på 1GB, så blir filen 1GB.
Så med en gang filen er opprettet, så vil naturlig nok opplastingen ta sin tid. Det samme gjelder også første gang du laster den ned på en ny maskin. Men etter det vil Dropbox bare laste ned endringene i filen.

Husk å "lukke" den virtuelle disken når den ikke er i bruk slik at Dropbox får synkronisert.

Lykke til med en sikker hverdag.

Er utviklere late, eller vet vi bare ikke bedre?

2008-12-21T02:14:00.007+01:00

Ja, jeg sier vi, siden jeg er en utvikler selv.

Men jeg vet noe som tydligvis ingen andre vet. Ellers så er de for å late til å bry seg.

Jeg snakker om cross site scripting, eller XSS om du vil. Det tok meg ganske nøyaktig 10 minutter å finner tre norske nettsider som er sårbar for XSS angrep, to av de er utviklet av seriøse selskap.

Er dette for utviklere ikke vet hvilke trusler som finnes, at de rett og slett ikke er klar over den viktigste regelen en utvikler har: Ikke stol på noe som kommer fra brukere, det vil si:

POST data
GET data
Cookies
Innhold i headers
Filer
... andre lignende kilder

Et eksempel: ung.no XSS sårbarhet

Det som ofte glemmes i listen over er cookies og headers, men faktum er at disse er like enkle og manipulere som get data.

Et annet morsomt eksempel:

http://www.filmweb.no/index.jsp

I søkeboksen øverst kan du for eksempel skrive: "><script>alert("XSS");</script>

Så hva tror du er det latskap, eller uvitenhet som gjør så mange norske nettsider sårbare for en slik triviell angrepsmåte?

Velkommen

2008-12-21T02:06:00.000+01:00

Velkommen til denne bloggen om Informasjonssikkerhet, på norsk.

I nærmeste fremtid vil det forhåpentligvis dukke opp flere og flere meningsfulle innlegg om informasjonssikkerhet. Både monologer (som forhåpentligvis utvikler seg til dialoger) om diverse konsepter, men også nyoppdagede sårbarheter som ikke er tilgjengelig andre steder på nett.