Kártékony PNG képek jöhetnek

2014. február 05. 10:50 - Csizmazia Darab István [Rambo]

Biztonsági kutatók figyeltek fel arra a módszerre, melynél kártékony PNG fájlok böngészőben való betöltésekor egy trükkös iFrames beszúrással lehetett észrevétlenül átirányítani a weboldalak látogatóit tetszőleges rosszindulatú linkekre.

Az iFrame betöltése után megjelenik egy elsőre ártalmatlan jquery.js is, ám később a LoadFile() függvény használata során egy ciklusban kódolódik ki a PNG képbe ágyazott URL, amelyre aztán a böngésző a rejtett átirányítást végzi. A Sucuri szakemberei szerint máris észlelhetőek ilyen valós támadások, vagyis a kártevő megjelent az In the Wild világában. A dolog teljesen észrevehetetlen egy hétköznapi felhasználónak, hiszen a kép akár képernyőn kívüli negatív pozícióban is lehet láthatatlanul, nekünk a későbbiekben viszont majd a "createElement"-ekre lesz érdemes jobban odafigyelni.

Azt is hozzáteszik, hogy nem kizárólag a PNG fájlformátum sebezhető ezzel a módszerrel, hanem akár egyéb más grafikus állomány típusok is. Az is elképzelhető, hogy hamarosan tömegesen jelennek meg a trükköt alkalmazó drive-by-download támadások, és ellephetik majd a Google keresőtalálatokat is az ilyen jellegű SEP mérgezések, hiszen láthatóan nem kell gigantikus erőfeszítés az ilyen rejtett linkes trükkhöz.

A részletes bejegyezést az incidensről és a támadás elemzéséről itt lehet olvasni: http://blog.sucuri.net/2014/02/new-iframe-injections-leverage-png-image-metadata.html

13 komment
Címkék: malware iframe png sucuri drive-by-download createelement

Ajánlott bejegyzések:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Tomi1977 2014.02.05. 21:01:56

Van erre védekezési lehetőség? Elég ijesztően hangzik.
Válasz erre 

titan 2014.02.06. 12:18:31

... szóval a javascript segítségével lehet dekódolni elkódolt url-eket, és a böngészőt átirányítani... zseniális felfedezés... Kb. mint a másik "képben vírus" ijesztgetés, ahhoz is már meg kellett, hogy fertőzve legyen a gép eleve, hogy működjön. Ha meg eleve fertőzött a gép, nem kell külön kép ahhoz, hogy további fertőzéseket össze tudjon szedni, legfeljebb álcázni lehet ezzel a módszerrel az információ forrását.
Válasz erre 

ElPadre 2014.02.06. 14:51:55

elképesztően szarul van lefordítva a cikk, de a lényeg:
1. a PNG (és egyéb) képformátumokban lehet egyéb szöveges tag, a kép részeként (pl. copyright info, stb).
2. ebbe rakják bele az injektor javascriptet.
3. a kód csinál egy canvast, rárakja a képet, és innentől be tudja olvasni byte-onként a képet.
4. a script kiolvassa a spéci szöveges tag-et, ami már egy legit malware iframe injenction javascript kód, és végre is hajtja.
5. a trükk: a legtöbb web-pajzs csak a közvetlen scriptet figyeli, nem pedig egy így összeállított scriptet, ami egy PNG file tag-jéből jön... így cselezik ki a web-pajzsot. ennyi.
Válasz erre 

nemjogasz 2014.02.06. 15:37:13

Be szép idők is voltak, amikor a weboldalak még csak sima html-ek voltak, és a böngészők is csak azokat értelmezték... Semmi aktív tartalom, semmi scriptelés, semmi bővítmény... Bezzeg a régi időkben... *Nagypapi mód kikapcs*
De egyébként tényleg az esetek 90%-ban szerintem semmi szükség nem lenne sima htmlen meg cssen kívül semmire.
Válasz erre 

Savior 2014.02.06. 16:44:03

@nemjogasz: ezért is használok NoScriptet. Sajnos egyre kevesebb az olyan weboldal, amit lehet így is nézni, ráadásul lassan már minden 6 másik site-ról szedi a JS-eit, és ki tudja, azok közül mi kell éppen neki. Eh.
Válasz erre 

qwertzu 2014.02.06. 18:01:41

@ElPadre: Így már érthetőbb.

"2. ebbe rakják bele az injektor javascriptet."
Na ez nem világos. Mi a francért futtat a böngésző egy ilyen talált scriptet?
Válasz erre 

ElPadre 2014.02.06. 20:29:06

@qwertzu: mert a böngésző futtatja a javascriptet, a javascriptben meg van eval. hát ezért.
Válasz erre 

Csizmazia Darab István [Rambo] · http://antivirus.blog.hu 2014.02.07. 06:32:49

@Tomi1977: Kéne vele játszani kicsit, de így elsőre azt mondom, ha még a link generáláskor esetleg nem is, de a kapcsolódáskor az AV meg a NoScript már meg tudja fogni.
Válasz erre 

titan 2014.02.07. 10:00:13

@ElPadre: és akkor itt a lényeg, hogy első körben el kell induljon a valódi kártékony kód (egy javascript), és csak utána lehetséges a png-ben bármilyen kód futtatása. Obfuszkált kódot pedig majdnem bármilyen file-formátumban el lehet helyezni. főleg ha a megjelenített tartalom nem számít, mert - ahogy itt fentebb írták - böngészési területen kívülre pozicionálják. Azaz a leírás minimum tévesen fogalmaz, felnagyítva az eredeti problémát avagy kiragadva egy részletét a nagyobb problémának.
Válasz erre 

ElPadre 2014.02.07. 10:04:22

@titan: hát ez az. eddig valamennyire kényelmes volt ez a rész a webpajzsoknak, mert lusták voltak a drive-by attakok írói, és jobbára hasonló kódokkal oldották meg. most már magasabb fokozatba kapcsoltak.

a problémát akkor lehet véglegesen megoldani, ha a JS/ES sandbox specifikációját rendesen megírják, és ha a masszívan elterjedt scriptek felhagynak az eval használatával, hogy az eval-t magát ki lehessen iktatni ill. a legszigorúbb sandbox speckók vonatkozzanak rá.
Válasz erre 

titan 2014.02.07. 10:16:15

@ElPadre: alapvetően az interpreter dolga lenne az, hogy a megfelelő jogosultsági szinteket beállítsa az egyes kódoknak, az eval se rosszabb a többi kódnál, egyszerűen arra is megfelelő szabályozások kell, hogy vonatkozzanak. Egyébként amennyire tudom ezek a szabályozások alapvetően már meg is vannak. A kérdés innentől az, hogy miféle kártékony javascript kód lehetséges, és ha lehetséges, akkor miért egy szűrőnek kell azt megfognia, és miért nem a megfelelően megírt interpreter teszi azt.

Másik: felvetették, hogy a javascript milyen felesleges, szerintem is az, de csak ha túlzott mértékben támaszkodik rá valamilyen oldal, egyébként a felhasználói élmény fokozása érdekében nagyon is jól tud jönni. Ha pl. én fejlesztek valamit, akkor először úgy építem meg, hogy működjön minden javascript mentesen, és utána aggatom rá azokat a kódokat, amik javítanak rajta (pl. adott esetben overlay-ek, css-ből megoldhatatlan animációk). Flash-t már nagyon rég nem használok (egyébként furcsállom, hogy az actionscript problémái mostanában mintha kevésbé kapnának hangot)
Válasz erre 
süti beállítások módosítása