Vlákno názorů ke zprávičce Bashware: nový útok využívá Windows Subsystem for Linux od ventYl - Toto myslim celkom krasne ukazuje fakticku bezzubost konceptu...

Toto myslim celkom krasne ukazuje fakticku bezzubost konceptu antivirusu ohladom nejakej serioznej a predikovatelnej bezpecnosti. Cely koncept platania deraveho API OS v ktorom uz od bodu nula chyba akykolvek naznak bezpecnosti antivirusmi riesi problem na nespravnom konci. Bohuzial je nemozne problem opravit na spravnom konci (WINAPI) bez rozbitia prakticky kazdeho uplne netrivialneho kusu kodu. Cely koncept toho systemu je z bezpecnostneho hladiska proste zly. A nejde to opravit. Co je komu platne bezpecnostne riesenie, ktore je (a vzdy principialne bude) minimalne jeden krok za utocnikmi a prave utocnici su ti, ktori udavaju tempo?

Cely trik ktory sa tu pouzil je v tom, ze heuristika antivirusov sa v prvom rade vesa na rozhranie aplikacii a systemovych kniznic. To API je pomerne nizkourovnove a primitivne a nema az tak velmi daleko od toho ako boli implementovane prerusenia v MS-DOSe. S cim nikto neratal je to, ze ak sa v tom spusti vrstva kompatibility s Linuxovymi syscallmi tak v nej pojde spustit wine ako vrstva kompatibility s WINAPI volaniam. Kedze WSL nemapuje proces Linuxoveho subsystemu na Widli proces tak antiviraky nemaju sajnu o tom, ze nejaky proces vznikol. A keby aj mali, tak fakt, ze nejaka potencialne skodliva cinnost je vykonavana bude celkom efektivne maskovana overheadom wine nad WSL a overheadom WSL nad jadrom OS.

> Toto myslim celkom krasne ukazuje fakticku bezzubost konceptu antivirusu ohladom nejakej serioznej a predikovatelnej bezpecnosti. Cely koncept platania deraveho API OS v ktorom uz od bodu nula chyba akykolvek naznak bezpecnosti antivirusmi riesi problem na nespravnom konci. Bohuzial je nemozne problem opravit na spravnom konci (WINAPI) bez rozbitia prakticky kazdeho uplne netrivialneho kusu kodu. Cely koncept toho systemu je z bezpecnostneho hladiska proste zly. A nejde to opravit. Co je komu platne bezpecnostne riesenie, ktore je (a vzdy principialne bude) minimalne jeden krok za utocnikmi a prave utocnici su ti, ktori udavaju tempo?

Tak, bezpečnostní model tam je už dávno, ale holt si uživatelé zvykli jeho služeb pokud možno nevyužívat (protože na jejich oblíbených WIndows 9x nebyl přítomen).

> Cely trik ktory sa tu pouzil je v tom, ze heuristika antivirusov sa v prvom rade vesa na rozhranie aplikacii a systemovych kniznic.

Pokud myslíte modifikace knihoven v paměti procesu za účelem jeho monitorování, tak dobré bezpečnostní řešení se buď tak nechová, nebo se jedná jen o jakousi první úroveň bezpečnosti, protože každá aplikace může takové knihovny obejít o své vlastní vůli skrz přímé systémové volání. Hlavní úroveň monitorování (v zásadě on-access) je třeba udělat v jádře.

S těmi pico procesy ale máte pravdu, i když už by snad měly být i viditelné operace, které provádějí se soubory. Ale dlouho tam byl problém v tom, že některá rozhraní používaná pro monitorování/blo­kování se na ně prostě nevztahovala. Nevím, jaká je v tomto ohledu aktuální stiuace.

Z jiného zdroje jsem měl pocit ale, že hlavní problém je, že antiviry neumějí pracovat s ELFy.

> Tak, bezpečnostní model tam je už dávno, ale holt si uživatelé zvykli jeho služeb pokud možno nevyužívat (protože na jejich oblíbených WIndows 9x nebyl přítomen).

To sa bavime o sedeni pod non-admin pouzivatelom? To za relevantny bezpecnostny model nie velmi povazujem. Bol by som ochotny nazor zmenit v pripade, ze by vyuzivanie non-admin konta zamedzilo vsetkym hrozbam malware okrem pripadov, kedy sa jednoznacne jedna o bug v OS (nedokumentovane chovanie alebo chovanie v rozpore s dokumentaciou). Obaja ale vieme, ze toto riesenie je len ciastocne a principialne ani nemoze byt 100% uspesne.

> Pokud myslíte modifikace knihoven v paměti procesu za účelem jeho monitorování,
Mam na mysli akekolvek riesenie na urovni userspace. Ci uz je to IAT hooking, alebo prepisovanie kniznic priamo v pamati procesu (teraz narychlo neviem najst ako sa Microsoftne riesenie na prepisovanie za letu vola). Samozrejme si ziadne solidne AV riesenie cisto s tymto nevystaci, ale bezne sa to pouziva, pretoze to dava sancu heuristike zistit vysokourovnovu semantiku chovania aplikacie. Je zjavne ze ani monitorovanie na pomedzi kernelu tu nepomohlo, pretoze bud WSL pouziva iny entry point do kernelu, nez je chraneny antivirmi, alebo heuristika nie je schopna v scheme, ktorou pristupuje WSL k nativnemu kernelu rozpoznat ziadne divne chovanie.

> Ale dlouho tam byl problém v tom, že některá rozhraní používaná pro monitorování/blo­kování se na ně prostě nevztahovala.
Presne v tomto (a hlavne v tomto) je jadro problemu. Bezpecnost Windowsu je postavena na tom, ze k systemu je prilepene rozhranie, ktore umoznuje *dodatocne* blokovat potencialne nebezpecne chovanie. Cela bezpecnost systemu je potom funkciou schopnosti implementacie blokovania takeho chovania toto chovanie ako nebezpecne rozpoznat. Neviem, ci to ludia, ktori tomuto oponuju nevidia, alebo nechcu vidiet.

Ak system uplne legitimne dovoluje spravit take invazivne akcie, ako zapis do pamate ineho procesu alebo dokonca spustenie syscallu / threadu v kontexte ineho procesu, tak z absolutneho principu veci nemoze byt o bezpecnosti ani slovo. To samo o sebe by nebolo zle, keby tento fundamentalny mechanizmus nebol tak siroko aplikovany (co znemoznuje jeho odstranenie). To, ze v systeme potom existuje obmedzenie, ktore nedovoli injectovat pamat alebo instrukcie do kritickych procesov je potom uz len chaba naplast.

Nechutnym sideefektom potom je, ze celkovy pristup k bezpecnosti je taky, ze sa problemy riesia na mieste, kde sa vektor spusta namiesto toho aby sa riesili na mieste, kde vektor utoku ucinkuje. To potom rozbija veci, nici spatnu kompatibilitu a celkovo posobi tak trocha dost WTF.

> To sa bavime o sedeni pod non-admin pouzivatelom? To za relevantny bezpecnostny model nie velmi povazujem. Bol by som ochotny nazor zmenit v pripade, ze by vyuzivanie non-admin konta zamedzilo vsetkym hrozbam malware okrem pripadov, kedy sa jednoznacne jedna o bug v OS (nedokumentovane chovanie alebo chovanie v rozpore s dokumentaciou). Obaja ale vieme, ze toto riesenie je len ciastocne a principialne ani nemoze byt 100% uspesne.

Malware nutně nepotřebuje administrátorská práva k tomu, aby přežil. Ač se třeba pak nedokáže rozšířit mimo profil daného uživatele (pokud si ten dává pozor). Bezpečnostní model tady zajistí (vyjma chyby OS), že se malware k věcem dostupným pouze administrátorům nedostane. Což ale není nutně potřeba.

Tady by mě zajímalo, co za bezpečnostní model považujete.

> Mam na mysli akekolvek riesenie na urovni userspace

Takové řešení možná pomůže v případě heuristiky založené na spuštění podezřelého souboru ve virtuálním stroji řízeném antivirem, ale jinak je to prostě bezpečnostně špatně, protože to malware může obejít, nebo dané hooky (ať už je to IAT hooking, inline hooking psaný manuálně nebo přes onu Microsoftí Detours knihovnu).

> Presne v tomto (a hlavne v tomto) je jadro problemu. Bezpecnost Windowsu je postavena na tom, ze k systemu je prilepene rozhranie, ktore umoznuje *dodatocne* blokovat potencialne nebezpecne chovanie.

Daná rozhraní dovolují blokovat před provedením dané akce (zápis do FS/registru, komunikace po síti, přístup k cizímu vláknu/procesu/des­ktopu), takže bych to neoznačoval za "dodatečné blokování". Jistě, pokud jej považujete za dodatečné proto, že heuristika nebezpeční neidentifikuje a dovolí vám daný soubor spustit, tak máte pravdu, ale z definice heuristiky s tím nic moc neuděláte.

AFAIK problém WSL nebyl/není v tom, že by používalo jiný entriÿ-point do jádra. I proto, že modifikace tabulky systémových volání, tak oblíbená u AV autorů, je na 64bitových verzích zakázána (a je to podle mě dobře, neb ji AV často implementovali špatně). Kernelová rozhraní pro sledování FS/registru/sítě... jsou níže (kdy už např. obvykle nemáte problém v tom, že se vám vstupní data mohou měnit pod rukama, což je případ modifikace tabulkysystémových volání). Problém spočíval v tom, že u pico procesů (WSL) nebyl správně reportován jejich kontext, což dost znemožňovalo monitorování z kernelu. Ale tyhle moje informace jsou poměrně staré (tak rok-dva). Rozhodně se ale nejedná o něco nového, na co ti výzkumníci přišli... prostě asi jen vyzkoušeli, že to funguje (nebo si poslechli povídání Alexe Ionescu o WSL).

> Ak system uplne legitimne dovoluje spravit take invazivne akcie, ako zapis do pamate ineho procesu

Než takové akce můžete udělat, musíte k danému procesu/vláknu získat požadovaný přístup. Pokud neběžíte s právy administrátora a daný proces běží pod jiným uživatelem, může si změnou ACL na svém objektu a na objektu svých vláken (popř. už při jejich vytváření) tak, abyste mu do paměti lézt nemohl (podobně s jeho vlákny). I pokud běží pod stejným uživatelem (i když je tento uživatel uvedený jako vlastník), může mu zamezit přístup, ale tady už ubde záležet, co daný proces přesněji provádí. Navíc mají AV možnost tyto přístupy k cizím vlánkům/procesům filtrovat (ne úplně tvrdě, ale pokusy o přístup se zápisovými oprávněními ano).

S GUI je tady trochu problém, jelikož se s ním do bezpečnostního modelu asi dříve moc nepočítalo.

> To, ze v systeme potom existuje obmedzenie, ktore nedovoli injectovat pamat alebo instrukcie do kritickych procesov je potom uz len chaba naplast.

Tuhle věc si zřejmě původně vydupal Velký obsah kvůli DRM (Windows Vista). Pro účely systému se šířeji začala používat až o dost později (WIndows 8+). Navíc už lze tuto feature využít i pro významené procesy třetích stran (síla ochrany dle síly certifikátu).

> Jistě, pokud jej považujete za dodatečné proto, že heuristika nebezpeční neidentifikuje a dovolí vám daný soubor spustit, tak máte pravdu.
Ano, povazujem ho za dodatocne nie v zmysle, ze akcia je zakazana ex-post (to je tazko technicky implementovatelne), ale preto, ze potencialne nebezpecne akcie nie su zakazane jaksi implicitne, ale dodatocna heuristika zistuje, co je bezpecne a co nie. Proste to nie je nadesignovane ako bezpecne, ale bezpecnost je tam dolepena.

> Problém spočíval v tom, že u pico procesů (WSL) nebyl správně reportován jejich kontext, což dost znemožňovalo monitorování z kernelu.
Takze defakto je bezpecnostny model postaveny na tom, ze nejake obmedzenie sa snad vynuti, pokial mame to stastie a kontext operacie nam bude spravne nareportovany. To mi pride dost chabe (ale podla mojich skusenosti s korporatnym vyvojom uplne ok). A prelomenie tej ochrany je potom zavisle od toho, komu sa podari najst scenar pri ktorom sa obmedzenia nevynucuju.