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 50.000 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: 50000 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ényekKategória IPs I E

U

A

Példák

Popup blokkoló

277 x Zone Alarm (210), CA Personal Firewall (17), Sunbelt Popup Killer (12)

Hirdetés blokkoló

188 x Ad Muncher (99) , Privoxy (58), Proxomitron (25)

Problem in Transit

30 x Blank Page (107), Incomplete Page (7)

Tömörítés 30 x bmi.js (23) , Newlines removed (6), Distillation (1)

Security or Privacy

17 x x Blue Coat (15), The Cloak (1) , AnchorFree (1)

Ad Injector 16 x MetroFi (6), FairEagle (5), LokBox (1), Front Porch (1), PerfTech (1), Edge Technologies (1), knects.net (1)

Meta Tag Changes

12 x x Removed meta tags (8), Reformatted meta tags (4)

Malware 3 x W32.Arpiframe (2), Adware.LinkMaker (1)

Egyéb 3 x New 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: http://www.google.com De ha

http://google.com/?</script><script>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:

<!-- the-cloak note - deleting possibly dangerous META tag - unknown NAME ’generatorversion’ -->

DE: <meta name="foo--><script>alert(1);</script>"> [*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ákCount 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 <script> 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ájtokTechnika Data Transferred

Original 226.6 KB

Web Tripwire 265.8 KB

Web Tripwire (tripped) 266.0 KB

HTTPS 230.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: http://www.cs.washington.edu/research/security/webtripwires.html

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: <script type="text/javascript" src="webtripwire.cgi?page=OLDALNEV"></script>

a html mellé a webtripwire.cgi Statikus:

<script type="text/javascript" src="webtripwire-OLDALNEV.js"></script> 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

http://marcy.web.elte.hu/test/webtripwires.htm 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: