Při řízení bezpečnosti informací je důležité mít zajištěnou dostupnost, důvěrnost a integritu dat včetně provozních. Poznáme zdrojpravdy, na který se můžete spolehnout, když ostatní bezpečnostní a forenzní data jsou kompromitována (nebo je jejich pořízenía zpracování příliš nákladné a složité). Projdeme jednotlivé kroky zajímavého bezpečnostního incidentu, jak se projevily v síťovýchlozích, jaký dodatečný kontext k útoku je možné zjistit ze síťové vrstvy, s jakou jistotou je dokážeme detekovat a jakým způsobemje možné problém zmírnit, nebo mu dokonce předejít. V závěru článku se zamyslíme nad tím, zda není bezpečnost malýcha středních podniků podceňována a zda by spolupráce s poskytovateli internetových služeb (ISP) nemohla přinést novémožnosti pro zvýšení kybernetické bezpečnosti.
Síťové logy Netflow Detekce útoků SME OT ISP
Úvodem
Na bezpečnost můžeme pohlížet jako na vrstvy. Primární vrstva má za úkol řídit, aby se uživatelé a systémy pohybovali pouze tam, kde to mají povolené, a nezpůsobili škodu nebo nějakým způsobem nezasáhli do kritických aktiv organizace. Žádný systém řízení ovšem není dokonalý. Proto tu máme druhou vrstvu – monitorující. Jednou z oblastní dohledu je chování hostů a identit v sítích (Network Detection & Response).
Vylíčený příběh jednoho incidentu je ilustrativní, syntetický a nejmenuje konkrétní subjekty. Vychází však z reálných zkušeností a může se odehrávat v některé síti např. i nyní. Navzdory této anonymizaci se pokusím co nejsrozumitelněji přiblížit situaci. Tento incident nepovažujeme za výjimečný, zároveň nevnímám, že je dostatečně v obecném povědomí.
Incident ke studiu
Pojďme se nyní podívat na onen příklad incidentu, kdy úvodní vektor útoku přichází přes ISP (internet Service Provider, tedy poskytovatel internetu). Pokusí se dojít až do OT sítě jednoho z firemních zákazníků ISP.
Většina útoků v kyberprostoru není cílených proti konkrétní organizaci. Přesto jsou velmi komplexní a sestávají se z několika navazujících kroků (kill-chain). Názorně se podíváme na jednotlivé kroky pro náš incident, vizualizujeme je na matici MITRE ATT&CK® a u každého kroku zodpovíme:
- jak se projevily v síťových lozích,
- jaký kontext k útoku je možno zjistit ze síťové vrstvy,
- s jakou spolehlivostí dokážeme útok detekovat,
- jakým způsobem šlo problém mitigovat, nebo mu dokonce předejít.
Podniková infrastruktura
Specifikujme SME podnik, na kterém ilustrujeme incident:
- 700 stanic – převážné stanice zaměstnanců, ale i další zařízení (segmentace sítě pomocí VLAN),
- kancelář je schovaná za routerem + dynamický firewall,
- servery podniku jsou hostovány u ISP včetně web serverů otevřených do internetu,
- relativně malá, ale důležitá OT výrobna/manufaktura.
Recon fáze / Průzkum perimetru
Pro SME je stále velmi častý vektor útoku přes otevřené porty na webových službách vystavených na veřejné IP adrese do internetu. Toto ale není náš úvodní vektor útoku. Není to ani cílená kampaň. V našem případě se jedná o tzv. spray & pray kampaň. Při této taktice se útočí na mnoho předem vytipovaných cílů (klidně až milióny). Útočník doufá a většinou má pravdu, že díky tomu množství se někam dostane. Úspěšně prolomené (či jen objevené „nezamčené“) zařízení se následně spojí k c2 (command & control) místem a pak se uvidí dál.
První fáze se nazývá „recon“ – každý den, každou hodinu jsou skenovány veřejné IP rozsahy:
- nejprve na otevřené porty,
- na těch otevřených je proveden dotaz, aby se zjistilo, jaká tam běží služba (např. http, ssh),
- ideálně i verze aplikace, která službu realizuje, např. Apache verze 2.4.
Příkladů používaných nástrojů v recon fázi je hodně:
- NMap, OpenVAS, OpenSCAP
- Metasploit
- Vuls (agentless vulnerability scanner)
- Archery (vulnerability assessment and management)
- w3af (web application attack and audit framework)
Tyto nástroje lze použít jak pro útok, tak na prevenci a monitorování vlastní bezpečnostní situace.
Obr. 1: Infrastruktura podniku
Obr. 2: MITRE ATT&CK® – PRE matice (zdroj: https://attack.mitre.org/)
Obr. 3: Obohacení síťových logů o reputaci IP adres
Detekce skenu
Ohněm kutaný a mnoha bitvami prověřený standard pro logy ze síťového provozu je tzv. netflow (RFC 3954 https://www.ietf.org/ rfc/rfc3954.txt). Popisuje každé síťové spojení, ke kterému došlo:
- kdo je zdrojem, kdo je cílem spojení (IP adresa, nikoli jméno), přes jaké porty a protokol probíhalo,
- např.:
- protokol: TCP
- zdrojová IP adresa: 10.2.3.44, zdrojový port 12345,
- cílová IP adresa, cílový port 443,
- TCP flags: SYN a ACK,
- může být obohaceno o další informace z L7 aplikační vrstvy nebo JA3 otisky.
Sken otevřených portů lze detekovat z netflow logů. Podle situace se odvíjí spolehlivost této detekce. Z pohledu podniku, který provozuje individuální webovou službu na jedné veřejné IP adrese, to není jednoduché – tato IP běžně přijímá mnoho spojení/dotazů, a to, že jeden z nich je cílený scan, není zřejmé. Avšak pro ISP, které má stovky, tisícovky, milióny veřejných adres, je to o poznání jednodušší – v datech lze rozpoznat clustery spojení o stejném chování vůči celému adresnímu rozsahu poskytovatele.
Spolehlivost detekce je možné ještě zlepšit, když flow data obohatíme o tzv. IP reputation feed.
Obr. 4: Infrastruktura ISP
Tento feed (informační zdroj) obsahuje informace o veřejných IP adresách, ze kterých odchází sken nebo útok (např. na SSH port 22), jak často, kdy naposledy. U feedu je také důležité, jak čerstvé a úplné informace obsahuje. Nejlepší je korelovat několik dodavatelů těchto informací.
Skenerů na internetu se nezbavíme, ty tu byly, jsou a budou. Nicméně ovlivnit úspěšnost útoků možné je. Pro SME můžeme např. nastavit dynamicky firewall a dočasně filtrovat již na perimetru provoz z těchto známých útočících IP adres. Pro velký podnik, který má velmi dobře zabezpečený perimetr, je zase zajímavé vidět, že útočící adresa není na žádném IP reputation listu, protože to může indikovat cílený útok.
Obr. 5: Ilustrace fází útoku v ISP síti v části MITRE ATT&CK® matice (zdroj: https://attack.mitre.org/)
Initial access fáze/počáteční průlom
Pojďme zpátky k našemu případu. Podniková síť byla zvenku dobře zabezpečená a používá dynamicky firewall.
Jiný případ je u infrastruktury ISP – aby mohla provozovat svou funkci, je neustále vystavena ven do internetu.
ISP (poskytovatel internetu)
- 8 000 připojených bodů,
- 12 000 síťových logů za sekundu.
ISP používá zařízení s RouterOS pro svou infrastrukturu. Tato zařízení jsou cenově přívětivá a velmi oblíbená v našich končinách i po světě. Není divu, že jsou cílem mnoha zranitelností.
CVE-2022-45315
Mikrotik RouterOs before stable v7.6 was discovered to contain an out-of-bounds read in the SNMP (Simple Network Management Protocol) process. Tato zranitelnost umožňuje útočníkům spustit libovolný kód prostřednictvím vytvořeného paketu.
Příklad CVE pro RouterOS
Jeden z routerů neměl poslední update firmware a fungoval jako jedno z core zařízení. Při jedné z mnoha spray & pray kampani, která zkoušela i zranitelnosti RouterOS, se útok dostal dovnitř. Spolehlivost detekce tohoto jevu je obtížná, protože tyto útoky probíhají často a ze síťového provozu nelze přesně zjistit, zda úspěšně proběhly další kroky.
Přesto v této fázi může ISP udělat preventivní akce:
- zavřít servisní porty směrem ven (to většinou dělají, bohužel miskonfigurace a lidské chyby jsou častým jevem),
- zlepšení kvality detekce útoku na servisní porty.
Např. můžete chtít, aby pokročilé NDR (Network Detection & Response) dokázalo kombinovat tři datové zdroje a v bezpečnostní politice je zohlednilo:
- sken zranitelnosti objeví na core zařízení zranitelnosti,
- na toto zařízení někdo posílá pakety na port spojený s touto zranitelností,
- a zároveň odesílatel paketu je na IP reputation deny listu.
Alert z takové politiky bude efektivnější než alternativní detekce jen pomocí netflow.
Obr. 6: Ilustrace fází útoku v podnikové síti v části MITRE ATT&CK® matice (zdroj: https://attack.mitre.org/)
Lateral movement fáze/rozšíření uvnitř sítě
Během našeho incidentu nebyla taková detekce implementována. Jeden z routerů ISP byl napaden a útočící skript eskaloval privilegia a získal kontrolu nad zařízením. Zároveň se úspěšně vyhnul tomu, že by si toho někdo všiml. Router se choval normálně. Uplynula nějaká doba a infikovaný router začal skenovat síť kolem sebe.
Našel další routery (ve stejné VLAN) a začal brute force útok na Telnet, SSH, Mikrotik winbox služby. Použít šlo např. nástroje nmap, hydra. V několika případech byl úspěšný. Není neobvyklé, že routery spolu komunikují. Brute-force útoky jsou ovšem často „hlučné“ (generují mnoho netflow logů). Lze je tedy s velkou jistotou detekovat právě z netflow logů a bezpečně odlišit od běžné vzájemné komunikace.
Průnik do firemní sítě
Jedním z nově infikovaných zařízení byl i router na perimetru jednoho z firemních klientů – to je onen podnik s 700 hosty.
Gateway router samozřejmě vidí na všechna další zařízení v kanceláři. Vidí tunelem i do hostingu u ISP, kde jsou servery s aplikacemi a databázemi. Z tohoto zařízení lze také vidět na firewall OT sítě, která se stará o výrobu. V tuto chvíli se ovládnutý router pokouší připojit k c2 (command & control). Nejprve skrze DNS resolving (překlad URL na adresu). Poté přímo na několik IP adres. Firma neměla v době incidentu aktuální feed potenciálních škodlivých IP adres s malware c2. Díky komunikaci s command & control centrem a již zjištěným informacím i okolní síti infikovaného zařízení se do infikovaného zařízení stáhly další postupy šité na míru pro útok na aplikační a databázové servery a dále specifické postupy k OT síti.
Kampaň pokračovala a začala nikoli agresivně, ale pomalu zkoušet prolomit se dál k hodnotnějším cílům.
Změny chování na perimetru OT sítě si všimnul IDS Intrusion Detection System (open-source system Suricata https://suricata.io/). S í ť n e l ž e Změna chování u spojení k databázovému serveru byla odhalena z netflow dat. Zmiňme tady jeden pozitivní aspekt. Na endpointu je pro útočníka s privilegovaným přístupem jednoduché po sobě zamést stopu (smaže logy, upraví záznamy o přístupu). U síťových logů může být situace lepší, lze např. implementovat nezávislé generování netflow pomocí pasivních sond (viz Obr. 7), které jsou zapojeny takovým způsobem (přes tzv. optické TAPy), že jsou neviditelné pro ostatní zařízení v síti. Tyto logy jsou pak odesílány do nezávislého kolektoru mimo lokální síť, kde probíhá monitorování.
Zpětná reprodukce incidentu
V této chvíli se díky informacím nasbíraným ze síťového provozu IT technik/administrátor dozvěděl, že se něco děje. V podniku sice nemají implementované EDR řešení (End-point Detection & Response). Ale síť byla smysluplně segmentovaná. Pro analýzu měl k dispozici netflow síťové logy a logy z IDS, ze kterých dokázal zpětně rekonstruovat, co se událo. Jsou sice slepá místa v kill-chainu, kde ze síťového provozu mnoho nezjistíte, ale taky je tam plno míst, kde s poměrně vysokou spolehlivostí dokážete odhalit různé jevy a indicie útoku. Obzvláště při kombinaci více zdrojů dat a následné automatizované pokročilé korelaci tak dokážete reagovat i na nové či nespecifické pokusy o útok a včas zabránit jejich šíření.
Obr. 8: Příklad fází, kde jsou síťové logy slepé
Bilance na závěr
Také je dobré vzít v úvahu, že často až samotný incident je pro organizaci dostatečně skutečným impulsem pro zlepšení bezpečnosti. S forenzními daty, o která je možné se opřít, je tato změna jednodušší a diskuze s vedením bývá konkrétnější. Na příkladu jsme viděli několik míst, kde podnik po diskuzi s ISP dokázal zlepšit prevenci nebo zavést zmírnění podobných útoků. Významným posunem by tak byla např. i ochrana firemního perimetru již na straně ISP. Firemní zákazníci by tam měli trvat na tom, aby jejich ISP byl schopen aktivně bránit svou i zákaznickou infrastrukturu včetně nasazení pokročilých nástrojů, procesů a metod pro analýzu síťového provozu.
V tomto příběhu se útok dostal hodně daleko. V podstatě skoro těsně až k cíli. Naštěstí nedošlo k žádné skutečné škodě ani k výpadku kritických služeb. Dokonce se utužil vztah mezi ISP a jeho firemním zákazníkem při dohledání a mitigaci problému, kde museli spolupracovat.
Otevřená diskuze
Pro autora má tento incident několik ponaučení:
- Netflow data jsou skvělým lepidlem mezi jednotlivými kroky útoku, které probíhají na různých strojích.
- Síťové logy jsou nezbytné při zpětné forenzní analýze, co a jak se vlastně událo – při hledání jehel v kupce sena.
- Síť nelže – na endpointu je pro útočníka s privilegii jednoduché po sobě zamést stopu. U síťových logů to nelze. Při nasazení sond nebo vhodném nastavení síťových prvků jsou tyto generovány nezávisle a vždy.
- S přicházející novelizací zákonů o kyberbezpečnosti u nás i v EU bude hodně firem a ISP povinováno reportovat incidenty. První věc při vyšetřování, o kterou si CSIRT/CERT nebo úřad řekne, jsou logy včetně těch síťových.
- Útoky rády přicházejí přes nejslabší článek v řetězci. Článek nechce vykreslit ISP jako toho „zlého“. Je to naopak. Diskutujme, zda právě ISP jsou ve skvělé pozici, protože mají zkušenosti s netflow logy a dokážou v nich číst. Jsou schopni takové řešení pro své zákazníky efektivně implementovat – uvést do provozu – a možná i dohlížet. Obzvláště neschopnost pravidelné profylaxe a neustálého dohledu bezpečnostních komponent je často pro menší a střední podniky nedosažitelnou metou, a bezpečnost tak zůstává v říši papírových opatření nebo zbožných přání. Právě zde je šance pro ISP vytvořit službu s velkou přidanou hodnotou za efektivní náklady pro své zákazníky.
This email address is being protected from spambots. You need JavaScript enabled to view it.
