Kdyby vás napadli minulý týden, poznali byste to dnes?

Nedávný incident na ČVUT i vyhlášené kritické zranitelnosti PHP připomínají nepříjemnou skutečnost: instalace bezpečnostní opravy řeší chybu směrem do budoucna, ale neodpoví na otázku, co se na serveru dělo v minulosti.

ČVUT 22. října potvrdilo kybernetický útok související s celosvětovou vlnou pokusů o napadení webů využívajících PHP. Přesný způsob útoku ani konkrétní zneužitou chybu univerzita nezveřejnila. Do stejného období však spadá zveřejnění kritických zranitelností známých jako PHP2Shell, pro které byly opravené verze PHP vydány 21. října. Aktualizace je zásadní krok, ale samotný patch celý problém nemusí vyřešit.

Co se dělo před vydáním opravy?

Amazon Threat Intelligence zachytil ve své honeypot síti MadPot pokusy o zneužití PHP2Shell už 17. října – tedy čtyři dny před veřejným zveřejněním opravy. To neznamená, že stejné útoky úspěšně proběhly na vašich produkčních systémech. Ukazuje to však riziko, že datum zveřejnění zranitelnosti bývá málokdy prvním dnem, kdy se ji útočníci pokusili využít.

Datum zveřejnění zranitelnosti nemusí být prvním dnem, kdy se ji někdo pokusil využít.

Pokud byl server s neopravenou verzí několik dní přístupný z internetu, nestačí se ptát pouze na to, zda je patch nainstalovaný. Stejně důležité je zjistit, zda se na systému nic nestalo ještě před jeho aplikací. Patch opraví chybu, ale zpětné vyšetřování za nikoho neudělá.

Samotný exploit není jediná stopa

U nově objevené zranitelnosti často zpočátku chybí přesná detekční signatura. Po úspěšném průniku se však server začne chovat neobvykle – webový server nebo PHP proces spustí shell, objeví se příkazy curl či wget, stáhne se další kód nebo proces naváže neobvyklou odchozí komunikaci.

Na těchto post-exploitačních vzorcích staví část detekčního pokrytí PHP2Shell také platforma Elastic Security, využitelná v rámci MIP Insight. Samotný webový access log ukáže pouze příchozí HTTP požadavek, zatímco detailní endpointová telemetrie odhalí, co se na serveru dělo potom.

Viditelnost v historii je důležitější než značka nástroje

Podobné detekční principy využívají vedle Elasticu i další bezpečnostní platformy od Microsoftu, CrowdStriku, Palo Alto Networks nebo Splunku. Rozhodující pro úspěšné vyšetření není logo v konzoli, ale hloubka viditelnosti a délka uchovávané historie událostí.

Některá data získají svůj skutečný bezpečnostní význam až zpětně.

Pokud máte k dispozici potřebnou telemetrii, můžete se v čase vrátit o několik dní zpět a dohledat chování, které v době vzniku nevypadalo podezřele.

Součinnost MIP Insight a MIP Defend v praxi

Tento scénář zřetelně ilustruje rozdělení rolí v architektuře MIP. Modul MIP Insight řeší viditelnost – logy, observabilitu, SIEM, detekce a hledání souvislostí v historii. Na tento přehled navazuje MIP Defend s aktivní ochranou, EDR, hardeningem a segmentací.

Cílem není hromadit různé bezpečnostní nástroje, ale propojit data, detekce a reakce do jednoho funkčního celku. Místo dotazu „Máme SIEM?“ je proto užitečnější položit si otázku: Kdyby byl některý z našich serverů napaden minulý týden, dokázali bychom to dnes spolehlivě zjistit?

Související čtení

• MIP: jak spojit provoz, přehled, ochranu a obnovu IT – Jak do sebe zapadají MIP Insight, MIP Defend a MIP Shield.

• SIEM a EDR pro výrobní firmy – Proč moderní bezpečnostní provoz potřebuje víc než samotný sběr logů.