Søk i artikler

Topp 10 sikkerhetshull

Hva er egentlig et sikkerhetshull når man snakker om IT? Og hvilket er mest utbredt i dag? Her er en liste med de ti mest utbredte sikkerhetshullene, enkelt forklart så det er mulig å forstå hva dette går ut på.

Et sikkerhetshull er en bakdør på en datamaskin hvor man kan snike seg inn med rette kunnskaper. Gjennom denne bakdøren kan man hente ut informasjon man egentlig ikke skulle hatt tilgang til eller gjøre skade på annen måte. Denne listen er rangert etter hvor alvorlig sikkerhetshullene er, med tanke på hvor utbredte de er, hvor mye skade som blir gjort og hvor hyppig de er brukt.

10 - Server konfigurasjon

Rett og slett at serveren er feil konfigurert. Når man setter opp en server første gang er det en del konfigurering som skal til for å få den til å passe inn i miljøet den står i. En standardkonfigurasjon er sjelden perfekt. Her er det mange syndere. Feilkonfigurasjon inkluderer blant annet:

  • Ikke installerte sikkerhetsoppdateringer
  • Feilinnstilte adgangsnivåer på serveren
  • Unødvendige installasjoner
  • Uforandret standardkonto med standard brukernavn/passord
  • Ekstern tilgang til "debug" funksjoner
  • For detaljerte feilmeldinger
  • Feilkonfigurert kryptering

9 - DOS (Denial of service) angrep

Dette er ikke hovedsakelig et sikkerhetshull hvor angriperen får tilgang til serverens filer, heller at ingen gjør det. Angrepet går ut på at man sender så mange forespørsler til serveren at den ikke klarer mer. Når man gjør en forespørsel til en database på serveren, vil serveren gi deg svar tilbake ut fra hva du spurte om. Holder derimot serveren på å svare en annen, blir forespørselen satt i kø. Denne køen kan bli full, det er bare et spørsmål om å sende mange nok forespørsler hurtig nok. Blir køen full har plutselig ingen tilgang til informasjonen. Ikke engang lovlige brukere.

8 - Usikker lagring

De fleste servere inneholder sensitiv informasjon. Dette kan være alt fra passord til kredittkortnummer eller personopplysninger. Disse må på en eller annen måte lagres. Dette skal selvfølgelig gjøres kryptert. Kryptering har dessverre den ulempen at det er mange feilkilder. Feilkilder i kryptering kan være blant annet:

  • Mislykket kryptering. Data er faktisk ikke kryptert.
  • Usikker lagring av krypteringsnøkler
  • Dårlige krypteringsalgoritmer som er lette å knekke
  • Ikke oppdaterte nøkler som er kompromittert

En annen ting det er vanskelig å beskytte seg mot er minnehåndtering. Man kan ha lagret noe kryptert, men når serveren skal bruke informasjonen til noe, blir det lagt i minnet på maskinen og da er informasjonen ukryptert og åpen for lesning.

7 - Dårlig feilhåndtering

Når en feil oppstår i serveren, skal det skje en prosedyre som gjør at den kan fortsette som normalt, om feilen ikke var kritisk. Dette kalles feilhåndtering. Om en hacker kan få en feil til å oppstå som har dårlig feilhåndtering, kan han i visse tilfeller få tilgang til sensitiv informasjon, stenge sikkerhet på serveren eller gjøre et DOS angrep.

6 - Injection

For å ta et veldig enkelt eksempel på hva injection går ut på: Man har en internettside med en tekstboks hvor man skal skrive navnet sitt og trykke OK. Så skal det komme opp en melding på skjermen hvor det står, i mitt tilfelle, "Hei, Christopher". Si at jeg ikke hadde skrevet Christopher, men heller en programmeringslinje som hentet ut alle brukernavn og passord fra en database. Da ville meldingen på skjermen gitt "Hei," og så alle brukernavn og passord lagret på serveren. Man kan selvsagt skrive inn andre ting i slike felter og gjøre veldig mye rart.

5 - Buffer overflow

Et hvert programmeringsspråk har sine begrensinger. Begrensninger i hvor mye informasjon den kan motta av gangen, hvor mye informasjon den kan lagre i minnet til en hver tid osv. osv. Ved buffer overflow overgår man disse begrensningene og får dermed uventede ting til å skje om man har en dårlig feilhåndtering (punkt 7). Man kan ved hjelp av buffer overflow krasje maskinen, kjøre hackerkode eller hente ut ellers utilgjengelig informasjon.

4 - Cross site scripting (XSS)

XSS går ut på at man sender en bruker eller en server et lite program som sender informasjon til et sted den egentlig ikke skulle gått. En vanlig metode er å sende en bruker et lite script gjennom vanlig internettsurfing. Script er noe alle moderne nettsider kjører og det er vanskelig å skille de vennlige fra de fiendtlige. Når en bruker har mottatt scriptet kan man få det til å ligge å kjøre i bakgrunnen og forandre forespørsler sendt fra den intetanende brukerens maskin. Den intetanende brukeren logger seg dermed på en lukket side hvor han har tilgang. Scriptet vil nå laste ned informasjon bak kulissene og sende det tilbake til hackeren.

3 - Identifiseringskontroll

Når man logger seg på en nettside, identifiseres man gjennom IP adressen man kommer fra. All trafikk blir sendt fram og tilbake i såkalte TCP pakker. Det er små pakker med informasjon som inneholder en "header" og en "payload" -del. Her er det header-delen som er interessent for en hacker. Header-delen sier hvem pakken er fra og hvor den skal. Her kan en hacker gå inn å "spoofe". å spoofe betyr at man forkler seg med en annen IP adresse. Man kan dermed overta identiteten til en annen bruker. En annen metode kalles "session hijacking". Her går man inn i mellom en allerede opprettet forbindelse og overtar sesjonen. Brukeren mister forbindelsen og serveren tror den snakker med samme bruker.

En annen enklere versjon av identifiseringskontroll kan være så enkelt som brukernavn/passord biten. De aller fleste nettsider med en form for innlogging, har en "glemt passord" sak. Her trykker man og ved noen anledninger får man et spørsmål man skal svare på for å få et nytt passord. Her er det mange feilkilder og det er ikke vanskelig å se for seg hvor enkelt det her kan være å overta en annens identitet.

2 - Tilgangskontroll

Når man logger seg inn på en side vil man først gå gjennom en autentiseringskontroll for å kontrollere at du er den du er. Så vil serveren, ut i fra hvem du er gi deg et tilgangsnivå. Her har du en liste over hva du kan og hva du ikke kan gjøre. Og her er feilkildene langt som et vondt år. Feilkonfigurering for det første. (punkt 10). Er det mange som synder på. Men den mest vanlige feilen er at man konfigurerte serveren riktig da nettsiden ble opprettet. Men siden den gang har siden vokst og man har fått mere funksjonalitet som krever mer tilgang for brukerne. Her er det ofte dårlig kode som gir midlertidig tilgang til visse funksjoner. Her skal det som oftest minimalt med kunnskap til for å få permanent tilgang til funksjoner og/eller ytterlige utvide tilgangsnivå. Det er så ille at ofte står brukernavn og passord skrevet i klartekst i koden.

1 - Uvaliderte forespørsler

Det mest brukte og farligste sikkerhetshullet på nettet i dag er at man ikke validerer forespørsler. Som beskrevet under "injection" (punkt 6) kan man sende forespørsler til serveren som får serveren til å gi ut informasjon den egentlig ikke skulle ha gitt ut. Man kan si at "injection" er en del av punktet uvaliderte forespørsler, men uvaliderte forespørsler kan gjøre så mye mer. Ved "injection" snakker man om typiske inputbokser og lignende. Ting man synlig kan se på skjermen. Men man kan sende serverforespørsler bak kulissene også. En server mottar forespørsler i form av såkalte "HTTP requests" og i noen tilfeller sender man en fil med informasjon som serveren svarer på. Det er disse som virkelig er farlige. Man kan kjøre hele programmer, slette filer, stort sett gjøre hva man vil om ikke serveren validerer forespørslene.

I alle store webserverprogrammer ligger det en god del basisk validering. Men det er vanskelig å validere alle forespørsler som kommer inn fra brukere. Ikke bare er det millioner av forskjellige mulige forespørsler, men man har også utallige mange måter disse forespørslene kan gjøres på. Den feilen som alle gjør, som gjør at dette punktet havner på førsteplass, er at man som regel prøver å validere hva som ikke er lov. Dette lar seg nesten ikke gjøre da det er så uendelig mange ting som ikke er lov å spørre serveren om. Det man må validere er hva som er lov. Her har man mye mer kontroll på hva serveren får lov til å svare på. Ulempen er at man må oppdatere hva serveren får lov å svare på for hver minste forandring man gjør på serveren.

Noen enkle forhåndsregler:

  • Anta at angriper har kildekoden
  • Overvåk og se etter angrep
  • Ha gode sikkerhetsstandarder
  • Feil på en sikker måte
  • Hold sikkerheten enkel
  • Minimer angrepsflate ved å installere kun det du må
  • Valider hva som er lov ikke hva som ikke er lov

Denne artikkelen er skrevet etter et foredrag fra Ragnar Harper som er Teknisk leder i Harper Security og bygger på OWASP modellen.

Lik oss på Facebook