Intranetes betörés JavaScript-tel
Az SPI Dynamics a napokban zajló BlackHat USA 2006 konferencián tartandó előadásának beharangozásaként tette közzé a koncepciót bemutató JavaScript kódját, melynek segítségével az intranetünk gépei ismert minták alapján felderíthetőek. Manapság már szinte minden hálózati eszközben webszerver működik, elősegítve a távoli konfigurációt. Az SPI Dynamics pedig olyan szkriptet készített, amely a termékek által használt közismert képek és a beágyazott keretek segítségével azonosítani tudja, hogy egy adott hoszt létezik-e, és hogy milyen webszervert futtat.
A közzétett kód lehetővé teszi, hogy kipróbáljuk a módszert, és egyben természetesen meg is tekinthetjük magát a felderítésre használt JavaScript kódot. Az SPI Dynamics nem épített be semmilyen támadásra alkalmas funkciót a példakódjába, de megjegyzik, hogy a JavaScript lehetőségeit nem merítették ki, csupán demonstrációval szerettek volna szolgálni.
A potenciális IP címek felderítéséhez a JavaScript Image objektumot használják a kívánt ping funkcionalitás megvalósítására, majd egy Iframe alkalmazásával állapítják meg, hogy valóban webszerver fut a gépen. A különböző webszervert is tartalmazó készülékek és az ismert webkiszolgáló programok által megszokott helyen elhelyezett képek ellenőrzésével pedig a futó kiszolgálót tudják megállapítani.
A JavaScript alapú megoldás a rendszergazdák számára azért lehet ijesztő, mert a tűzfalakat könnyedén átlépi, a betörő szándékai szerinti kód tulajdonképpen a belső hálózaton belül van már. Éppen ezért összetettebb védelemre van szükség az ilyen sebezhetőségek kivédése érdekében. A módszert részletező PDF dokumentumban az SPI Dynamics a rendszergazdáknak azt ajánlja, hogy a legfrisebb biztonsági frissítéseket alkalmazzák a potenciálisan veszélyeztetett eszközökön, illetve hálózati behatolás érzékelőt működtessenek.
A webfejlesztőknek az esetből az az elsődleges tanulság, hogy a Cross Site Scripting sebezhetőségeket mindenképpen komolyan kell venni. Nem csak arról van ugyanis szó, hogy az ellenőrizetlenül weblapunkra került JS kódok miatt a felhasználónk azonosítóját vagy jelszavát megszerezhetik (bár ez sem túl üdvözítő), hanem a látogatónk helyi rendszerét is támadásnak tehetjük ki.
További információ az XSS-ről és más sebezhetőségekről, valamint kivédésükről PHP a frontvonalon, védekezés a bemeneten című cikkünkben.
■ A közzétett kód lehetővé teszi, hogy kipróbáljuk a módszert, és egyben természetesen meg is tekinthetjük magát a felderítésre használt JavaScript kódot. Az SPI Dynamics nem épített be semmilyen támadásra alkalmas funkciót a példakódjába, de megjegyzik, hogy a JavaScript lehetőségeit nem merítették ki, csupán demonstrációval szerettek volna szolgálni.
A potenciális IP címek felderítéséhez a JavaScript Image objektumot használják a kívánt ping funkcionalitás megvalósítására, majd egy Iframe alkalmazásával állapítják meg, hogy valóban webszerver fut a gépen. A különböző webszervert is tartalmazó készülékek és az ismert webkiszolgáló programok által megszokott helyen elhelyezett képek ellenőrzésével pedig a futó kiszolgálót tudják megállapítani.
A JavaScript alapú megoldás a rendszergazdák számára azért lehet ijesztő, mert a tűzfalakat könnyedén átlépi, a betörő szándékai szerinti kód tulajdonképpen a belső hálózaton belül van már. Éppen ezért összetettebb védelemre van szükség az ilyen sebezhetőségek kivédése érdekében. A módszert részletező PDF dokumentumban az SPI Dynamics a rendszergazdáknak azt ajánlja, hogy a legfrisebb biztonsági frissítéseket alkalmazzák a potenciálisan veszélyeztetett eszközökön, illetve hálózati behatolás érzékelőt működtessenek.
A webfejlesztőknek az esetből az az elsődleges tanulság, hogy a Cross Site Scripting sebezhetőségeket mindenképpen komolyan kell venni. Nem csak arról van ugyanis szó, hogy az ellenőrizetlenül weblapunkra került JS kódok miatt a felhasználónk azonosítóját vagy jelszavát megszerezhetik (bár ez sem túl üdvözítő), hanem a látogatónk helyi rendszerét is támadásnak tehetjük ki.
További információ az XSS-ről és más sebezhetőségekről, valamint kivédésükről PHP a frontvonalon, védekezés a bemeneten című cikkünkben.
Ijesztő
Harap a kicsiJ
Pedig igazából ez nem JS "feature", egyszerűen csak végiggondolták a lehetőségeket. Tetszik.
Betörés
<img src="" />segítségével) tudnak bármilyen GET/POST kérést imitálni, s így be tudnak lépni, létre tudnak hozni akár felhasználót is maguknak, vagy a tűzfalunkon engedélyezni egy távoli IP cím hozzáférését. Veszélyesen hangzik, de nem hiszem, hogy rövid távon megjelennének olyan megoldások, melyek széleskörűen ki is használnák.kis kiegészítés
Kis tévedés, mert a CSRF támadásban pont az a pláne, hogy nem kell tudnod az authentikációs adatokat, hiszen a user a szokott módon lép be a rendszerbe. Ezért fontos, hogy ha olyan a környezet, akkor a third party cookiek tiltva legyenek, valamint lehetőleg alkalmazás szinten védekezzünk ellene (formok kapjanak valami azonosítót, csak úgy ne lehessen elküldeni; valamint ha fontos funkcióról van szó, akkor a végrhajtás előtt kérjen megerősítést).
Felhő
Azért
Persze, ez nem bocsánat arra, hogy valaki elfeledtkezzen a védekezésről, de a támadhatóság súlyosságát (a rendszergazdák szemszögéből) valamelyest lejjebb viszi.
nem értem
Felhő
Belső hálózat
nem kell többször bejutni
Például ha van egy ismert (hibás) PHP groupware program az intraneten, aminek megfelelő URL paraméterével tetszőleges PHP kódot include-olhatunk távoli gépről, akkor ezt a szervert a JS meg tudja keresni, az include-os kérést el tudja indítani, utána viszont már a szerveren az include-olt kód azt csinál, amit csak lehet, és permanensen beépítheti magát.
Ahogy a blogbejegyzés is jelzi, a JS itt csak a kapu, amivel más sebezhetőségek kihasználhatóak. A fenti természetesen csak az én fantáziám szüleménye, és egy eléggé konkrét eset lehetséges leírása. Érdekes lenne megnézni, hogy az SPI Dynamics előadásában mi lesz még...
Elolvastam, de
Attól tartok, nem értitek a lényegét a mondanivalómnak. Ha egy ismetlen hálózatba jutok be ilyen módon, megkapom a webszerverek listáját és esetleg típusát. Utána, mint hacker, nyilván kielemzem ezeket az adatokat majd ezeket felhasználva egy támadást indítok.
De akkor újabb CSRF támadást kell végrehajtanom, most már módosított paraméterekkel. Ergo, meg kell várnom, amig még valaki abból a hálózatból belesétál a csapdámba. Nem jól mondom?
nem kell többször bejutni
olvasni
Felhő
rss is hasonló cipőben
Betanews: RSS Feeds at Risk From Attackers?
technikai részletek
gyakorlati alkalmazásra szemléltető példa (IFRAME)
http://jibbering.com/blog/?p=514
tanulságos dolgok ezek :)