Předně, omluva za off-topic.
Pro výrobce 3rd-party firewallů a jiných síťových vychytávek (např. libPCAP, MS virtual WiFi) pod Windows existuje doporučený zdvořilý způsob, jak si do systému zavěsit "fitrující mezivrstvu" do síťového stacku. Našel jsem pro to názvy "NDIS filter driver" nebo "NDIS intermediate driver" - netuším, zda se jedná o synonyma, nebo dvě různé evoluční varianty, nebo úplně jiné věci. (V případě Windows Vista se bavíme o ovladačích dle standardu NDIS 6.)
NDIS intermediate (Protocol) driver a (lightweight) NDIS filter driver se AFAIK liší v tom, že u tohot druhého máte daleko méně práce s programováním, protože Microsoft potřebný obecný kód udělal za vás (proto lightweight).
I pídil jsem se po možnosti, jak vypsat nainstalované takové drivery. Našel jsem zmínky o "fltmc" (standardní součást Win7+, nevím jak Vista) ale ten zřejmě vypisuje jenom filter drivery ve storage subsystému (v oblasti souborových systémů). Nějaké síťové filter drivery jsou vidět ve "vlastnostech adaptéru" (GUI) - netuším zda striktně všechny, nebo třeba jenom moderní a slušně vychované... analogicky podle situace v oblasti driverů obecně, kde staré "NTDM" drivery často nemají ikonku v device manageru, a modernější slušně vychované WDM/WDK drivery obvykle ano.
Filtry souborového systému fungují jiným způsobem než NDIS filtry, není tu žádná společná báze. Device Manager vám zobrazí v zásadě ovladače obsluhující fyzický či virtuální hardware, popř. v něm dohledáte jejich filtry (ač to dá dost práce). To platí ale o typech zařízení, která se filtrují standardním způsobem ("zavěšení" nad zařízení, které chtějí filtrovat), "moderní" FS filtry a NDIS filtry fungují jinak (zřejmě kvůli výkonu). Koneckonců, plug&play ovladače, kterých je drtivá většina, se v paměti vyskytují právě v případě, že je jich zapotřebí.
Taky jsem zkoušel hledat v regeditu, a našel jsem u konkrétního síťového adaptéru větev Linkage a v ní položku FilterList, což je textový seznam odkazů na jakési GUIDy... které jsem dohledal někam do podvětví HKLM\SYSTEM\CurrentControlSet\Control\Network\{4d36e974-e325-11ce-bfc1-08002be10318}. Všude samé GUIDy. Nemám rád GUIDy. Zkoušel jsem brouzdat nápovědou netsh a netcfg, jestli by nebyl lidský seznam, ale kde nic tu nic.
Ano, čekal bych něco takového. GUID je velmi oblíbený druh indexu (je dostatečně dlouhý, aby byl jedinečný).
Všimněte si, že Microsoftí vlastní firewall v seznamu "filter driverů" nenajdete. Někdo tady káže vodu a pije víno :-) Bodejť ne, když si především sami napsali celý NDIS framework - zdvořile se zavádět a standardně se představit musí všichni *ostatní* :-) Tj. všichni ostatní zdvořilí.
Protože Windows Firewall není implementovaný prostřednictvím filtru NDIS, ale je to Callout driver používající rozhraní Windows Filtering Platform. Z toho také vyplývalo, že pracuje nejníže na IP vrstvě (WFP už umí filtrovat i linkovou, je to novinka cca od Windows 8/8.1, ale nevím, zda to do firewallu zarhnuli). Ovladače spojené s NDIS se dostávají do akce až pod firewallem.
Zdvořilý malware je hloupý a trapný. Skutečný malware bydlí v kernelu a háčkuje kernel API. Klasika jsou kejkle s tabulkou procesů, ale i pro nás by se určitě našla nějaká tabulka symbolů v síťovém stacku nebo nějaká příhodná tabulka NDIS callbacků apod.
Taková tabulka by se určitě našla. Otázka je, jak moc je hlídána proti těmto změnám technologií KPP (Patchguard). Nějaké šachování se spojovým seznamem procesů (ne, není to tabulka, tabulka tu je jen jako mapovátko jejich čísel na jejich datové struktury) či "háčkování API" se v dnešní době moc praktikovat nedá, protože naopak vede k nestabilitě sytému (KPP v případě nalezené modifikace vyvolá BSOD). Samozřejmě, je to o tom najít datovou strukturu, která (zatím) hlídána není.
Čili trochu šikovný malware je na úrovni MS firewallu, může se snažit ho vyšachovat apod. V seznamu zdvořilých NDIS driverů potažmo šikovný malware není vidět. Jakmile jednou dostanete svůj driver do kernelu, můžete téměř všecko.
Ano, jakmile jste v jádře, bezpečnostní pravidla pro vás neplatí, protože jste prostě důvěryhodný. A vzhledem ke sdílení adresového prostoru s ostatními ovladači se nikoho na nic ptát nemusíte. Pro vstup do kernelu je ale potřeba podpis důvěryhodným certifikátem, což, jak se mi zatím jeví, je pro autory malware stále dost problém (rozhodně to není běžná praxe).
Další možný "vektor útoku" je tradičně v user space - tradičně výměnou/zaháčkováním winsock2.dll (nebo jak se ta knihovna dneska jmenuje). Jakákoli user-space aplikace, která jede přes sockety (včetně raw socketů? včetně ICMP utilit?) musí skrz winsock.dll. Pokud hijacknete winsock.dll, držíte v hrsti prakticky všechny síťoviny v user space, a nemusel jste ani prosadit svůj driver do kernelu. V cestě Vám stálo "jenom" user-space UAC. Existují legitimní softwarové balíky, které tohle dělají - tradičně socks proxy. Obecně háčkovat DLL (prakticky celé WinAPI) umí třeba APImonitor. Logicky malware útočící na winsock.dll toto nebude nikde roztrubovat. Navíc v případě háčkování winsock.dll ani nevím o možnosti, jak toto udělat "zdvořile" = podle mého admin ani nemá kam se podívat po nějakém seznamu zavěšených procesů/knihoven třetích stran.
Ano, toto se dá. Pokud se ale jedná o úpravu DLL na disku (ne v paměti aplikací, které chceme přesměrovávat), lze na to přijít pravidelnou kontrolou integrity (tyhle systémové DLLky bývají digitálně podepsané Microsoftem).
Správě byste samozřejmě měl pracovat pod opravdovým účtem s omezenými právy (pak je pro projití UAC třeba heslo a nefungují ani běžné triky, pokud vynecháme bugy). Ale z historických důvodů to nepatří k běžné domácí praxi.
91 Odpovědí
23598 Zhlédnutí