Detecting In-Flight Page Changes with Web Tripwires

1. 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)

2. 1. Bevezetés

3. 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

4. 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

5. 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

6. 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, …

7. 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

8. 2. Mérési tanulmány

9. 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

10. 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)

11. 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

12. 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.

13. 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)

14. Mérési eredmények

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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”

21. 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

22. 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…

23. 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

24. 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

25. 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!!!

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

27. 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

28. 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

29. Implementációs stratégiák

30. 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, ???)

31. 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

32. 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

33. 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á

34. 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)

35. 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

36. 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)

37. 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

38. 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ó?

39. É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)

40. 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%)

41. 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

42. Átvitt bájtok • 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

43. 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

44. 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

45. 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.

46. 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

47. 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

48. 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)

49. 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: