Taggat med: SIEM

Identifiera log4j med OSS-Fuzz och några säkerhetshöjande tips

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)
  • Se över Er software bill of materials (SBOM)
  • Genomför regelbundet automatiska och manuella penetrationstester
  • Ö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

Photo by Danial Igdery on Unsplash

Test av Recorded Future Express

Svensk-grundade företaget Recorded Future har släppt ett browser-plugin som låter dig söka igenom IOC:er (Indicators of Compromise) på webbsidor.

Det kan först låta lite konstigt att man skulle vilja söka igenom webbsidor efter IOC:er men många SIEM-system i dagsläget såsom Moloch och Maltrail (som jag bloggat om tidigare) har webbgränssnitt.

Pluginet finns till Google Chrome, Edge samt Mozilla Firefox och för att använda det måste du registrera dig med en E-post och sedan erhålla en licensnyckel. Denna licensnyckel används sedan för att göra slagningar mot Recorded Futures databas över IOC:er såsom:

  • Checksummer över skadlig kod
  • Kolla upp CVE-nummer och prioritera sårbarheter
  • Domännamn som används för skadliga syften
  • Suspekta E-postadresser (kollar domänerna)

Pluginet är gratis att använda men viss data samlas in av Recorded Future (se nedan). Och har du en betalversion såsom Core eller Advanced så kan du länkas direkt vidare till din dashboard hos Recorded Future.

Nedan skärmdump visar på hur malware-kampanjen vid namn Gamaredon larmar på flertalet IOC:er:

Recorded Future Express
Källa: MalCrawler

Jag upplever det som om det mesta finns med hos Recorded Future och att täckningen är väl över 90% av alla kända IOC:er jag har kollat på.

Dock så finns ett antal URL:er inte med som IOC:er hos Recorded Future såsom denna:

  • message-office.ddns.net

Vilken uppenbarligen finns med på Maltrails IOC-lista över APT Gamaredon (pterodo, primitive bear). Tyvärr identifieras inte heller CVE 2017-0199 på sidan ovan hos MalCrawler. Men på en annan test-sida så identifieras CVE-2017-11882 korrekt (kanske har med bindestreck att göra?).

Här nedan är ett exempel där Checkpoint kollat på flertalet kampanjer och RF Express fångar upp alla IOC:er utmärkt. Du ser en röd eller gul prick till höger om checksumman som Chrome pluginet lägger till.

Här kan du testa Express:

Ny version av Windows Sysinternals Sysmon

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.

Här kan du ladda hem Sysmon: docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Identifiera Projekt Sauron (Remsec)

Detta är en guide till hur Er organisation kan identifiera den senaste avancerade skadliga koden vid namn Projekt Sauron.

Förutom att uppdatera antivirus med senate databaser så kan du även titta på nätverkstrafik för att se kommunikation till kontrollservrar (C&C). Ett till alternativ är att söka efter så kallade IOC:er (indicators of compromise).

IOC:er kan vara hashsummor, text-strängar, IP-adresser, URL:ar och mycket mer. Man kan säga att det är en typ av signaturer som är öppna, till skillnad från många antivirus-databaser som är stängda (förutom clamav).

Det finns ett antal gratis verktyg för att söka efter IOC:er samt ett antal olika öppna sammanställda listor med IOC:er.

Exempel på en IOC som identifierar Powershell verktyget Invoke Mimikatz:

Invoke Mimikatz Powershell

Ovan regel använder sig av Yara-formatet som är C-liknande. Yara är även ett öppet verktyg samt bibliotek till Python.

Följande metodik är framtagen av OpenIOC-projektet.

IOC metodik

lokiOch som du kan se av ovan process så är tanken att IOC:er snabbt ska gå att applicera i en mängd olika mjukvaror såsom IDS/IPS, SIEM, nätverket eller lokalt på en klient/server.

För att försöka identifiera Projekt Sauron så laddar jag hem först Loki-scannern:

wget https://github.com/Neo23x0/Loki/raw/master/loki.exe

Och sedan senaste signaturbiblioteket:

wget https://github.com/Neo23x0/signature-base/archive/754d19604d7c36580a3f254f341d220343ca9bdd.zip

Sedan måste du se till att hash-summan för loki.exe är korrekt samt att katalogstrukturen är korrekt. Sha256:

99239b002d76ea81fe239de2ad4d8fef4157ea0759a39e777a68e050df580342

Annars får du ett felmeddelande likt detta om katalogstrukturen är felaktig:

Traceback (most recent call last):
 File "<string>", line 811, in initialize_filename_iocs
WindowsError: [Error 3] The system cannot find the path specified: 'E:\\./signat
ure-base/iocs/*.*'
Traceback (most recent call last):
 File "<string>", line 1253, in <module>
 File "<string>", line 119, in __init__
 File "<string>", line 860, in initialize_filename_iocs
UnboundLocalError: local variable 'ioc_filename' referenced before assignment

När allt väl är på plats så är det bara att starta genomsökningen. Förslagsvis som en användare med behörighet att läsa processer och filer (Administratör):

LOKI IOC Scanner

Sen är det bara att vänta. En genomsökning kan ta flera timmar för en enda klient eller server.

När den är klar söker du efter följande text:

[RESULT] Indicators detected!
[RESULT] Loki recommends checking the elements on Virustotal.com or Google an
riage with a professional triage tool like THOR APT Scanner in corporate netw
s.
[NOTICE] Finished LOKI Scan SYSTEM: IE9WIN7 TIME: 20160813T10:53:49Z

Håll även koll på falska positiva (false-positives) indikationer. Windows sökverktyg SearchIndexer.exe gillar exempelvis att indexera upp dina signaturer och kan göra så att Loki varnar.

Loki arbetar med följande kontroller:

1. Filnamns IOC:Er
Regex-matchning på sökväg eller namn

2. Yara Regelkontroll
Yara signaturkontroll på fil eller process (minne)

3. Hashkontroll
Jämför hashar i en mängd olika format (MD5, SHA1, SHA256)

4. C2 kontrollkanal
Kontrollerar anslutningspunkter mot C2 IOCs (nytt sedan Loki version 0.10)

Och även följande presentations-bild från företaget Mandiant FireEye beskriver en indikator bra:

whats-an-indicator-copy_1

Senare kommer jag även gå igenom hur du använder verktyget Volatility för offline-analys, en av mina favoriter.

Denna guide fungerar för att identifiera nästan all skadlig kod, bara man vet vad man söker efter. Givetvis så bör även nätverkstrafik kontrolleras, men i fallet med Sauron så finns det ännu inga DNS-namn eller IP-adresser ut som man kan kontrollera för kommunikation och kontrollkanaler (C&C).

Och så klart underlättar nätverksforensik om du redan sparar undan DNS-uppslag eller all trafik som flödar ut/in på nätverket med trafikinspelning, något jag rekommenderar.

Värt även att poängtera är att när du exekverar kod såsom Loki i enlighet ovan så kan även detta innebära en säkerhetsrisk.

Men att kontrollera mot filnamn, hashsummor och annat är sådant som är statiskt. Antagonisten kommer bara att ändra sådant när hen blir upptäckt. Därför är det även bra att lära sig metoderna som nyttjas och kontrollera dessa.