Når normalen brytes: Slik avsløres digitale trusler i OT-nettverk
I forrige artikkel, «Malware i maskinrommet: Avvik fra normaltilstand», ble det gitt et overblikk over et forenklet industrielt miljø som ble utsatt for angrep. Denne artikkelen tar et videre dypdykk i de tekniske detaljene rundt dette miljøet.
Industriell kontrollsystemer bruker forskjellige protokoller for å kommunisere mellom seg. De protokollene kjører på ulik port og støtter ulike funksjoner. Det er viktig å bli kjent med dem hvis man operer med kontrollsystmerer.
Image Source: ICS Cheat Sheets | It’s Not Cheating If You Have an Effective and Safe Approach!
Modbus TCP/IP
Modbus TCP er en av de mest brukte protokollene som blir brukt mot PLC, RTU eller andre kontrollsystemer.
Ved å ta en nærmere titt på definisjonen av Modbus TCP ser vi at alle pakkene er som regel like lange.
.png?width=1343&height=105&name=image%20(3).png)
Følgende bilde viser «en sesjon» for protokollen.
Bildet viser at klienten ønsker å lese (0x03) fra en enhet som har id 9 (0x09). Og klienten ønsker å vite verdien på Register 1 (0x0001).
Serveren svarer med samme funksjonskode (0x03) og verdien (0x005). Dette kan for eksempel være trykket i en tank.
Hvis vi ønsker å skrive til en enhets register kan vi bruke funksjonskode 0x06, og da med en verdi av 0x0001 for eksempel. Dette kunne vært sendt for å starte en pumpe.
Slik sender kontrollsystemene pakker fram og tilbake for å styre et komplekst anlegg med pumper, tanker, eller maskineri.
DRAGOS skriver at over 46000 enheter er offentlig tilgjengelig via denne protokollen. Og det gjør det veldig attraktivt for trusselaktører når de kan nå industrielle kontrollsystemer ved å sende noen Modbus pakker.
Dragos-FrostyGoop-ICS-Malware-Intel-Brief-0724_r2.pdf
Hvis det er behov, på en enkel måte, å simulere Modbus trafikk mellom «master» og «slaves» så ligger det et Github repo tilgjengelig for dette:
Hvis det er behov for å simulere kontrollsystemer så kan man bruke en kombinasjon av OpenPLC og Factory.io
OT malware
Hvordan bruker så skadevare Modbus protokollen for å angripe industrielle kontrollsystemer og anlegg? Det finnes flere metoder og varianter av skadevare. Jeg skal bruke FrostyGoop skadevaren som utgangspunkt. Det er mulig å laste den ned her: https://bazaar.abuse.ch/browse/tag/FrostyGoop/
Etterforskningsrapporter viser at FrostyGoop brukte en JSON fil for få instruksjoner på hva den skulle utføre. Her er det to JSON filer med to ulike instruksjoner.
Bildet til venstre viser at funksjonskode 1, «Read Coils», skal kjøre mot 127.0.0.1.
Bildet til høyre viser at instruksjonskode 15, «Write Multiple Coils», skal kjøre med en verdi av 0x11110000.
Det skjer ofte i rekkefølge, men nødvendigvis ikke innenfor samme tidsrom. Som angriper ønsker man å vite noe om kontrollsystemet og sender derfor «Read» instruksjoner mot systemet. Deretter må verdiene tydes og forstås for så å sende en «Write» instruks.
Hvis vi ikke ønsker å gjenbruke skadevare kan vi kode vårt eget i Golang ved hjelp av biblioteket “rolfl\modbus". Det er ganske enkelt å lage et program som kommuniserer med kontrollsystemer, siden protokollen er enkel. Og det bare en nettverkspakke som skal sendes for å få det svaret man er ute etter.
Her er et forenklet eksempel basert på tidligere bildet til høyre. Legg merke til at variabelen vals blir initiert med lik verdi som på bildet, og client utfører samme funksjonskode som på bildet.
Se for deg nå at det programmet nå kjører kontinuerlig uten stans.
Hva skjer her, i bildet under, som kan være unormalt? Muligens vanskelig å se og gjette:
Svaret er at her blir både pumpen slått på og avløpet (Discharge valve) åpnet. Og dette skal simulerer en oppførsel som egentlig burde være umulig å få til. Når det kommer til vann så skjer det muligens ingen skade, utenom skade på utstyret. Men det kan være andre miljøer der to ting ikke burde skje samtidig.
Zeek deteksjon
Et maskineri eller anlegg operer i et mønster slik at flere moduler kan operere med hverandre. Det er dette som er normaltilstanden. Men når det kommer en ukjent applikasjon som begynner å sende instruksjoner så oppstår det en unormal tilstand som vi burde klare å detektere.
Nedenfor har jeg skrevet et Zeek script som generer varsler om det er en optikk av en spesifikk instruksjon, eller om det plutselig blir en stor mengde Modbus pakker.
Scriptet fungerer på denne måten: Hver gang det kommer en Modbus pakke vil zeek ha kontroll på hvem som sendte den og hvilken instruksjon som ble sendt. Det vil så måles til en threshold verdi som er satt i toppen av scriptet. De verdiene er knyttet opp til tidsvinduet som det måles i (epoch). Om det er ett sekund eller ett minutt, er det mulig å justeres.
Filename: modbus-thresholds.zeek
Og det vil se slik ut:
Denne loggfilen kan så mates inn i en SIEM-løsning for deretter å generere varsler, og ikke minst en rask respons og etterforskning av dette avviket.
Oppsummering
Vi må bli kjent med OT-miljøet for å ha en riktig deteksjon og respons. Vi må vite hvilke protokoller som blir brukt, og hvordan normal tilstanden ser ut. Det hjelper også å vite hvordan anlegget er strukturert og hvilket komponenter som er i drift.
Uten denne informasjonen så har vi ingenting der å gjøre!
Men når vi har den den informasjon kan vi se etter avvik og bygge opp alarmer rundt normaltilstanden, på et plan som ligger nært kontrollsystemene.
Les mer
Når er det riktig å leie inn en CISO?
Kritisk tenkning i sikkerhetsanalyse: Redusere subjektiv tolkning
Malware i maskinrommet: Avvik fra normaltilstand
