Detecting In-Flight Page Changes with Web Tripwires Avagy hogyan észleljük weblapokon az „utazás” közben történt változásokat… Source: same titled article by Charles Reis (University of Washington), Steven D. Gribble (University of Washington), Tadayoshi Kohno (University of Washington), Nicholas C. Weaver (International Computer Science Institute)

1. Bevezetés

Kitérő : Tripwire Linux Adatintegritás ellenőrző Digitális ujjlenyomat a könyvtárakról/fájlokról Adatbázisba kerül Így kiszűrhetőek a nem kívánt változások

Bevezetés: In Flight Changes HTTP: van lehetőség az oldal módosítására utazás közben Általános gondolkodás: általában nincs változtatás EZ TÉVEDÉS A cikk íróinak szerverén IP esetén: 1,3%-nál történt változás

Bevezetés: miért vizsgáljuk Sokféle típusú módosítást észleltek pl  Internetszolgáltatók (ISP): reklámok beszúrása  Végfelhasználók: reklámok, popup-ok eltávolítása  Malware készítők: férgek terjesztése Ezek közül sok nemkívánatos a felhasználónak vagy a kiadónak  Reklámok ki/be: a kiadó bevételei, bosszantja a felhasználót  SŐT: hibák, sebezhetőségek beszúrása sok biztonságos és hibamentes oldalba

Bevezetés: miért vizsgáljuk, HTTPS Az esetleges negatív következmények miatt  Észlelni, és figyelmeztetni a felhasználót  megakadályozni  De nem minden változás nem kívánt: céges proxik a privacy védelme, biztonság növelése miatt HTTPS  Kódolás miatt erős megoldás DE  A HTTPS végpontok tudnak változtatni  költséges: és megakadályozza az előnyös változtatásokat: cache, tömörítés, …

Bevezetés: web tripwires Ezért a kiadóknak érdemes alkalmazni a ~  Kliens oldali JavaScript a változások észlelésére  Nem 100% észlelés, biztonság DE a gyakorlatban : Kisebb költségű mint a HTTPS Nem kell a böngészőkön változtatni Sokféle stratégiát támogat Továbbiakban  Mérési tanulmány  ~ implementációs stratégiák  hatékonyság

2. Mérési tanulmány

Mérések Elvárás volt: a felhasználók változás nélkül kapják amit a kiadó nekik szánt Ez nincs mindig így: kérdés mennyire Egy html oldalt terveztek, ami képes figyelni a változtatásokat Kérdések  Milyen típusú változások milyen gyakran történnek?  Van-e ezeknek előre nem látható következményük? Eredmény: IP: >1%, sok negatív következmény

Mérések: böngésző kiterjesztések A kiterjesztések általi változásokat nem figyelték, hiszen azok a felhasználó tudtával tevékenykednek (gyakorlatilag azok nem is a html kódon, hanem a már a böngésző belső reprezentációján dolgoznak)

Mérések: Technológia 1 A használt „web tripwire” egy JavaScript kód  Ami az oldal betöltésekor fut le  Minden érzékelt változásról riportot küld a szervernek, és tájékoztatja a felhasználót.  Képes megjeleníteni az elvárt és a kapott tartalom eltéréseit  Információt gyűjt a környezetéről

Mérések: Technológia 2 Két megjegyzés  Előfordulhattak hamis negatívok (volt változás, de nem láttuk), ha csak olyan oldalon változtatottak, ami nem tartalmazza a scriptet)  Ez a technológia nem titkosított, úgyhogy a reklámozó ügynök ha akarta eltávolíthatta, befolyásolhatta a scriptet, ám nem valószínű hogy széles körben ilyen beavatkozások történtek volna.

Mérések: realitás A mérési oldalnak valóságszerűek kellet lenni  Html-tagok web-authoring programból, véletlen szöveg és kulcsszavak linkekkel különböző TLD-s * használata  Internetszolgáltatók: beszúrt reklámok NebuAd  ennek csak a.com TLD-kre van hatása A mérés közben felvett új  Hátha „white-list”-ra kerül Tapasztalat  A legtöbb változás válogatás nélkül  Néhány NebuAd.com specifikus  Más NebuAd több TLD-re (ismeretlen minta)

Mérési eredmények A reprezentatív rálátás miatt többféle helyzetű látogatóra volt szükség Végül a Slahdot news, és Digg honlapjának címlapján gyűjtötték az adatokat egyedi IP, ebből 657 esetben történt módosítás  70%-a kliens oldali proxik (popup blokkolók, …)  46 esetben az internetszolgáltató végzett módosítást  125 cím proxy-ja volt sebezhető a cross-site scripting támadásokra  3 cím érintve volt kliens alalpú malware-kal

Mérési eredmények KategóriaIPsIE U A Példák Popup blokkoló 277xZone Alarm (210), CA Personal Firewall (17), Sunbelt Popup Killer (12) Hirdetés blokkoló 188xAd Muncher (99), Privoxy (58), Proxomitron (25) Problem in Transit 30xBlank Page (107), Incomplete Page (7) Tömörítés30xbmi.js (23), Newlines removed (6), Distillation (1) Security or Privacy 17xxBlue Coat (15), The Cloak (1), AnchorFree (1) Ad Injector16xMetroFi (6), FairEagle (5), LokBox (1), Front Porch (1), PerfTech (1), Edge Technologies (1), knects.net (1) Meta Tag Changes 12xxRemoved meta tags (8), Reformatted meta tags (4) Malware3xW32.Arpiframe (2), Adware.LinkMaker (1) Egyéb3xNew background color (1), Mark of the Web (1)

Mérési eredmények: elemzés Tehát meglehetősen színes képet láthatunk A internetszolgáltatók, a vállalatok, a felhasználó, a támadók mind végeznek módosításokat Ezen változások gyakran szemben álnak a felhasználói és a kiadói célokkal  Kiadó: tartalom nyújtása a felhasználóknak, esetleg egy bevétel forrással a reklámokból  Felhasználó: biztonságos tartalom kevés bosszantó dologgal

Mérés elemzése: Internet szolgáltatók Két fő ok a módosításra  Bevétel generálás reklámokkal  Forgalomcsökkentés tömörítéssel A beszúrt reklámok bosszantják a felhasználókat Partner cégek  reklámok beszúrására (pl 5 ip: NebuAd szerveréről beszúrt kód)  Sok közülük állítja: felhasználói szokásokon alapul  Privacy sérülése: web-tripwire: látják mi az egyedi reklám, ez alapján: hol járt a legutóbb a felhasználó Forgalomcsökkentés  Whitespace-k eltávolítása, image-distillation, de hibákat okozhatnak

Mérés elemzése: vállalatok Okok  Forgalom csökkentés  Ügyfelek védelme Megfigyelések  Metatagok eltávolítása, hogy a kiadó akarata ellenére a cache-lés engedélyezve legyen  Blue Coat WebFilter: vállalati proxy a rosszindulatú forgalom ellen

Mérés elemzése: Végfelhasználók 1 Okok (rengeteg ok):  Popup / ad blockers  Biztonság  teljesítmény A felhasználó által telepített program végzi Popup blokkolók  Érdekes: nem csak popup blokkolok, de tűzfalak is  Általában beszúrt JavaScript kód, window.open-re közbelép

Mérés elemzése: Végfelhasználók 2 Ad blokkolók  Egyre népszerűbbek, de a mérési oldal nem tartalmazott reklámokat, így nem jelent meg  De észleltek ad blocking proky-kat a beszúrt JS-ből Biztonság növelése, hatékonyság  AnchorFree Hotspot Shield: Wifi-n védi a felhasználót  IE: támadások ellen a mentett fájlba „Mark on web” komment  Anonymization servuces: pl The Cloak  Proxy-k amik eltávolítják a cache tiltó metatag-ot és cache-lik az oldalt

Mérés elemzése: Malware szerzők Okok  Rosszindulatú kódok terjesztése (malware)  Bevétel beszúrt reklámokból (adware) Pl: Adware.LinkMaker (1 kliens volt fertőzött)  Változások: kétszer aláhúzott szavak - mouseover: ad frame W32.Arpiframe féreg (2 kliens esetén)  Lehet hogy a kliens maga nem fertőzött  Ez a féreg LAN-on terjed ARP cache mérgezéssel  „Man-in-the-middle”

Mérések: nem várt problémák A fenti változások valamely fél érdekein alapult De sok közülük súlyos következménnyel járhat:  Sérült funkcionalitás  sebezhetőségek

Problémák: oldal hibák Kétféle típust figyeltünk meg:  A beszúrt JS a tripwire-val együtt IE verem túlcsordulás okozott Pl: xpopup.js a CA Personal Firewall popup blokkolója Pl: bmi.js tömörítő script Néha megakadályozva a tripwire jelentését Többféle script, egyazon névtér tesz nélkül =>   A CA Personal Firewall által beszúrt kód sok helyen interferál a blogbejegyzések kommentek elküldésével A beszúrt kód megjelent a kommentben…

Sebezhetőségek : Ad blocking Sok beszúrt tartalom sebezhetően hagyta az oldalt a xss-el szemben (xss: pl egy form-ba JS kódot írva az lefutattható) Ad blocking sebezhetőségek  2 free, 1 kereskedelmi ad blocker esetén  Ezek beszúrják az oldalba JS kommentként az URL-t: // Original URL:  De ha alert(1);  A sebezhetőség kihasználása Bank login formja (HTTP, csak a válasz HTTPS) Google keresési formja

Sebezhetőségek: IE A lementett oldalakba hasonlóan beszúr „Mark on web” Kevésbé súlyos  Csak lemezről való beöltéskor futhat  Így nem fér hozzá a szerverhez vagy cookie-khoz

Sebezhetőségek: The Cloak Névtelenség  Lekéri a weblapot a felhasználó nevében  Sok tagot eltávolít/átír (ne szivárogjon ki adat) Akár az összes JS (*) Két féle xss sebezhetőség  Megmagyarázza miért távolított el valamit: DE: alert(1); "> [*kikerüli]  Böngészők „Same origin policy” : Minden oldal a cloak.com-ról oldalak hozzáférhetnek egymás adataihoz!!!

3. Web Tripwires implementációs stratégiák

Motiváció Láttuk hogy a beszúrt kódoknak sok negatív következménye lehet. HTTPS egy megoldás, de kizárja  Proxy-k általi cache  Image distillation (kép „tömörítése”)  Biztonsági ellenőrzések vállalati proxy-k által De kell  Kulcs csere  CPU overhead a szerveren

Célok Észlelje az „utazás” közben történt változásokat  (kivéve a böngésző bővítmények által történteket) Megakadályozzon bizonyos változásokat  Nehéz kódolás nélkül, de nem mindenhol igény Mind a felhasználó, és a kiadó felé jelezze, és segítsen megérteni a változás okát Ne zavarja a funkcionalitást és a teljesítményt  Oldal szemantikája  Back gomb

Implementációs stratégiák Count Scripts Check DOM XHR then Overwrite XHR then Redirect XHR on Self HTTPS Detects all HTML changes ***** Prevents changes** Displays difference *** Preserves semantics ***** Renders incrementally **** Supports back button ****

Tervezés és implementáció Több stratégia lehetséges Itt JS alapú implementáció Mindegyik azonos megközelítéssel  A szerveren 3 elem van  A kért oldal, a tripwire script, és egy „jó változat” A jó változat cheksum, vagy kódolt string  Ha a böngésző megkapja mindhármat Minden implementációnál: a szerver tudja a tervezett tartalmat  Dinamikus oldalak? Más szerver? (cache, ???)

Count Scrips Megszámolja a tagokat A mérések alapján a módosítások 90%-át észleli A „jó változat” itt a scriptek száma Hátrányok  Ha nem script beszúrás történt nem érzékeli  Nem egyszerű megmondani melyik az új script Előnyök  Egyszerű  Nem interferál az oldallal

Check DOM Jó lenne a teljes tartalmak összehasonlítása  De egy JS nem fér hozzá a kapott html-hez  Csak a DOM-fához document.documentElement.innerHTML  De ez az ábrázolás böngésző/verzió függő A szerveren előre kell az összeshez a „jó változat” Ez a technika a gyakorlatban megvalósíthatatlan Hisz még a felhasználó pontos azonosítása sem biztos Azaz az összes változatott el kéne küldeni Mi egy cheksum listát használtunk  Így lehetetlen a pontos változások megállapítása

XHR A böngészők belső html reprezentáció ellenőrzése:  Kapja a felhasználó adatként az oldalt: XMLHttpRequest  Tripwire is megkapja a teljes oldalt  A kérés megkülönböztethetetlen a weboldal kérelmektől  A böngésző bővítmények nem nyúlnak hozzá

XHR then Overwrite Működés  Kis indító oldal (tripwire & „jó változat”)  Utána lekérni kért oldalt  A tripwire érzékeli a változásokat, és a document.write felülírja az indító oldalt Előny  Megakadályozza a változtatást Nem biztonságos: Az indító oldal felülírható Hátrány  Render: egyszerre lehet csak betölteni  Firefox esetén a document.write ütközik a vissza gombbal  IE és Safari: document.write bugok (Safari: cookie, IE üres srciptre fagy)

XHR then Redirect A document.write hátrányait el kell kerülni A felülírás helyett átirányítjuk a kért lapra  A lap cacheable  Így a böngésző az XHR által a cache-be került változatot tölti be (nem kéri el újra a szervertől) Hátrány  Betöltés  Már nincs meg a megelőzési lehetőség  Vissza gomb

XHR on Self Működés  Először elküldjük a kért oldalt (Render OK)  Majd a kért oldal kéri a külső tripwire scriptet (benne a „jó változat” string kódolva)  A script ezután XHR-el kéri el újra a kért oldalt (mivel a lap cacheable, így a cache-ből kapja) Hátrány  Nehéz lenne a változásokat megelőzni (a tripwire előtt futó JS…) Előny  A legtöbb célnak megfelel (változások szűrése, különbségek, szemantika, fokozatos betöltés, vissza gomb)

HTTPS A fenti technikák vs https  A célok kissé eltérnek https a felhasználók számára bizalmasság és sértetlenség a szervernek nem ad információt ezek tejlesüléséről HTTPS erősebb biztonsági garanciákat ad  Kódólás (képek és bináris adatok is)  visszautasít bármilyen megváltoztatott tartalmat Biztosítva van a fokozatos betöltés, szemantika Azonban drága A tripwire-k több döntési lehetőségeket adnak

4. Értékelés, hatékonyság Érdemes-e web tripwire használata?  Megfizethető-e a sima HTTP-vel szemben?  A HTTPS-hez képest a költségei?  Mennyire megbízható?

Értékelés Az összehasonlítás  Latecy (késés)  Throughput (áteresztő képesség) 4 változata egy főbb bank honlapjának  HTTP  Web-tripwire (XHR on Self)  Web-tripwire (XHR on Self) ami riportot készít a módosítást  HTTPS 3Ghz Xeon, Apache 2, Fedora Core 6 (nincs hardveres SSL gyorsítás)

Latency mérése Mérési módszer  Kis, oldalba ágyazott scriptek  start latency: első script lefut  end latency: onload esemény (a betöltés végén)  Az átvitt bájtok mérése Firefox, szimulált 2Mbps sávszélesség 50 ms egyirányú link latency 5 mérés (a maximális relatív hiba 3,25%)

Eredmény start latency  Nem nőtt 240 ms  SSL-nél a kapcsolódás miatt 840 ms Betöltési idő  Hosszabb a tripwire számításai miatt  A riport készítőnél még hosszabb (összes különbség kiszámítása) Teljes latency  Még így is a HTTPS oldal alatti

Átvitt bájtok TechnikaData Transferred Original226.6 KB Web Tripwire265.8 KB Web Tripwire (tripped)266.0 KB HTTPS230.6 KB A web-tripwire 17,3%-al növelte az átvitt adatmennyiséget  Ez a html kód teljes kódolt változata (ami kis %-a az egyéb beágyazott tartalmaknak) A jövő tripwire-i akár ellenőrizhetik a teljes átvitt tartalmat  Esetleg, csökkenthető az overhead cheksum-okkal

Throughput Két Feadora Core 6 kliens, 1Gbps hálózat, elhanyagolható latency, Mindig növelve a terhelést, sessionok számának hosszantartó tetőzésig A web-tripwire csak 4% visszaesést okozott HTTPS az SSL kézfogások miatt CPU terhelés

Módosítók kezelése 1 A módosítók  nem feltétlen akarják hogy észleljék a változást  hirdetések, beszúrása, rosszindulatú kódok A végfelhasználó  elrejtené a kiadóktól, hogy milyen proxy-kat használ (ad-blockers) A web-tripwire-k nem érzékelnek mindent  Pl: a teljes oldal cseréje  Így ez a technika nem véd azoktól, akik minden áron rosszindulatú tartalmat akarnak adni

Módosítók kezelése 2 Inkább az a modell  A módosítók meg akarják őrizni a funkcionalitást  Közben vezet be változásokat  Azaz képes megfigyelni késleltetni és önkényesen módosítani a csomagokat  Azaz a felhasználóban van valami elvárás a tartalomra Itt a web-tripwire-k hatékony módszer lehet  A módosítóknak meg kell találni, és letiltani őket De a kiadók a kód összekeverésével, több változatával, a „jó változat” reprezentációnak változtatásával védekezhetnek. Vagy egyéb funkcionalitási JS-ekkel való integrálás.

Módosítók kezelése 3 Azaz kialakulhat egy verseny a kiadók és a mosósítók között, amelyben a fenti technikák segíthetik a kiadókat Habár ahol kritikus kérdés az integritás HTTPS-re lehet szükség

Saját tapasztalat 1 A washingtoni egyetem kutatói a tanulmány mellé, egy web-tripwire toolkit-et is készített: A XHR on Self stratégiát követi A JavaScriptet egy CGI állítja elő. Két mód:  Dinamikus: minden kéréskor CGI előállítja a scriptet (benne kódolva az oldal „jó változat”-a)  Statikus: adott oldalakhoz a CGI-vel előre legenerált JavaScripteket használunk

Saját tapasztalat 2 A letöltött zip tartalmaz minden fájlt. A védendő oldal mellé fel kell másolni a szerverre:  webtripwire.css, webtripwire.gif, webtripwire-submit.cgi Dinamikus:   a html mellé a webtripwire.cgi Statikus:   Futtasd:./webtripwire.cgi "page=OLDALNEV.htm" > webtripwire- OLDALNEV.js  Töröld ki a script első két sorát (karakter kódolási direktívát)  A html mellé webtripwire-OLDALNEV.js (script+kódolt változat)

Saját tapasztalat Próbálkoztam a washingtoni egyetem példaoldalával, de nem történt változás utazás közben. Ezért eme oldalhoz a statikus módon legeneráltattam a js-t (benne a kódolt „jó változat”-tal), majd szándékosan változtattam a kódon. Így szimulálva az út közben történt változást, és: