FireSheep i Session Hijacking – kad ti ovce spale farmu

Par mjeseci (ili tu negdje) prije objavljivanja ovog teksta pojavio se jedan jako zanimljiv (blago rečeno) plugin za Firefox. FireSheep nije uvršten u Mozillinu oficijelnu kolekciju proširenja (dakle, Mozilla FireSheep ne podržava, ali ga ni ne zabranjuje), što je razumljivo obzirom na to da je plugin namijenjen isključivo session hijackingu putem bežičnih mreža. Možda vam ovih par općenitih opisa ne znači puno, u nastavku teksta pokušat ću pojasniti o čemu se zapravo radi.

Prije nego krenemo s istraživanjem šta to FireSheep radi i kako, želim naglasiti da nikako ne podržavam korištenje FireSheepa i sličnih alata, nikada ga nisam koristio niti to namjeravam u budućnosti. Mislim da bi se takva radnja komotno mogla svesti pod hakiranje, a to je nešto što nit’ volim nit’ zagovaram. Međutim, da se FireSheepom nešto postiglo, sigurno jeste. Ali i o tome ćemo u nastavku.

Imajte u vidu da je tekst pisan za laike, samim tim jako uprošten i kad bi željeli cjepidlačiti, neki navodi možda i nisu apsolutno tačni – no poslužit će za potrebe ovog teksta. Problemu pristupam izokola, želim čitateljima pojasniti kontekst problematike, jer, kao što ćete vidjeti, FireSheep, makar bio povod pisanja ovog teksta, samo je simptom, a nikako uzrok problema sa kojima se susrećemo. Da bi shvatili o čemu se radi morati ćemo zagrebati nešto dublje, do osnova Interneta i mreža općenito. Trudit ću se da ne zađem previše u tehnikalije, taj dio ostavit ću za sam FireSheep.

Svjestan sam da je ovo još jedan jako dug post i da će ga zbog toga mnogi zaobići. Ali svjestan sam i toga da neupućenost i neinformiranost ne štiti. To što ne znate šta je session hijacking i kako se od njega štititi ne znači da ne možete postati žrtva, stoga vam toplo preporučujem da izdržite do kraja – ne dozvolite da vam vatrene ovce ‘spale’ FarmVille imanje…

Pa, krenimo.

Kako je sve počelo?

24.10.2010. na konferenciji pod nazivom ToorCon 12 Annual Security Conference, Eric Butler i Ian Gallagher, sigurnosni eksperti iz Seattlea, SAD, održali su prezentaciju naslovljenu: “Hey Web 2.0: Start protecting user privacy instead of pretending to” (“Hej Web 2.0: Počnite štititi svoje korisnike umjesto što se pretvarate da to radite”) – slajdove prezentacije možete pogledati ovdje (samo mijenjajte broj slajda u adresi).  Kao opis svoje prezentacije naveli su:

Despite growing public concern over web privacy, especially within social networking sites, companies including Facebook, Twitter, and even Google all fail to protect users against session hijacking attacks. These attacks are nothing: Session hijacking is one of the oldest, simplest, and most widely known attacks against the web. An interested attacker can view your private Facebook photos, broadcast Tweets as you, see your web history, and anything else you can do while logged in to your own online accounts.

 

We’re bringing up this tired issue to remind people of the risks they face, especially when on open WiFi networks, and to remind companies that they have a responsibility to protect their users. To drive this point home, we are releasing an open source tool at ToorCon 12 which shows you a ‘buddy list’ of people’s online accounts being used around you, and lets you simply double-click to hijack them.

‘Open soure tool’ koji spominju je ništa drugo no naš sada već famozni FireSheep. U trenutku pisanja ovog teksta FireSheep je downloadan 1.056.983 puta (to bi bilo preko milion).

Počnimo od početka: Sesija / Session

Web stranica i web site su različiti pojmovi. Em’ što se različito pišu i izgovaraju, em’ što prestavljaju različite stvari. Web stranica predstavlja, u principu, html dokument (zanemarimo na trenutak skripte i web aplikacije, kad se svede na ono osnovno, ostane nam html dokument), dok je site kolekcija (obično) semantički vezanih html dokumenata, obično pod istim URIem.

Sesiju je nešto teže definirati, ali za potrebe ovog teksta dovoljno je reći da sesija podrazumijeva komunikaciju (razmjenu podataka – može uključivati više razmjena u više vremenskih trenutaka) u kojoj su jasno utvrđene obje tačke i gdje bar jedna od tih tačaka pohranjuje informacije o sesiji. Ono što je za nas bitno je da se sesija može nastaviti u trenutku različitom od trenutka uspostave sesije.

Primjer sesije je Login sesija, npr. korisnik se autorizirao na nekom web siteu (npr. facebook), posjetio ga, otišao, vratio se nakon izvjesnog vremena i nastavio korisiti usluge sitea bez ponovne autorizacije – korisnik je nastavio svoju sesiju.

Također, sesija je krucijalna za jednokratnu autorizaciju korisnika na svim stranicama nekog sitea (npr. logali ste se na facebook homepage i ne morate se ponovno logati kad hoćete pogledati nečiji profil ili pregledati slike – jedan login, jedna sesija, vrijedi na svim stranicama).

Cookie

Cookie (kolačić) je prilično stara tehnologija i apsolutno sveprisutna na webu. Najpoznatija inkarnacija svakako je HTTP Cookie, mada su i druge tehnologije prihvatile koncept. Cookie je tekst (dakle, neizvršna informacija) koja se pohranjuje na kompjuteru – klijentu. Tekst sadrži podatke na osnovu kojih server klijentu pri narednim posjetama može ponuditi prilagođenu uslugu: od identifikacije i autorizacije klijenta do raznih postavki i slično. Cookie je postao nezamjenjiv instrument pri radu sa sesijama – server na korisnikovo računalo pri uspostavljanju sesije postavlja cookie, koji kasnije browser serveru može ‘vratiti’, indicirajući na taj način da korisnik želi nastaviti svoju ranije uspostavljenu sesiju.

HTTPS i SSL/TLS

SSL (Secure Socket Layer) i TLS (Transport Layer Security) su dva srodna sigurnosna protokola namijenjena podizanju nivoa sigurnosti i privatnosti komunikacije na Internetu. U kombinaciji sa HTTPom čine HTTPS protokol (HyperText Transfer Protocol Secure), osnovu sigurnog browsanja, a koriste se i sa nekim drugim Internet protokolima (POP3, SMTP, FTP…).

U svojim začecima Internet je bio namijenjen isključivo javnoj razmjeni informacija. Npr. kada pristupate ovom mom blogu, to činite putem običnog, nezaštićenog HTTPa, jer je sadržaj namijenjen svakome ko ga želi čitati, ništa se ne taji, ništa nije povjerljivo ili privatno. I danas je dobar dio sadržaja na Internetu javan, i u tim situacijama je korištenje enkripcije suvišno (zanemarimo na trenutak pitanje privatnosti u smislu da neko treći-deseti prati vaše kretanje po webu). Međutim, kako su se počele pojavljivati mnogo osjetljivije usluge, tipa Internet bankarstvo, ili usluge gdje pohranjujemo osobne podatke koji nisu namijenjeni svima, poput facebooka, enkripcijom podržan HTTPS počinje dobivati na smislu.

Smisao SSL/HTTPS sesije je uspostavljanje sigurnog kanala komunikacije između klijenta i servera, koji podrazumijeva enkripciju razmjene podataka, ali i provjeru autentičnosti njihova izvora (međusobna provjera identita). SSL i HTTPS su relativno stare tehnologije, s nama su već 20ak godina ili tu negdje, dakle, dovoljno su dugo tu da su apsolutno univerzalno podržane. Kada surfate koristeći HTTPS, daleko vas je teže pratiti (zapravo, izuzetno teško, ali ne i nemoguće) i gotovo nemoguće prisluškivati. Problem je u tome što je uspostavljanje sigurne sesije tehnološki kompliciranije i ‘skuplje’ kad su resursi u pitanju (treba više procesorske snage da se sva ta enkripcija prožvaće). U današnje vrijeme radi se o smiješno maloj cijeni u kompjuterskim resursima, bar iz perspektive korisnika, no kada se radi o serverskom sistemu sa milionima i milionima sesija u svakom trenutku, priča je nešto drukčija.

U današnje vrijeme postoji (osnovan, dobrodošao, i dobrano zakasnio) trend forsiranja HTTPSa gdje god je moguće, a predvodnik trenda je Google. Npr. već je neko vrijeme moguće Googleovoj tražilici pristupati putem HTTPSa (tako da niko osim Googlea i vas ne zna koje pojmove tražite), a odnedavno se i Gmailu može pristupati isključivo na siguran način – niko ne može ‘prisluškivati’ vašu poštu. Istim primjerom vodi se i PayPal. Na žalost, nisu svi tako ažurni…

WiFi sigurnost (WPA)

Internet se zasniva na međusobnom povjerenje. Vi vjerujete da niko ne prisluškuje komunikaciju izmđu vas i vašeg ISPa postavljajući kakav međuserver na kabl između vašeg stana i ISPa. Vjerujete i da ISP ne prisluškuje vaše online aktivnosti. Vaš ISP ima povjerenje u svoj nad-ISP da ne čini isto itd. Ovo povjerenje je u velikoj većini slučajeva opravdano, a onda kada postoji sumnja postoje tehnologije poput SSL/TLS i HTTPSa.

Govorim o prisluškivanju, praćenju, man-in-the-middle napadima. Srećom, ove stvari nisu toliko česte, dijelom zato što je za njih potreban pristup mediju razmjene podataka, u našem slučaju kakvom kablu, što nije uvijek praktično ili fizički izvedivo. Ali šta kada se radi o bežičnim mrežama, kada je medij razmjene informacija eter – zrak?

Koliko god da je ne-apsolutna, fizička nepraktičnost pristupa mediju (kablu) pruža nezanemarivu zaštitu našoj mrežnoj komunikaciji. Međutim, kada je medij zrak, svima uvijek lako dostupan, javlja se čitav niz novih sigurnosnih briga i problema. O ovome sam detaljnije pisao u jednom od prethodnih tekstova, (Ne)sigurnost bežičnih mreža (WiFi/WLAN) na javnim mjestima, koji vam toplo preporučujem jer je i dalje aktualan i zapravo se bavi istim problemom, samo ga promatra iz drugog ugla.

Da ukratko rezimiram: podaci bežičnih mreža se razmjenjuju radio-valovima. Svako sa odgovarajućim primopredajnikom (bežičnom mrežnom karticom, danas je ima svaki laptop) može sudjelovati u razmjeni, makar je samo ‘slušati’. Fizička nepraktičnost pristupa mediju tako je znatno umanjena – sve što gledate na Internetu može vrlo lako biti poznato svima u dometu. Korištenje nezaštićene bežične mreže za logovanje na neku stranicu analogno je vašem vikanju svog korisničkog imena i šifre u prepunom kafiću: mogu vas čuti svi koji žele, a onim kojima je baš stalo vaše podatke mogu zapamtiti i ništa ih ne sprječava da ih kasnije iskoriste.

Zato su bežične mreže od samih početaka podržane eknripcijskim protokolima i izuzetno je bitno da se ti protokoli koriste. WPA/WPA2, današnji standardni protokoli za enkripciju bežičnih mreža, čak i kada se koristi unaprijed dijeljena i svima poznata šifra mreže (tzv. pre-shared key, PSK) implementira međusobnu izolaciju komunikacije pojedinih klijenata priključenih u mrežu. To se ostvaruje šiframa koje su jedinstvene i dodjeljuju se svakom od klijenata, tako da tu šifru (Private Temporary Key, PTK) znaju samo pristupna tačka i taj klijent. Bez poznavanja PTK komunikacija između odgovarajućeg klijenta i pristupne tačke ostalima (makar bili klijenti iste mreže) čini se kao gomila nasumičnog šuma.

Dakle, korištenje WPA/WPA2 osigurava sigurno korištenje bežične mreže i služi kao prevencija čitavom nizu problema/napada. Na žalost, iz praktičnih i sasvim razumljivih razloga, na javnim mjestima bežične mreže često nisu zaštićene eknripcijskim protokolom. Ako dođete u situaciju da se poslužite tom mrežom, nemojte koristiti online usluge koje barataju vašim osobnim podacima. Ne provjeravajte mail. Ne posjećujte facebook, Twitter, e-bay, amazon ili nešto slično. Čak i kada vjerujete davatelju usluge bežične mreže (doista, vjerujete li gazdi kafića u kom surfate ‘netom?), vjerujete li liku s laptopom za stolom do vas?

Neko će reći: “Zašto bi neko prisluškivao mene, ja ionako ništa ne krijem?”. Zato što može i vi ste mu se našli pri ruci, i zato što prisluškivanje zlonamjernom korisniku otvara čitav niz mogućnosti o kojima možete čitati u nastavku.

Session Hijacking

Sjećate se priče o sesijama? Kako nakon inicjalne autentikacije naknadne nisu potrebne, jer se sesija može nastaviti? Session Hijacking je pojava, doslovno, otimanja sesije, obično na način da neko treći neovlašteno nastavi vašu sesiju. Obzirom da je cookie instrument upravljanja sesijama, session hijacking se često izvodi krađom cookiea u kom su zabilježeni podaci o sesiji.

Ukoliko se session hijacking eksploatira na način da su i napadač i žrtva u istoj lokalnoj mreži, iz perspektive Internet servera iza istog routera (npr. bežična mreža nekog kafića), zahvaljujući NATu (Network Address Translation) server ‘vidi’ da oboje, iz njegove perspektive, imaju identičnu IP adresu, adresu njima zajedničkog routera! Serverima, tj. pružateljima Internet usluga, ova i slične stvari otežavaju prepoznavanje session hijackinga.

U ovom tekstu koristio sam termin hijacking, mada u konkretnom kontekstu bi sidejacking bilo korekntije. Za objašenjenje razlike između ova dva termina, ali i pregled izloženosti nekih često korištenih Internet usluga pogledajte Online services security report card.

FireSheep

An Extra Offering by treehouse1977

Kada kombiniramo sve pobrojano: sesije i njihovo nastavljanje korištenjem cookiea, korištenje nešifrovanih bežičnih mreža i session hijacking, dođemo do problema koji tako efektno naglašava FireSheep. Razmislite: šta sprječava nekog zlonamjernog da prisluškujući vašu (nešifrovanu) bežičnu mrežnu komunikaciju iskopira vaš cookie i kasnije ga koristi kao svoj? Ništa, zar ne (izuzev što je za takvo nešto ipak potrebno podosta znanja)? A šta time taj neko dobiva? Dobiva ovlasti na usluzi čiji je cookie ukraden istovjetne onima koje ste imali vi u aktuelnoj sesiji. Ako koristimo primjer facebooka, taj neko može sve što možete i vi bez ponovnog unošenja šifre: može dodavati i brisati prijatelje, pregledavati sve vaše privatne slike, dodavati nove i brisati postojeće, slati vašim prijateljima poruke i postavljati statuse, a svi će misliti da ste to zapravo vi. Sa stanovišta facebooka, sve akcije ste poduzeli vi, jer radi se o vašoj sesiji, cookie je tu da posvjedoči da je doista tako…

Kao što vidite, FireSheep nije problem; problem je s nama već dugo-dugo, i malo ko je učino malo šta da se on otkloni. Rješenja postoje jednako dugo, ali kao što ćemo vidjeti, njihova implementacija je, na žalost, rijetkost. Iako su hakeri odavno zloupotrebljavali ovu problematiku, hakera, tj. ljudi s dovoljno znanja da zloupotrijebe propust je relativno malo. A onda se pojavio FireSheep – plugin za browser, koji je ništa drugo do interface koji omogućava izvođenje session hijackinga uz minimum informatičkog znanja. Uz FireSheep haker može biti bilo ko s kompjuterom opremljenim Firefoxom i bežičnom mrežnom karticom. Stoga nije ni čudo da se odjednom toliko pažnje pridaje problematici. Na žalost, kako to obično biva, medijska pažnja usmjerena je na FireSheep, umjesto na nemar Internet giganata koji nas je doveo u nezavidnu situaciju u kojoj se nalazimo.

Kako FireSheep radi? Za početak analizirajmo kako radi (na žalost, većina) stranica na Internetu. Kada se logujete, to (za nadati se) radite putem neke login stranice kojoj se pristupa isključivo putem HTTPSa. Dakle, vaša komunikacija sa serverom, koja se koristi za slanje vašeg korisničkog imena i šifre, zaštićena je SSLom, i tako treba biti, sve OK. Posljedica logovanja je ostavljanje cookia (koji je sa servera dopremljen sigurnom vezom) sa podacima vaše upravo otvorene sesije na vašem kompjuteru. I dalje sve OK. A onda vas site prebaci na običan HTTP, da bi nastavio sesiju browser serveru šalje cookie, ovaj put nezaštićen nekim enkripcijskim protokolom. Ukoliko se sve to odvija putem nešifrovane (u našem slučaju bežične, ali ne mora biti samo bežična) mreže, doista je trivijalno presresti cookie, iskopirati ga i kasnije iskoristiti. Ono što FireSheep radi je trivijaliziranje procedure prepoznavanja i presretanje cookiea i njegove upotrebe. Međutim, napadaču koji koristi FireSheep naša šifra ostat će nepoznata (bar nešto).

Za session hijacking kojih sve Internet usluga se FireSheep može koristiti? Popis je podug, inicijalno su podržani: Amazon, Basecamp, bit.ly, eNom, Facebook, Foursquare, GitHub, Google, Hacker News, Harvest, The New York Times, Pivotal Tracker, Twitter, ToorCon, Evernote, Dropbox, Windows Live, Cisco, Slicehost, Gowalla i Flickr. Kasnije su najavljeni i: Yahoo!, eBay, LinkedIn, Digg, Reddit, Wikipedia, Blogger, GoDaddy, Posterous, Tumblr, Netflix, YouTube, Slashdot, MobileMe, PayPal, Salesforce, Craigslist, MySpace, Match i AOL, ali nisam siguran jesu li i implementirani. Imajte na umu da svi pobrojani siteovi nisu jednako izloženi, ovisno o drugim mjerama zaštite koje koriste.

Dakle, FireSheep ‘snifa’, osluškuje promet na bežičnoj mreži i traži cookie. Kada neki pronađe, prikazuje to u zasebnom sidebaru Firefoxa odakle se jednim dvoklikom može na dati site ‘ulogati’ (tj. nastaviti sesija) nesretnog korisnika – žrtve. Jednostavno da jednostavnije ne može biti.

Legalnost?

FireSheep bi mogli usporediti sa vatrenim oružjem. Dok njegovo posjedovanje može biti legalno, njegova upotreba (npr. pucanje po drugima) to svakako nije. Dakle, legalno je posjedovati, čak i aktivirati FireSheep, no iskoristiti ga za session hijacking nečijeg korisničkog računa nije. Obzirom da se informacije koje FireSheep presreće javno emitiraju, i onaj koji ih emitira mora snositi neku odgovornost.

Što se tiče Mozille, oni su oficijelnog stava da FireSheep nije problem, niti propust Firefoxa (što je činjenica), već je to problem web siteova koji ne koriste HTTPS za prijenos cookiea.

Prevencija?

Jedna od mogućnosti koje nam stoje na raspolaganju, kad je prevencija session hijackinga putem FireSheepa u pitanju, je VPN (Virtual Private Network). Iako VPN svakako nudi najveći nivo sigurnosti (ne samo na ovom polju; svako lokalno prisluškivanje je anulirano, bilo bežično ili ne), relativno ga je komplicirano implementirati u kućnoj radinosti (treba znanja, ali i hardverskih i infrastrukturalnih predispozicija), a u nekim verzijama može i koštati, stoga ću se orijentirati na prosječnom korisniku dostupnije opcije.

Neko će spomenuti BlackSheep kao alat za ‘borbu’ protiv FireSheepa, ali baš kao što je sam FireSheep manifestacija suštinskog problema, tako je BlackSheep reakcija na postojanje FireSheepa. Sam BlackSheep ne rješava ništa, samo vas upozorava ukoliko neko u vašoj mreži koristi FireSheep. Bolje nego ništa, no ovim sam problem nije riješen.

Još jedan Firefox plugin koji se nudi kao rješenje za nastali problem je HTTPS Everywhere. Ideja ovog plugina je vrlo jednostavna: forsira korištenje HTTPSa gdje je god to moguće. Problem je u tome što se HTTPS ne može koristiti baš svugdje, tj. sve stranice ga ne podržavaju (jer neke ga ni ne trebaju), tako da je HTTPS Everywhere potrebno podešavati za svaki site posebno. Podržani su: Google Search, Wikipedia, Twitter, Facebook, bit.ly, GMX, WordPress.com blogovi, The New York Times, The Washington Post, PayPal, EFF, Tor, Ixquick i još neki siteovi. Tu je i Force-TLS plugin koji radi identičnu stvar (podržava STS), a slična rješenja postoje i za druge browsere (listu pogledajte ovdje). HTTPS Everywhere je svakako preporučljivo koristiti (npr. natjerat će veći dio facebooka da radi preko HTTPSa), ali ni ovo nije univerzalno rješenje.

WPA enkripcija bežične mreže je sigurno najjednostavnije rješenje koje može zadovoljiti, mada nije idealno. Svejedno je li WPA ili WPA2, u oba slučaja postoji međusobna izolacija klijenata (za borbu protiv FireSheepa poslužit će i prevaziđeni WEP jer FireSheep se oslanja na činjenicu da enkripcije uopće nema, ali WEP sam po sebi ne nudi međusobnu izolaciju klijenata). Šifra mreže može biti jednostavna, može biti poznata svima, lako pamtiva, svejedno, samo da je ima. Enkripcija komunikacije između klijenta i pristupne tačke efektivno onemogućava funkcioniranje alata kakav je FireSheep. Možemo diskutirati o tome kako je na PSK mrežama moguće presresti PTK za odvijanja ‘handshake’ procedure, no ovo opet zalazi u neke hakerske vode obzirom da je operaciju ipak nešto teže izvesti.

Jedino pravo rješenje, rješenje koje bi u potpunosti riješilo problem session hijackinga (bar na ovom nivou), je potpuna implementacija HTTPSa. Već neko vrijeme postoji incijativa za implementaciju STSa (Strict Transpot Security), što je ništa drugo do forsiranje HTTPSa. Posljednje verzije browsera će podržavati / već podržavaju STS (npr. Firefox 4 će STS podržavati out of the box), no problem je sa serverske strane. Poznato je da je PayPal jedan od onih koji su rano prihvatili STS, tako da PayPal nije ranjiv na session hijacking FireSheep oblika.

Na žalost, implementacija STSa nije nimalo trivijalna, ali na primjeru Googlea se vidi da je itekako moguća (Gmailu i Google Docsu se može pristupiti isključivo putem HTTPSa). Svi su izgledi da prelazak na potpunu SSL uslugu nije nimalo trivijalan, čim se jednom facebooku na dan objave ovog teksta i dalje pristupa putem ‘običnog’ HTTPa. Nekada davno-davno (prije 10ak i više godina), SSL se izbjegavao jer je, naprosto, bio procesorski zahtjevan. No današnji procesori su daleko moćniji nego nekad, i mada korisnika ima daleko više nego tada, bez problema se mogu nositi sa svim SSLom izazvanim opterećenjima. Danas su i sami protokoli su napredniji (npr. moguće je nastaviti SSL/TLS sesiju, dok to prije nije bio slučaj – najveće opterećenje izaziva inicijalni handshake koji se ovako izbjegava). Osim toga, već sada se koristi SSL za logovanje, tako da se ovaj ‘naporni’ dio posla obavlja i danas, samo što nas se nakon logovanja putem HTTPSa vraća u ‘nesigurni’ HTTP. Dakle, opterećenje nije razlog neimplementiranja HTTPSa na svakom koraku. Kako je to u blog postu lijepo sročio jedan od Googleovih inžinjera zaslužan za migraciju Gmaila na puni HTTPS:

If there’s one point that we want to communicate to the world, it’s that SSL/TLS is not computationally expensive anymore. Ten years ago it might have been true, but it’s just not the case anymore. You, too, can afford to enable HTTPS for your users. In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this, we had to deploy no additional machines and no special hardware.

….

If you stop reading now, you only need to remember one thing: SSL/TLS is not computationally expensive anymore.

Naravno, HTTPS se ne mora koristiti baš svugdje, osim toga, nisu ni svi podaci povjerljivi (npr. dijelovi intefejsa web stranica su javni i jednaki za sve). Problem je što se HTTP i HTTPS ne miješaju dobro, zbog prirode osjetljivosti HTTPSa browseri upozoravaju korisnike ukoliko je sadržaj na stranici koju pregledavaju dobavljen miješano, i HTTPom i HTTPSom. Ovo naravno može dovesti do zbrke i zbunjivanja korisnika, ali i otvoriti prostor za neke buduće zlouporabe, pa se stoga ovaj pristup ni ne koristi.

Problem koji se ispriječio gigantima poput facebooka pri uvođenju potpune SSL usluge svakako je njihova kompleksna arhitektura. Naime, npr. facebook, ili bilo koji Internet gigant danas koristi nešto što se zove CDN – Content Distribution Network. Facebook nije jedan ogroman server negdje u Americi, nije čak ni gomila servera na jednom mjestu, prije će biti da je Facebook zapravo nekoliko gomila servera razasutih po cijelom svijetu. Kada pristupate facebook serveru, naravno da koristite jednu adresu, ali vas facebookov CDN sistem upućuje na server koji je vama geografski najbliži, najmanje opterećen u datom trenutku itd., sve samo da bi usluga bila što brža i komfornija. CDN se u pozadini brine za koherentnost podataka (odnosno kako je već realizirano). Problem koji će prebacivanje na SSL izazvati za npr. facebook je ograničenje koje SSL nameće, a to je ograničeno keširanje. Implementacija varira od browsera do browsera, ali ima situacija kada SSL sadržaj browser smije keširati samo za vrijeme sesije, nakon njenog završetka keširani sadržaj se briše. U slučaju nastavljanja sesije, sav sadržaj se mora ponovno dovući sa servera. Ovo uključuje npr. dijelove intefejsa i slično, stvari za koje se računa da su u pravilu keširane na kompjuteru klijenta, što može znatno povećati promet i opterećenje, time i troškove. Osim toga, tu su i nemali troškovi izdavanja velikog broja certifikata, obzirom da sadržaj sa CDNa često dolazi sa efektivno različitih domena (SSL certifikat u pravilu vrijedi isključivo za jednu domenu). Da bi se sadržaj koji dolazi putem CDNa stavio pod prividno zajedničku domenu, što odmah znači i manji broj nimalo jeftinih certifikata, kompletan CDN se mora redizajnirati, što je težak, kompleksan, a i nimalo jeftin zadatak. Dakako, nemam pojma kako npr. facebook doista radi, ovo je samo nagađanje, ali vjerovatno je blizu istini.

Ukratko; da bi se zaštitili od session hijackinga FireSheep tipa, moraju se implementirati dvije stvari:

1. enkripcija bežičnih mreža (WiFi) korištenjem WPA protokola;
2. pristupanje Internet uslugama isključivo putem SSL šifrovanih veza.

Sve ovo se moglo implementirati još davno-davno, samo su nas incercija i lijenost doveli do trenutne situacije.

Šta se FireSheepom postiglo?

Kao što sam već nekoliko puta naglasio, FireSheep nije problem; FireSheep problem potencira i čini njegovu eksploataciju trivijalnom. Ono što je ovaj Firefox plugin postigao je skretanje pažnje na problem nekorištenja SSLa tamo gdje je potreban i probleme koji mogu nastati korištenjem otvorenih bežičnih mreža.

FireSheep jednostavnošću svoje upotrebe, u ma kako maliciozne svrhe, tjera pružatelje usluga na Internetu da napokon implementiraju SSL zaštitu koja je jedina prava zaštita od session hijackinga. Sasvim je sigurno da je pažnja koju je priča o FireSheepu privukla natjerala facebook, Amazon, Twitter i ostale “velikane” nesigurnog weba da se napokon pokrenu ka implementaciji sigurnog i potpunog SSL pristupa svojim sadržajima. Prvi koji je reagirao na FireSheep bio je Microsoft, njihova hotmail usluga već neko vrijeme nudi opciju pristupa isključivo putem SSLa.

Ne postoji jača sila od kritične mase nezadovoljnih korisnika: ili joj se povinuje ili se nestaje. Samo je nemar doveo do situacije da kritična masa nezadovoljnih korisnika ujedno bude i kritična masa nasamarenih, prevarenih ili na neki drugi način oštećenih korisnika. Za nadati se da je FireSheep napokon uspio promijeniti Internet – na bolje.

NAPOMENA: molim vas ne pristupajte svom email accountu sa javne mreže, ukoliko veza nije sigurna (zaštićena SSL/TLSom). Iako vam u ovom sluaju FireSheep ne može nauditi, doći do vašeg korisničkog imena i šifre i dalje je trivijalno. Provjerite postavke svog email klijenta, a ako treba i promijenite ih kako bi koristili sigurne veze. Ako vaš provider ne nudi SSL/TLS POP3/SMTP/IMAP pristup, pa, vrijeme je da potražite novog providera. Isto vrijedi i za webmail. Molim vas budite oprezni, vani, u divljini, ima svega.

Slike:

• naslovna: Pecado y Firesheep by tian 2992
• An Extra Offering by treehouse 1977

NAPOMENA: par dana nakon objave ovo posta facebook je objavio kako će svim korisnicima na raspolaganju biti opcija pristupa facebooku isključivo putem HTTPSa.

Slični postovi:

• facebook HTTPS podrška nije baš idealna
• Facebook Notes RSS Import fail
• Privatnost na Internetu
• Špijuni su među nama – third-party tracking skriven u WordPress pluginu
• Optimizacija WordPress bloga: SEO i meta tagovi