Kereszt-platformos vírus - a legfrissebb proof-of-concept

Titkosítás, biztonság, privát szféra

A Kaspersky arról ír, hogy egy vírusmintát kaptak: egy kereszt-platformos vírusét. Az oldal szerint ez a legújabb próbálkozás arra, hogy olyan ártó szándékú kódot hozzanak létre, amely kárt tud okozni Linux és Windows környezetben is. Emiatt a neve is kettős: Virus.Linux.Bi.a / Virus.Win32.Bi.a

A vírust assembly-ben írták, és meglehetősen egyszerű. Csak azokat a file-okat fertőzi meg, amelyek az aktuális könyvtárban vannak. Az ELF és PE formátumú fileokat fertőzi meg (például a felhasználó ~-jában levő, a felhasználó által írható binárisokat). Az ELF file-ok fertőzéséhez INT 80-as rendszerhívást használja. Beinjektálja a saját törzsét a file-ba, közvetlenül az ELF file header-je után a “.text” szekció elé. Windowson a Kernel32.dll-t használja a károkozásra.

Bővebben itt.

Egyesek szerint ez a proof-of-concept annyira nem új "találmány", hiszen 5 évvel ezelőtt is volt már példa hasonló próbálkozásra.

( crown v | 2006. 04. 10., h – 14:08 )

A virus terjedeset neheziti, hogy melle kell csatolni egy 2MB os windows DLL-t a kompatibilitas miatt, es a gepen telepitve kell legyen egy make 3.1.2 verzio, es gcc 3.5.1, tovabba megfelelo iras jogok beallitva a user home konyvtaraban a linux-al valo kompatibilitas miatt. ;)

( rogerius | 2006. 04. 10., h – 14:09 )

Ha assembly-ben van, akkor procifüggő is, igaz? Tehát ha a Linux mondjuk PPC-n megy akkor nem funkcionál. Ugye? (Bocs a lame kérdésért.. :) )

( Som-Som | 2006. 04. 10., h – 15:21 )

Na jó, de hogy jut el hozzám a fertőzés? Valaki küld nekem egy binárist, észre sem veszem, hogy elmentem és aztán véletlenül elindítom?

És akkor mit is fertőz meg? A home-omban lévő lefordított kódokat? Legalább rendszergizda jogokat szerezne...

Ja, de melyik defaultláma rak futtatható binárist a home-jába? Még azt is nyűg lenne nekik elmagyarázni, hogy nem "ize", hanem "~/ize", mert a PATH az már magas. (Na meg hát ugye a setuid root-os bináris meg még ritkább a user home-okban.)
Ez az egész szerintem max. arra jó, hogy lehet majd őrjöngeni, hogy "de a linukszon is vannak vírusok"... Amúgy tudtok valami olyan linuxos virnyáról, ami kártékonyság tekintetében túltesze ezen meg a bizalom-elvű mongol víruson?

gsimon, tőled az eddigiek alapján többet vártam.

"Melyik defaultláma ..."

Pl. az, amelyiknek a disztrója alapból nem tartalmaz java-t, meg flash-plugint, meg mplayert, meg xine-t, meg-meg. Aztán letölti valahonnan (ugye böngészők jelentős része pl. bizonyos pluginhiánynál automatikusan küld a megfelelő (-nek minősített) oldalra, ahonnan máris töltheted le a bináris (sokszor futtatható) formátumú vackot. És máris kész a fertőzés: r=1 user otthoni adsl-en letölti ezt a ketyerét, majd a (z immár fertőzőtt példányt) odaadja r=0,5 haverjának, aki csak modem mögött csücsül - ne kelljen már azt a vackot is letöltenie a lassú drótján.

Amúgy te se látod a "proof-of-concept" részét a dolognak?

Utolsó kérdésedre, kb 6-8 éve a Bugtraq-re küldött egy pofa egy linuxos-vírust, az annyival volt inteligensebb, hogy minden futtathatót megfertőzőtt - ill. asszem futásonként csak 5 v 10 db még nem fertőzöttet -, amit egyáltalán ért (nem csak a $HOME-ban), (root-ként kipróbálva a teljes diszket megfertőzte természetesen), és a FreeBSD linuxemujával is gyönyörűen ment. Az is p-o-c verzió volt, a fertőzőtt pl (ha jól emlékszem) fertőzés után inteligensen jelezte, hogy sikerült fertőznie X darabot. (Szerencse, h a fickó kódoltan küldte a listára - programot kellett írni a dekódoláshoz -, ezzel elég sok lámát ki zárt a fertőzésből.)
Ja, amúgy ha jól emlékszem a Code Red (vagy hogy is hívták, ami Apache-ot fertőzött, és bezárta maga után a kaput) nem volt kicsi (igaz, az féreg, nem vírus a hagyományos osztályozás szerint).

> Pl. az, amelyiknek a disztrója alapból nem tartalmaz java-t, meg
> flash-plugint, meg mplayert

Akkor olyat kell használni, amiben benne van. Nem is lenne rossz, ha végre elválna a Linux szerver és ez a fél-desktop kategória, a fél-desktop disztribekbe meg tessék minden szart belepakolni. A home olyan, mint a "Documents and Settings", egyik alatt sincs semmi helye binárisnak.

Egyébként én örülök ennek a POC kódnak, talán ha lesz egy k.nagy fertőzés, akkor az emberek majd kapcsolnak és nem mondanak többet olyat, hogy "Linuxra vírusirtó, az meg minek?".

---
;-(

> Akkor olyat _kell_ használni, amiben benne van.

Ennyit az egyén korlátlan szabadságvágyáról, ugye? Nem utolsósorban ez nem feltétlenül a disztribúció készítőjén múlik, vannak időnként gyártói hasfájások is. Pl. nem adható tovább. (Bár ha abból indulunk ki, hogy anno tilos volt pl. Secure-RPC-t használó szoftvert kivinni az USA-ból, de azért volt olyan Linux disztrib, amiben benne volt, és itthon is megvásárolható volt - no ahhoz képest egy vacak licence-sértés teljesen korrekt dolog. Vagy valamit félreértek?) Szóval ez mellékszál.

Én user home-okban futtatható binárist eddig csak két esetben láttam:
- valaki C-ben fejlesztett, és ugye ki is próbálta, amit csinált
- egy haver gépére kézzel másoltam fel a w3m-et, mert nem tudtam elérni, hogy ugyan tegye már fel, és sürgős volt a dolog :)

A böngésző-plugin-ek, azok persze vannak, de azért vessünk rájuk egy pillantást:

fules@chaos:~$ ls -lR ~/.opera/plugins/
/var/home/fules/.opera/plugins/:
total 2052
-rwxr-xr-x 1 fules fules 2096844 Oct 4 2005 libflashplayer.so
fules@chaos:~$

Ez nekem inkább tűnik lib-nek, mint önállóan futtatható binárisnak, legalábbis:
fules@chaos:~$ ~/.opera/plugins/libflashplayer.so
Segmentation fault

A letöltött cuccok továbbadását illetően:
fules@chaos:~/archive$ ls -l install_flash_player_7_linux.tar.gz
-rw-r--r-- 1 fules fules 989217 Feb 28 14:50 install_flash_player_7_linux.tar.gz

Szimpla targéza, azon belül pedig csak script, ill. a fenti .so:
fules@chaos:/tmp$ file install_flash_player_7_linux/flashplayer-installer
install_flash_player_7_linux/flashplayer-installer: Bourne shell script text executable

A dzsuvát nézve, megint csak script:
fules@chaos:~/archive$ file j2re-1_4_2_05-linux-i586.bin
j2re-1_4_2_05-linux-i586.bin: Bourne shell script text executable
Van mögötte persze egy ELF futtatható bináris, de azért mielőtt elindulna, van rajta egy ellenőrzőösszeg-vizsgálat is.

Szóval ezek scriptek és ellenőrzött binárisok. Nem pont a vírusvédelem miatt ugyan, de ez itt egy pozitív mellékhatás :).

A nem csak a home-ban fertőző dögöknek meg nem sok esélyt jósolok, legalábbis az én linuxot használó ismerőseim között nincs, aki alapból root-ként használná a gépét, pedig nem is győzködtem őket erről, csak hál'Istennek a telepítők voltak olyanok, hogy így egyszerűbb volt nekik, mint trükközni, hogy mégis csak kizárólag a root legyen.

A binárisokat fertőző cuccokkal meg azt tartom nehézkesnek, hogy folyamatos fejlesztésre kényszeríti őket a fertőzendő binárisok fejlődése. Amíg a usernek csak egy 'apt-get update; apt-get upgrade'-et kell mondania, és újrahúzta az apache-át a legújabbra, addig a féregnek a. újra kell fertőznie, b. be kell tudnia jutni az újabb apache-ra, c. tudnia kell azt is fertőznie.
Szerintem egy linuxos virnya írójának sokkal munkásabb és kudarctelibb élete van, mint Má$ rendszerek esetén, így, amíg a vírustelep bitgettók ki nem halnak teljesen, addig nyugtunk lesz, utána pedig lehet, hogy a vírusaktivitás a mostaninak az 1%-át is elérheti :)...

Ellenben, az erő sötét oldaláról nézve: miért nincsenek script-vírusok :)? Ha a libtool meg tudja csinálni, hogy egy binárist szépen átdob egy '.libs' nevű könyvtárba, a helyére meg tesz egy scriptet, ami teszi a dolgát és majd indítja az eredetit, akkor ezt egy virnya is meg tudná tenni, nem? Egy script-vírus abszolute platformfüggetlen lenne, a file-formátum se igazán érdekelné, akár más scripteket is 'megfertőzhetne', hmmm... Na, távozz tőlem Sátán, _nem_ fogok ilyesmit írni, még ha érdekes kísérlet lenne, akkor sem :) !

Ez nekem inkább tűnik lib-nek, mint önállóan futtatható binárisnak

És libben nem lehet kártékony kód?

Van mögötte persze egy ELF futtatható bináris, de azért mielőtt elindulna, van rajta egy ellenőrzőösszeg-vizsgálat is.

Backdoored binárishoz nem lehet korrekt CRC-t írni?

A nem csak a home-ban fertőző dögöknek meg nem sok esélyt jósolok

Desktop rendszerek tele vannak setuid root binárisokkal (kernel bugokról nem is beszélve), senki sem mondta, hogy okosan megírt vírus nem használhatná ki ezt hogy rootot szerezzen. Ha pedig ezt nem is, de módosíthatná az IRC/Chat/levelező/akármi klienst, hogy sokszorosítsa és küldje tovább magát minél több potenciális áldozatnak (egy időben a mirc script wormok is remekül terjedtek, ezt pedig Linux alatt is el lehet követni korlátozott felhasználóként is.)

Amíg a usernek csak egy 'apt-get update; apt-get upgrade'-et kell mondania, és újrahúzta az apache-át a legújabbra, addig a féregnek a. újra kell fertőznie, b. be kell tudnia jutni az újabb apache-ra, c. tudnia kell azt is fertőznie.

Nehéz lesz újrafertőznie az apacheot, hogy ha minden más bináris továbbra is fertőzőtt a rendszeren, amely nem lett frissítve/lecserélve...

miért nincsenek script-vírusok :)?

Vannak, persze elterjedve nem Linuxon amelyet a számítógép felhasználók 1-2%-a használ maximum. Ez egyúttal megmagyarázza azt is, hogy miért nem csinál senki sem és nem azért, mert nehéz vagy lehetetlen lenne.

Tessék out-of-box gondolkodni.

"És libben nem lehet kártékony kód?"
Lehet, de most olyasmiről volt szó, ami futtatható binárisokat fertőz.

"Backdoored binárishoz nem lehet korrekt CRC-t írni?"
Lehet, ha maga a virnya direkte egy az egyben a java telepítőt akarja elkapni, amiről pontosan tudja, hogy hányadik sortól kezdődik az elf bináris és a scriptben hol van az ellenőrzőösszeg, amit át kell írnia, viszont itt nem ilyesmiről volt szó.

"Desktop rendszerek tele vannak setuid root binárisokkal (kernel bugokról nem is beszélve), senki sem mondta, hogy okosan megírt vírus nem használhatná ki ezt hogy rootot szerezzen"
Természetesen, csak épp itt most nem egy ilyen vírusról volt szó.

"hogy rootot szerezzen. Ha pedig ezt nem is, de módosíthatná az IRC/Chat/levelező/akármi klienst"
Ha nem szerez root jogot, hogyan módosítja? Nem mintha az itt említett virnya a leírás alapján csinálna ilyet, de azért érdekelne.

"Nehéz lesz újrafertőznie az apacheot, hogy ha minden más bináris továbbra is fertőzőtt a rendszeren, amely nem lett frissítve/lecserélve"
Nálam az apache www-data joggal fut, az alap-telepítésben úgyszintén, a www-data-nak pedig nincs írási joga a /bin, /sbin, /usr/bin, stb.-re, azaz attól, hogy az apache-ot elkapta, mást még nem kapott el. Ha netán te olyan disztribet használsz, ahol root-ként fut az apache, akkor szerintem válts minél hamarabb :)...

"amelyet a számítógép felhasználók 1-2%-a használ maximum. Ez egyúttal megmagyarázza azt is, hogy miért nem csinál senki sem"
Az előbb olvastál két példát, azaz próbálnak csinálni virnyákat. Hamis állítás bármiből implikálható, azaz a linux elterjedtségéről szóló rész igazságtartalma formálisan nem eldönthető :).

"Tessék out-of-box gondolkodni."
Tessék kissé a konkrét témától a feltételes móddal dúsan átszőtt hipotézisekig haladó vonalnak inkább az innenső oldalát előnyben részesíteni :). (Természetesen lehetNÉnek lib-eket fertőző vírusok, backdoor-os kódhoz is lehetNE crc-t hamisítani, a suid root-ot is kihasználhatNÁK a virnyák, ha az apache root-ként futNA, mást is veszélyeztetNE. Ha a disznóknak szárnya lenNE, akkor repülhetNÉnek.)

Szerintem hibás az alapálláspontod. Tele van a világ Win-vírussal, amik működnek. Van egy (vagy több) Linuxra megírt jószág, ahol a fejlesztő a POC kifejezéssel azt jelzi, hogy a dolog működőképességének dokumentálása céljából írta a dögöt (azaz az általános vélekedéssel szemben lehet Linuxra-egyáltalán/Linuxon-Windowson-egyaránt-működő vírust írni). Te meg azt fejtegeted, hogy de miért is nem fertőz rendesen, meg miért nem terjed rendesen.

Azért mert nehezebb a fertőzés a helyi gépen (nem olyan belterjes a Lin világ, mint a Win)

Mert nehezebb a terjedés (kevesebb van, az se 1/2/3-féle)

Általában jobban be van állítva a jogosultsági rendszere

Meg azért, mert kevésbé elterjedt rendszerről lévén szó, nem lehet akkora "arc"-hoz jutni általa

És nyilván van millió oka. De nem az, mert Linuxra nem _lehet_.

(Amúgy az IRC klienset - a bináridt - nem kell megfertőzni, bőven elég a felhasználó konfigurációs-fájlját piszkálni pl. olyasmihez, hogy küldözgesse magát ótomatában.)

Szerintem akkor elmentünk egymás mellett: Természetesen nem akartam cáfolni, hogy linuxra _lehet_ vírust írni.
Pusztán annyit akaram mondani, hogy (amúgy nagyjából az általad sorolt okokból) egy ilyen vírus nagyságrendileg kevesebb kárt tud okozni, mint egyéb rendszereken. Vírusos hascsikarás lehetséges, fekete lepra már nem.
(Amúgy az IRC-t illetően a magánvéleményem, hogy az már maga egy számítógépes vírus, csak nem a gépet támadja, hanem a felhasználót :)... Végülis a user se csinál mást hosszú órákon át, mint forgalmaz a hálón, másokat 'fertőzve' meg ezzel :), sávszélességet és gépteljesítményt foglalva, hmm?)

Lehet, de most olyasmiről volt szó, ami futtatható binárisokat fertőz.

A példa arra irányult, hogy a user letölthet olyan binárist, amely a kártékony kódot tartalmazza. (flash-plugin)

Lehet, ha maga a virnya direkte egy az egyben a java telepítőt akarja elkapni, amiről pontosan tudja, hogy hányadik sortól kezdődik az elf bináris és a scriptben hol van az ellenőrzőösszeg, amit át kell írnia, viszont itt nem ilyesmiről volt szó.

A mondatomban szerepelt a _backdoored_ szó és szinten egy példára utalt, hogy a user letölthet olyan binárist/filet/telepítőt, amely veszélyeztetheti a rendszere biztonságát.

Ha nem szerez root jogot, hogyan módosítja?

root jog nélkül is illeszthető script egy IRC/Chat kliensekhez, amely megvalósít egy továbbterjedést (lásd mirc script példa windowson) és root jog nélkül is illeszthetők mindenféle pluginek a levelező kliensekhez, amely szintén egy vírus/worm továbbküldését végezheti. A ptrace és egyéb megoldásokkal kivitelezhető futó programokba való kód injektálásos trükkökről meg nem is beszélve, de hagy ne adjak már ötleteket... ;)

Nem mintha az itt említett virnya a leírás alapján csinálna ilyet, de azért érdekelne.

Ne legyél már ennyire földhöz ragadt. Szakadjunk el az aktuális vírustól. Ez egy Proof-of-concept, mint írta Zahy is. Nem tartalmaz valódi veszélyt, csak bizonyíték arra, hogy lehet kerszt-platformos vírust írni (amely persze eddig sem volt kérdéses).

Nálam az apache www-data joggal fut, az alap-telepítésben úgyszintén, a www-data-nak pedig nincs írási joga a /bin, /sbin, /usr/bin, stb.-re, azaz attól, hogy az apache-ot elkapta, mást még nem kapott el.

Lásd. suid programok, kernel bugok kihasználása részt az előző posztomban. Másrészről nem feltétlenűl az apacheon keresztűl fertőződhetett meg az apache binárisa, ugye?

Az előbb olvastál két példát, azaz próbálnak csinálni virnyákat. Hamis állítás bármiből implikálható, azaz a linux elterjedtségéről szóló rész igazságtartalma formálisan nem eldönthető :).

Próbálnak csinálni _bizonyítékot_ arra, hogy lehet készíteni olyan vírust, amely több platformon is életképes. Proof-of-concept, nem tudom hányszor kell hangsúlyozni.

Tessék kissé a konkrét témától a feltételes móddal dúsan átszőtt hipotézisekig haladó vonalnak inkább az innenső oldalát előnyben részesíteni :). (Természetesen lehetNÉnek lib-eket fertőző vírusok, backdoor-os kódhoz is lehetNE crc-t hamisítani, a suid root-ot is kihasználhatNÁK a virnyák, ha az apache root-ként futNA, mást is veszélyeztetNE. Ha a disznóknak szárnya lenNE, akkor repülhetNÉnek.)

Az egész cikk egy feltételezésen alapul. LeHETséges kereszt-platformos vírust írni. Most lehet meg fog lepni, de proof-of-concept vírusok még Windows platformokon se terjedtek el soha, így nyilván nem az aktuális hír eredményeire kellene alapozni, ha az ember távlatokban akar gondolkozni.

De hogy megfordítsam a dolgot... Attól, hogy jelenleg nincs végleges gyógyulást biztosító gyógymód az allergiás betegségekre, még nem jelenti azt, hogy soha nem is lesz. A tudományos eredmények nem a 100%-os megoldásokat mutatják be, hanem a lehetőségeket.

Nekem nem kerülte el, de fogalmam sincs, hogy mit is jelent.
Mellesleg sok hülye felhasználó (pl. én is) akinek gyakran adódik root jogokat igénylő tennivalója, felrak egy sudo-t és beállítja a nopasswd:all-t. Ha a vírusban egy egészen kevés intelligencia van és megpróbálja a sudo-t egy így beállított rendszeren...
(tény: a fontos szervereken mindig kihagyom a NOPASSWD-t, de mondjuk a saját nyamvadt kis desktopomon minek? :) )
Persze itt már lehetne cifrázni a dolgot: pl. ro mountolni a /usr-t és alkatrészeit, így máris kisebb a fertőzés esélye, de ez talán már a paranoia kategória - nomeg ha root jogot szerzett a kártevő, akkor már mindegy is. Vagy nem?

---------------------------------------------------
Fel! Támadunk!

Nekem nem kerülte el, de fogalmam sincs, hogy mit is jelent.
Mármint a proof-of-concept? Kb. hogy egy elgondolás bizonyítása, azaz jelen esetben (elvileg) nem egy tényleges kártevő, hanem csak egy kisérleti (prototípus). Ez persze nem azt jelenti, hogy nem képes kárt okozni, de (mondom elvileg) nem azért hozták létre és ebből kifolyólag kissé "nyers" és sokszor bénán működik.
Persze itt már lehetne cifrázni a dolgot: pl. ro mountolni a /usr-t és alkatrészeit, így máris kisebb a fertőzés esélye, de ez talán már a paranoia kategória - nomeg ha root jogot szerzett a kártevő, akkor már mindegy is. Vagy nem?
Nem feltétlenül szvsz. Ha egy szkript vagy egy egyszerű program (vírus stb) akar kárt tenni, nem biztos, hogy arra is "gondol", hogy előtte újra csatolja a ro fájlrendszert. Egy kiszolgálón pl. az /usr -ben nem változnak olyan gyakran a binárisok, hogy ez kényelmetlenséget okozzon. Ezzel szemben egy desktop gépen viszont lehet. Ezen felül ha lehet akkor a /home /tmp /var/tmp partíciókat is célszerű lehet noexec -ként mountolni, ui. ide írhatnak a felhasználók, ill. a nem rendszergazda jogú processzek is.

Ilyenkor egy kicsit nagyon magam alatt tudok lenni...
Csupa olyan dolog, ami pár éve még szinte természetes volt, pedig csak egy-két saját gépemen volt linux.
Aztán ráuntam, pár év kihagyás és tessék... mindent elfelejtettem.
A /tmp és a noexec... némely rendszereken nem kerülnek ide önkicsomagoló állományok egy-egy csomag telepítésekor?
---------------------------------------------------
Fel! Támadunk!

A fajlrendszer minden reszere celszeru noexecet rakni, ahova a felhasznalok irhatnak. Es a /tmp ilyen meg a /home (persze) es a /var/tmp (hacsak nem egy symlink a /tmp-re vagy viszont). Abban az esetben is, ha ez a noexec kijatszhato (mint ahogy snq- jelezte egy kesobbi postban). Mivel a telepito szkriptek (pl. preinst, postinst stb) innen futnak (deb alapu rendszerek alatt mindenkepp) ezert frissiteskor remount exec szukseges.

Es a /tmp ilyen meg a /home (persze) es a /var/tmp (hacsak nem egy symlink a /tmp-re vagy viszont).

És a /var/lock vagy akár a /dev/shm könyvtárakkal mi a helyzet? ;)

Abban az esetben is, ha ez a noexec kijatszhato (mint ahogy snq- jelezte egy kesobbi postban). Mivel a telepito szkriptek (pl. preinst, postinst stb) innen futnak (deb alapu rendszerek alatt mindenkepp) ezert frissiteskor remount exec szukseges.

Magyarul inkább önszopatásra jó csak, védelmi szerepet nem igazán tölt be... :)

"ro-mountolni a /usr-t"
És még pár egyebet is nyugodtan, mondjuk a /var, a /home és a /tmp kivételével mindent, ext2/3 esetén nyugodtan felrámolni az immutable flag-et is, a /var-t és a /tmp-t ráadásul noexec-re mountolni.
Mondjuk érdemes scriptet csinálni az rw-re mountolásra/immutable leszedésére ill. visszafelé, különben elég fáradságos dolog befrissíteni a rendszert :)...

sudo és NOPASSWD? all-ra semmiképp. Egy hétig hagyd így, aztán nézd meg, hogy mit is használsz vele, aztán szűkítsd le csak arra. Szerintem a shutdown, apt-get, tcpdump-on kívül nem sok minden lesz.