Co je zranitelnost? Jsou to slabiny v systému nebo řešení vznikající například, když máte zastaralý systém, špatně nakonfigurovaný, nebo v nejhorším případně špatně naimplementovaný, zde již pak nepomůže ani „svěcená voda“. V rámci zranitelností existuje systém hodnocení CVSS (Common Vulnerability Scoring System) reprezentující na škále od 0 do 10 o jak závažný problém se jedná.
Noční můra č. 1 – Přišel email
Příkladem kritické a velmi problematické zranitelnosti je v Microsoft Outlook (CVE-2025-21298) s hodnocením CVSS 9,8, která umožňuje spuštění kódu a to bez zapojení uživatele, tzv „Zero-click“. Většina útoků přes email je založena na linku, který je v textu a uživatele odkáže na fiktivní stránky, kde se poté snaží vylákat informace ke zneužití. V případě této uvedené zranitelnosti však toto vše odpadá a útočníkovi stačí poslat infikovaný RTF soubor v příloze a díky zranitelnosti v knihovně pro náhledy dokumentu dojde automaticky ke kompromitování systému. Zcela bez zásahu uživatele. V těchto případech je řešením patchovat systém a hlídat aktualizace.
Noční můra č. 2 – Budeš sloužit nebo zemři
Další závažnou zranitelností je zneužití služeb TCP/IP Stack (CVE-2024-3808, CVSS 9,8, „Zero Click RCE/Remote Code Execution“) které běží na serveru a zpracovávají dotazy ze sítě. V tomto případě je útočník schopen zařídit vzdálené spuštění příkazu s privilegovanými právy nebo „spadnutí“ operačního systému na serveru a administrátor ani uživatel s tím nemůže nic dělat. Stačí, aby poslal do sítě speciálně upravený paket IPv6 a systém příkaz vykoná, případně skončí na modré obrazovce. Tato zranitelnost se bohužel týká celé Microsoft infrastruktury a může způsobit kompletní nefunkčnost celého firemního systému. První krokem k ochraně, je-li to však možné, je vypnutí IPv6 protokolu. A opět záplatovat systém.
Noční můra č. 3 – Už nejsem ve „virtuálu“
Dnes je běžnou praxí provozovat na fyzických serverech řady virtuálních operačních systémů pro různé potřeby, typicky prostřednictvím platformy VmWare (Broadcom). Tyto systémy lze snadno spravovat a vzhledem k možnosti oddělení prostředí představují i bezpečnostní vrstvu pro případný útok, protože nemají přístup na hostitelský systém. Tak to do nedávna platilo. Díky zranitelnosti ve Vmwaru (VMSA-2025-0004) je nově možné „vyskočit“ z VM do hostitele.
Pokud jsou serverové farmy, díky schválenému řízení rizik, udržovány s nižší úrovní bezpečnosti, tak teď je třeba situaci obratem přehodnotit. Protože stačí mít nasazený virtuální stroj se zranitelností a skrze něj je pak možné zkompromitovat hosta a následně získat přístup k celé hostitelské infrastruktuře, a tedy i ke všem virtuálním systémům. Řešením je zde také aktualizace.
Patch management a testování
Z výše uvedeného vyplývá, že většinu problémů řeší použití aktuálních záplat nebo aktualizace systémů. Otázkou však zůstává, jaký máte nastavený systém pro řízení těchto záplat, jak často probíhá kontrola, a co teprve testování?
Máte-li vývojářské, testovací a produkční prostředí, nasazování změn, včetně záplat, probíhá postupně a do „ostrého“ prostředí se dostane až ověřená verze, která nijak neovlivňuje funkce systému. Jak však zaznělo na konferenci Fresh IT, přístup k aktualizacím se dramaticky liší. Někdo spoléhá „že to bude fungovat hned“, jiní mají testovací „sandbox“ a další třeba v poslední fázi uživatelku Marušku, u které, když to funguje, tak je vše v pořádku.
Správce bezpečnosti je mezi mlýnskými kameny. Kdy nasadit záplaty, které jsou známé a zároveň už jsou aktivně zneužívané? Není na to jednoznačná odpověď, protože nedostatečné testování může firmu stát následné obnovování systému ze záloh. Zneužití zranitelnosti zase může vést například k zašifrování všech systémů, při tzv. ransomware útoku, kdy nejenom nebudou data k dispozici, ale zároveň útočníci mohou zveřejnit citlivé údaje.
Lahůdka na závěr
Veškeré snahy administrátorů o ochranu systémů jsou liché před útoky prostřednictvím oficiálních dodavatelů, jedná se o tzv. „Supply chain attack“. Pokud cílený útok započne v průběhu vývoje nebo aktualizace systému. Kompromitovaný kód je vložen přímo do knihoven oficiálního systému a ten je pak prostřednictvím záplat nasazen v cílové firmě.
Otázkou však stále zůstává, jak dlouho záplaty testovat? V minulém roce jsme byli svědky fatálních důsledků opomenutého testování, kdy byly updaty ihned nasazeny. CrowdStrike Attack si budeme dlouho pamatovat. Je tady však i útok na platformu Orion firmy SolarWinds, kdy útočník čekal několik měsíců od doručení otrávené aktualizace, než začal „škodit“ a napadeno bylo přes 18 tis. zákazníků SolarWinds.
A jak se bránit? Zde platí zlaté pořekadlo: „Důvěřuj, ale prověřuj!“, tedy testovat před nasazením vše, i od prověřeného dodavatele.