Criptojacking: nyomás alatt a JavaScript-ökoszisztéma
Monero-bányászatra tudta rávenni egy támadó mintegy 4000 weboldal látogatóit, miután az egyik külső JavaScriptet a forrásnál módosítani tudta. Nagy nevű áldozatok, fontos tanulságok.
Több ezer weboldalon tűnt fel egy időre kriptobányász JavaScript kód a múlt héten - köztük olyan brit intézményekén, mint a helyi adatvédelmi biztosi hivatal, vagy a diákhitel, illetve a helyi egészségbiztosító oldala. A felfedezésből gyorsan hatalmas botrány kerekedett, az érintett oldalak nagy részét az üzemeltetők pánikszerűen lekapcsolták, máshol viszont az üzemeltetők azt sem vették észre, hogy mi történt.
Maga a támadás viszonylag egyszerűen leírható: a Browsealoud olyan technológiát fejleszt, amellyel a weboldalak könnyebben hozzáférhetőek (accessibility). Kínál nagyítót, felolvasást, egyszerűsített, olvashatóbb nézetet, gyakorlatilag mindent, amire egy (például kormányügynökségi) weboldalnak szüksége van ahhoz, hogy megfeleljen a hatályos előírásoknak. A megoldás ráadásul könnyedén integrálható, a weboldal kódjába kell behúzni a Browsealoud scriptjét és a kívánt funkcionalitás gyorsan elérhető.
A problémát a cég szerverei jelentették: bizonyos támadók hozzáfértek a browsealoud.com-on hosztolt ba.js-hez és azt egy olyan példányra cserélték, amely a normál funkciók mellett csendben kriptopénzt is bányászott a weboldalak látogatóinak gépén - ez pedig simán le is futott a sok ezer, Browsealoudra támaszkodó weboldalon. A Coinhive-ot meghívó kód némi obfuszkációval szerepel a kódban, de viszonylag egyszerűen visszafejthető.
A kívülről behúzott JavaScript rendkívüli kockázatot hordoz: az oldalon ennek a kódnak hatalmas jogköre van, ahogy Troy Hunt sorolja, képes módosítani a DOM-ot, átirányítani a felhasználót, további külső tartalmat tölthet be, kérheti a felhasználót szoftverek telepítésére, rögzítheti a leütött karaktereket és begyűjthet bizonyos sütiket is. A biztonsági kockázat a kriptobányászaton messze túlmutat, sőt, azt is mondhatjuk, hogy ez még az egyik legjobb figyelmeztetés arra, hogy a webes gyakorlaton sürgősen változtatni kellene.
Verziózás+ujjlenyomat
Hogyan lehet kivédeni az ilyen típusú támadásokat? - teszi fel a kérdést Troy Hunt infobiztonsági szakértő. Az egyik ilyen a Subresource Integrity, amellyel a weboldal fejlesztője megadhatja a kintről behúzott, ismert erőforrás hash-ét, így amennyiben azt valaki módosítja és a hash nem egyezik az ismerttel, a böngésző megtagadja annak betöltését.
A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.
A gondot itt az jelenti, hogy bizonyos erőforrások folyamatosan változnak, kvázi szolgáltatás formájában kínálja azt a másik fél, gondoljunk a Google Analyticsre vagy épp a fenti példában a BrowseAloud kódjára. Ezt a cég rendszeresen módosítja, fejleszti, új képességeket ad hozzá, ezt pedig megnehezíti a hash ujjlenyomat használatát. A kiegészítő megoldás itt a verziózás lehet: ha a folyamatosan változó kódhoz nem is lehet egy fix hash-t rendelni, egyes verziókhoz már igen. Némi problémát jelent, hogy az Edge egyelőre nem támogatja az SRI-t, de a következő főverzió már pótolja ezt a hiányosságot.
A verziózást viszont támogatnia kell a külső szolgáltatónak is, ebben pedig egyelőre nincs érdemi előrelépés, a gyakran behúzott külső tartalmak, mint a Google Analytics vagy épp a Disqus nem is támogatják ezt a megközelítést - így egyelőre csak korlátozottan vethető be ez a védekezési forma.