Taggat med: IDS

NSA varnar för TLS-inspektion

NSA

Amerikanska säkerhetsmyndigheten NSA går nu ut och varnar för  Transport Layer Security Inspection (TLSI). Anledningen till att NSA nu varnar för TLSI är för att metoden att granska nätverkstrafik som går in och ut ur organisationer blir allt vanligare samt att denna metod även medför ett antal olika säkerhetsrisker.

Några anledningar till att TLSI blir allt vanligare är för att kontrollera att nätverkstrafiken inte innehåller någon form av skadlig kod eller att klienter kommunicerar med skadliga webbplatser eller Command and Control-servrar (C&C). Denna form av inspektion kan också förekomma i enheter såsom Deep Packet Inspection (DPI) eller NIDS/IDS, Network Intrusion Detection Software.

Exempel på hur det kan se ut med och utan TLS-inspektion:

Bild från NSA

Problemen som NSA pekar på

Men vilka problem är det då som kan uppstå med denna set-up? Jo det finns flertalet problem som jag tänkte gå igenom här:

Validering av certifikat – Tidigare undersökningar visar på att certifikatvalideringen i TLSI-enheter inte varit 100%-ig och detta ökar risken för bl.a. man-i-mitten attacker.

Algoritmer och SSL/TLS-versioner – Precis som förra punkten så kan brister i SSL/TLS-handskakningen eller val av algoritmer påverka säkerheten såsom nedgraderingsattacker.

Tillgången till klartext – Det finns en punkt i organisationen där någon kan läsa och modifiera klartexttrafik. Detta är ett problem ur säkerhetssynpunkt men även integritet. Ett intrång kan även leda till att klartexttrafik kan läsas.

Insiderhotet – En person som har tillgång till trafiken kan läsa ut lösenord. Se till att ha en särskild granskningsroll som kan se vad TLSI-administratörerna gör för något.

Observera också att en TLSI kan användas både för utgående trafik från klienter men även inkommande (reverse proxy) för exempelvis webbsajter. Värt att nämna här är även den sårbarhet i F5:s produkter som Christoffer Jerkeby hittade. Vill du själv testa TLSI så kan jag rekommendera Erik Hjelmviks PolarProxy.

En annan sak som NSA lyfter i rapporten är även att du bör undvika att bädda in flertalet produkter där din klartext flödar. Försök att hålla ner komplexiteten för riskerna ökar med antalet produkter samt så försvåras felsökning. Certifikatspinning kan också bli ett problem samt så påpekas att HTTP Strict Transport Security (HSTS) inkluderar stöd för att binda en TLS-session(?).

Rapporten från NSA kan du hitta i sin helhet här:

NSA tls rapport
MANAGING RISK FROM TRANSPORT LAYER SECURITY INSPECTION 

Källa: NSA

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.

IT-Säkerhetsmjukvara nu under exportkontroll

waFör några dagar sedan så enades ett 41 länder om att uppdatera The Wassenaar Arrangemanget (WA) som begränsar vad som får exporteras från de länder som skrivit under avtalet.

Sverige är ett av dessa länder och exporten kontrolleras av myndigheten ISP.

Dessa nya uppdateringar innefattar bl.a. IT-säkerhetsmjukvara som försvårar upptäckt av övervakningsmjukvara.

För att försöka sammanställa dessa uppdateringar inom IT-säkerhet:

Mjukvara..

  • som ändrar ett programs naturliga exekveringsväg med hjälp av externa instruktioner. Exempelvis exploits eller cracks.
  • som exfiltrerar information från en dator eller nätverksenhet.
  • som försvårar upptäckt på nätverk/Internet. Exempelvis i syfte att kringgå intrångsdetekeringsprodukter (IDS).

Skärmdump från sida 209 i WA:

WA