I slutten av juni 2022, rett før fellesferien, var det mange nettstedeiere som fikk det motsatte av den planlagte sommeravslappingen:
Den russiske hacker-konstellasjonen Killnet annonserte at norske nettsteder skulle rammes.
Med utenriksministeren som "posterkvinne" var det å forvente at spesielt offentlige nettsteder ville bli målrettet, men private virksomheter gikk heller ikke fri.
Juni, 2022: Den russiske hackergruppa Killnet angriper Norge - flere nettsider nede
Ingen er trygge
Arbeidstilsynet var tilfeldigvis en av de første til å bli rammet, og mediene brukte i de første dagene dette som eksempel på det pågående angrepet.
At Arbeidstilsynet både måtte håndtere en mediestorm samtidig som de skulle finne ut av og avverge angrepet kan jeg levelig se for meg ikke hjalp på situasjonen. Arbeidstilsynet er et viktig organ i Norge, men deres nettsider kan vel ikke sies å ha en spesiell stor signaleffekt i den pågående krigen i Ukraina.
Mediadekningen derimot, det å skape frykt og usikkerhet gjennom en handling, er ofte en lik stor drivkraft for de som bedriver hacking og der lyktes Killnet.
Samtidig viser angrepet fra Killnet at ingen er trygge når det kommer til sine digitale tjenester - alle nettsider er potensielle angrepsmål! At den norske regjeringen og NSM blir angrepet er som forventet, men at Bastø Fosen opplever angrep er ikke like innlysende..
Justisministeren: - Alt tyder på at angrepet kom fra et russisk miljø
Gjort research i forkant
Hackere bruker i dag mange ulike verktøy for å både analysere nettsteder og digitale tjenester samt gjennomføre angrepene.
Mye av dette er automatisk og lite sofistikerte teknikker og taktikker. Det er litt som å skyte en pil inn i en tett skog og håpe at du treffer et mål. Så lenge du ikke bryr deg om hva du treffer så er sjansen stor for at du i hvert fall treffer noe.
Med ansvar for drift og sikkerhet for veldig mange av de største nettstedene i Norge, spesielt i det offentlige, så sitter vi med mye informasjon om angrepene.
Flere har vært ute og sagt at angrepene har vært enkle og relativt ufarlige. Vi deler oppfatningen om at de var mindre avanserte enn tidligere angrep av liknende type, men vi så også en del målrettede angrep som bar preg av god research i forkant samt forsøk på store distribuerte angrep (DDoS).
«Vi så også en del målrettede angrep som bar preg av god research i forkant, samt forsøk på store distribuerte angrep.»
Angrep på applikasjonsnivå
Det andre vi så var et helt klart skifte i retning av OSI Layer 7-angrep; angrep på applikasjonsnivå.
Skytjenester og leverandører av sikkerhetstjenester har blitt bedre til å beskytte infrastruktur mot angrep, noe som gjør at applikasjonene bli mer interessante angrepsmål. Cloudflare sine rapporter viser den samme trenden.
Angrep rettet mot applikasjonslaget krever en god del infrastruktur på angriperens side, godt hjulpet av store botnet.
Man tror at Killnet disponerer over 4 millioner maskiner på verdensbasis. Det finnes heldigvis god beskyttelse mot applikasjons-angrep, men det er en øvelse på slakk line å stoppe uønsket trafikk samtidig som man slipper gjennom den legitime trafikken uten at underliggende infrastruktur slipper opp for CPU, minne og andre ressurser.
Automatisk skalering tar deg et langt stykke på vei, men det blir et kappløp mellom hvem som har mest ressurser. Uønsket trafikk bør stoppes på utsiden av applikasjonen, og om det ikke går, stoppes i applikasjonen med minst mulig bruk av ressurser.
- Det virker som at Killnet først og fremst går mot sårbare mål som ikke har gjemt seg bak DDoS-beskyttelse
Målretter RSS-er og API-er
Det viktigste verktøyet her er en Web Application Firewall (WAF) som kan identifisere uønsket trafikk og stoppe denne raskest mulig.
Det kreves god kompetanse på konfigurasjon og oppsett av regler som forhindrer mye av trafikken uten at det merkes eller påvirker vanlige besøkende. Under et angrep må du ha gode varslingsrutiner som lar deg ta grep raskt og med så stor treffsikkerhet som mulig.
Her snakker vi ikke om 100 millioner forespørsler til startsiden, som en WAF bør stoppe mer eller mindre automatisk.
Vi snakker om noen hundretusener av forespørsler mot en dårlig skrevet RSS feed (som kanskje har parametre som lar den returnere mye data og er tung for den underliggende databasen). Søkesider og AJAX (HTTP Rest)-kall er andre eksempler vi har sett hackerne forsøke å benytte seg av for å bruke opp alle tilgjengelige ressurser og på den måten ta ned nettsiden.
- Sammen med likesinnede land fordømmer vi disse angrepene
Sårbare for kall
Det er tidkrevende for hackere å utføre slike angrep, her kan de ikke skyte blindt, men må sikte på ett og ett tre. Med tid og kompetanse har de dog større sjanse for å lykkes. Dette setter større krav til oss utviklere som lager digitale tjenester og nettsteder som er eksponert på internett.
Dette er forsåvidt ikke noe nytt, vi har jo forholdt oss til angrep av ymse slag i lang tid, men da har det ofte handlet om å stoppe misbruk. Stoppe angrep hvor målet for hackerne er å komme seg inn på innsiden hvor defacing, løsepengevirus og selvfølgelig det å få tak i informasjon de ikke skal ha har vært ønsket resultat.
Noen av nettstedene under vår beskyttelse hadde funksjonalitet som gjorde dem sårbare for kall som krever mye serverressurser. Dette var typisk REST API-er med parametre som gjør søk eller oppslag i bakenforliggende systemer eller integrasjoner med on-premise systemer (det vi ofte kaller kjernesystemer).
Fellesnevneren er at dette er systemer som ikke er designet for stor trafikk, men fungerer helt fint med "normal" trafikk. Det kan også være normal funksjonalitet på et nettsted, som et fritekstsøk. Det meste av dette kan man dog beskytte seg mot med en god implementasjon, men det kommer med en pris i økt utviklingstid og mer kompleksitet.
«Et annet godt tiltak er å gjøre en kritisk vurdering av egne API-er.»
Vurder egne API-er
Dagens Web Application Firewalls er gode til å stoppe mange typer angrep, også på applikasjonsnivå. Utfordringen er imidlertid at en dedikert hacker som bruker nok tid på å analysere funksjonaliteten på et nettsted ofte kan finne funksjonalitet som krever mye ressurser på serveren.
Et målrettet angrep behøver dermed ikke være stort for å påføre nettstedet problemer og er i praksis et tjenestenektangrep som en WAF ikke fanger opp.
Sikkerhetsfokuset på nettsteder med mye funksjonalitet har vært rundt input-validering, XSS, SQL injection osv, men veldig lite på for eksempel rate limiting. Dette har vært ansett som en infrastrukturoppgave og ofte falt mellom to stoler.
Om søkesiden din har masse funksjonalitet og tillater filtrering og fasettering på flere nivåer er det ofte vanskelig å cache. Mange unike og brede søk kan skape problemer. Hvis ytelsestestene viser at du kun takler 10 søk i sekundet før køene begynner, så burde du lage en form for rate limiting som gir feilmeldinger når antall søk overskrider grensen.
Et annet godt tiltak er å gjøre en kritisk vurdering av egne API-er. Som utvikler er det lett å "legge til bare ett filter til". Kjekt å ha, da kan vi gjøre noe kult i fremtiden (kanskje). Dette er kanskje ikke eksponert i UI-et engang, men øker antall forskjellige kombinasjoner betraktelig.
Gutta bak 03 Cyber-podkasten: - Vi henger etter i Norge
Beskyttelse på applikasjonsnivå
En Web Application Firewall vil absolutt hjelpe og er en viktig komponent i din arkitektur, men om det er mange angrepsfaktorer som krever lite innsats av hackeren som minsker effekten av en WAF betraktelig.
Under angrepene fra Killnet overvåket vi våre kunders nettsteder nøye. Når vi så betraktelig økt ressursbruk gjorde vi vurderinger basert på trafikkmønsteret og sperret eller satte på "challenge" på de forespørslene som skapte problemer.
Dette fungerer fint når du har et team som sitter med fingeren på pulsen, men ikke like bra når du må vente til et angrep får effekt og alarmene går. Da opplever du treghet og potensielt nedetid før du rekker å ta aktive grep.
Derfor er det viktig å legge inn mer beskyttelse på applikasjonsnivå. Ikke bare beskytter du potensielt sårbare ressurser, men du øker også kravene til ressurser fra angriperen og samtidig sjansen for at en WAF skal fange opp utfordringen og stoppe angrepet på infrastrukturnivå.
«I analysene vi gjorde under og etter angrepene så vi at kunder som har lagt inn slik beskyttelse i egen kode hadde angrep, men alarmer for treghet ble ikke trigget.»
Ikke siste gang
I analysene vi gjorde under og etter angrepene så vi at kunder som har lagt inn slik beskyttelse i egen kode hadde angrep, men alarmer for treghet ble ikke trigget.
Veldig mye ble stoppet før det krevde mye serverressurser. Vi så til dels store distribuerte angrep der applikasjonen holdt stand i lang tid før WAF-en tok over.
Norske sikkerhetsmyndigheter er klare på at dette ikke er en engangsforeteelse, vi må forvente nye angrep i fremtiden. Akkurat nå er det krigen i Ukraina det handler om og vår nærhet til Russland gjør oss til et interessant mål. Tidligere har det vært upopulære politiske utspill og reaksjoner og utdelingen av Nobels fredspris har jo også potensiale for å skape uønskede hendelser.
Mange eiere og ansvarlige for norske nettsteder har nok tenkt at de er både for små og uinteressante for hackere.
De siste tiders hendelser viser at det ikke stemmer.
