Såhär i efterhand är det bra att dra lärdomar från log4j-sårbarheten och hur vi i framtiden kan förhindra liknande sårbarheter. En av mina personliga metoder är att genomföra fuzz-tester för att identifiera indikationer på att något är fel i ett system, bibliotek eller mjukvara.
Ett av Googles projekt som har identifierat flest antal sårbarheter genom tiderna heter OSS-Fuzz och drivs av ett antal backends såsom libFuzzer, AFL++ och Honggfuzz. I början av 2021 så fick libFuzzer stöd för att fuzza Java-kod med hjälp av Jazzer. Främst kod som är skriven JVM-baserade språk, såsom Java, Kotlin och Clojure.
Bildkälla: code-intelligence.com
För den fuzzing-kod som har hand om Remote JNDI-lookups så går den att se här. Men givetvis är fuzz-tester inte enbart den enda lösningen på att bygga säkra och robusta IT-system. Några andra säkerhetshöjande åtgärder för att försvåra attacker såsom Log4Shell (log4j) i framtiden:
Begränsa så att servrar och klienter inte får prata godtyckligt ut mot internet. Gäller även DNS-uppslag
Använd data-dioder för att föra in loggar i fysiskt separerade system. Till exempel en SOC/SIEM (airgap)
Öva regelbundet olika scenarior där ni exempelvis snabbt måste identifiera ett tredjepartsbibliotek och begränsa skadan som kan uppstå till följd av en sårbarhet
Se till att ni har verktyg som stödjer alla olika former av aktiviteter såsom den på raden ovan. Buzz-word för ett sådant verktyg kan vara Endpoint Detection & Response (EDR). Rekommenderar att snegla på Velociraptor (blogginlägg kommer)
Mjukvaror, system osv bör separeras så mycket som det går och gå med så låga behörigheter som möjligt. Se till att ha en förmåga att logga om en mjukvara avviker från detta
Ställ relevanta säkerhetskrav vid anskaffning av produkter och system. Följ upp så att dessa krav efterlevs
Jag tänkte försöka sammanställa några kloksaker om sådant som jag lärt mig efter nästan 20 års erfarenhet av tekniska cybersäkerhetsgranskningar från min tid inom bl.a. FRA, Försvarsmakten och nu som egenföretagare.
Desto äldre jag blir desto mer tid lägger jag på att reflektera och dra slutsatser på ett övergripande och bredare plan.
Det låter eventuellt inte som viktigt men att försöka uppskatta och prioritera den tid du fått avsatt för uppdraget är viktigt. Att inte lägga för mycket tid på sådant som kan leda in i en återvändsgränd ”down the rabbit hole”.
Beräkna tid
Låt verktygen arbeta för dig och automatisera så mycket du bara kan och på så sätt kan du lägga fokus på sådant som kräver manuellt arbete, såsom att förstå en bakomliggande logik i ett system eller mjukvara.
Lita dock inte enbart på automatiserade verktyg utan verifiera och dubbelkolla alltid resultatet.
Kommunikation
Att upprätta en bra leverabel såsom dokumentation (rapport) och ha förmåga att kommunicera denna leverabel till din uppdragsvidare är av stor vikt för framgång. Du kanske är jätteduktig teknisk men när uppdragsgivaren väl får din leverabel två veckor för sent så minskar värdet av din leverabel.
Vet du att du är mindre bra på att kommunicera och dokumentera men duktig på teknik se då till att ditt team innehåller en eller flera personer som kan kommunicera eller dokumentera.
Stödfunktioner och processer
Att ha bra processer och rutiner samt stödfunktioner som hjälper dig och höjer dig i ditt arbete så du kan leverera enligt din optimala förmåga är viktigt. Det kan röra sig om att du slipper gå på tråkiga möten där du kanske inte har något att göra eller minimera tidsrapportering. Eller att själv slippa installera om operativsystem, drivrutiner eller liknande.
Du kan i ditt arbete luta dig tillbaka till en bra grund när det gäller hur uppdrag kommer in, fördelas, prioriteras och sedan levereras. Samt efter avslutat uppdrag hur avdukning går till.
Tillgång till Internet kanske inte finns eller bör användas, därför måste du eller dina kollegor redan innan tänka till vad som kan behövas för offline-bruk. Jag brukar se till att ha många opensource-repon, indexerade digitala böcker (många förlag kan du köpa bulk billigt) samt deb-paket tillgängliga snabbt.
Här hittar du bristerna
Min erfarenhet säger mig att säkerhetsbristerna hittar du oftast på de ställen som:
Odokumenterade funktioner/gränssnitt/API:er
Ny eller gammal kod. Sök efter kod som hanterar gamla filformat eller protokoll exempelvis
Kod som parsar text eller andra komplexa funktioner
Funktioner som kan användas på andra sätt än vad utvecklaren hade tänkt på
Felaktig eller bristfällig separation mellan behörigheter eller användare
Ändringar mot grundsystemet. De flesta operativsystem nuförtiden är relativt säkra i sitt grundutförande, sök efter ändringar som genomförts.
Ställen där du kan nå långt in i systemet eller koden med extern indata
Finns givetvis en uppsjö till med saker där jag tittar, kanske kommer eventuellt i en bok framöver.
Spårbarhet
Att dokumentera dina findings under ditt uppdrag är av stor vikt. Speciellt eftersom att du troligtvis kan hitta ett eller annat guldkorn när du granskar exempelvis alla http-svar från webbservern eller all nätverkstrafik som du sparat undan i pcap-format.
Den efterföljande dokumentationen blir också otroligt mycket lättare om du sparat undan så mycket som möjligt. Även kan skärmdumpar eller liknande också vara bra som ett komplement till din löpande textdokumentation (krigsdagbok) eller rådata.
Glöm inte heller att du måste ha en process för att på ett säkert sätt radera all information efter avslutat uppdrag om så behövs, en del av Er OPSEC.
Tänk alltid ett steg längre
Du kanske är snabb på att skjuta iväg en ny exploit från Metasploit mot en sårbar server eller klient. Men tänk efter innan vad detta kan få för konsekvenser i ett andra eller tredje steg och ni behöver göra ett omfall.
Det kan vara så att säkerhetsövervakningen (SOC) upptäcker att ni håller på att genomföra en Red Teaming operation och då kanske ni behöver byta ip-adress, mac-adress eller liknande. Och då är det viktigt att redan innan veta hur detta går till.
Övrigt
Jag försöker även alltid ha möjlighet att göra saker på minst två olika sätt, det gör att jag kan verifiera och dubbelkolla vissa saker samt om ett verktyg eller metod skulle misslyckas kan jag alltid göra på något annat sätt. Öva är även viktigt så du och ditt team eller dina verktyg och metoder fungerar när det väl är skarp verksamhet eller ett uppdrag.
Se även till att du snabbt och enkelt kan sätta upp en miljö som efterliknar målsystemet eller den mjukvara som du granskar. Det gör att du kan hitta mer brister och inte behöver skicka alla dina tester över nätverket eller liknande.
Avslutande ord
Hoppas att detta kan leda till att du, din verksamhet eller ditt team kan bli bättre på just det ni gör inom cybersäkerhet. För jag tycker det är viktigt att vi delar med oss av våra lärdomar och kloksaker till varandra och på så sätt bygger vi säkrare infrastruktur, system och mjukvaror.
Se även till att utbilda din uppdragsgivare så denne blir en bra beställare, och hjälp till med krav och förväntningar samt förutsättningar.
Uppdatering: Nya versionen har nu släppts och event ID 22 representerar DNS-frågor:
Event ID 22: DNSEvent (DNS query)
This event generates when a process executes a DNS query, whether the result is successful or fails, cached or not.
is event generates when a process executes a DNS query, whether the result is successful or fails, cached or not.
Även så framgår följande uppdateringar i v10:
This release of Sysmon adds DNS query logging, reports OriginalFileName in process create and load image events, adds ImageName to named pipe events, logs pico process creates and terminates, and fixes several bugs.
Mark Russinovich som tillvardags är CTO på Microsoft Azure meddelade på Twitter att det kommer en ny version av System Monitor (Sysmon) idag Tisdag.
Denna nya version stödjer bl.a. DNS-loggning direkt till eventloggen i Windows. Både förfrågningar och svar loggas till eventloggen som DnsQuery.
När jag skriver detta under tisdagen har dock ännu inte den nya versionen av Sysmon släppts.
Skärmdump:
Ovan skärmdump visar att QueryResults returnerar 5 vilket är CNAME. Att logga svaren på detta sätt är bra vid SOC/SIEM och Threat Hunting eftersom svaren kan ändras med tiden och på detta sätt så får vi en ögonblicksbild hur frågan och svaret såg ut vid just detta tillfälle.
