Add-on pro Firefox odchytává cizí session-ID přes WiFi

PcWorld.com píše o zajímavém add-onu pro Firefox, který uživatelům umožňuje odchytávat session-ID přes nešifrované WiFi. Pro návštěvníky klubů a barů s nabídkou nešifrovaného WiFi připojení to může být velmi nepříjemná zpráva. Add-on je přednastaven pro nejpopulárnější stránky jako je Facebook, Yahoo apod. Po odchycení session-ID je možno jednoduše oklamat server a používat danou službu zcela neomezeně jako majitel účtu, tedy např. psát příspěvky na Facebook, odesílat e-maily a podobně. V jiném článku se píše o jedné z možností ochrany.

16.11.2010 21:12 | Amarok | Zajímavý software

Komentáře

[Jary]

Článek jsem nečetl, ale jistě bude stačit se po facebookování v kavárně od FB odhlásit. Session ID se tím určitě zinvalidní.

[Jendа]

Pokud nebude správce kavárny rychlejší a nestihne to zneužít už během sezení.

Ale v kavárně je zbytečné sniffovat provoz, když tam rovnou můžeš dát keylogger.

[Jiří J.]

To už tu bylo před asi měsícem, ne?

[Amarok]

Pokud ano, tak pardon, zkousel jsem vyhledavani, aby se to nestalo a podobnou zpravu jsem nenasel.

[Let_Me_Be]

Boze, na to mi staci transparentni proxy. Naco instalovat nejaky add-on do firefoxu?

[Jendа]

Ve skutečnosti stačí jenom pasivně poslouchat a pak si session naklonovat.

Cílem projektu AFAIK ale bylo ukázat, že odposlouchávání WiFi sítí není jen doménou „elitních“ hackerů s nebezpečným OS GNU/Linuxem a teroristickými programy Kismet a tcpdump a upozornit tak lidi, že HTTPS se opravdu vyplatí.

[Amarok]

Presne tak, to je plugin pro normalni lidi, kterym se problematika ma nazorne ukazat pomoci programu, ktery vetsina lidi zna a pouziva (FF).

[Ash]

Když už mám shell na serveru ve vlastní síti, tak tam rozhodně nebudu kopírovat nějakou http proxy vhodnou tak leda pro browser ale udělám si tam rovnou vpnku a je to.

[Jendа]

Nebo používat HTTPS… Třeba Facebook ho má, ale musí se tomu trochu pomoct (HTTPS-Everywhere od EFF). Stejně tak AbcLinuxu.

[Jaromír Svoboda]

Nebo používat HTTPS… Třeba Facebook ho má

Jde v https připojeným facebooku chat na stránce? Mě ne, dole místo lišty s chatem je ikona výstražného trojúhelníku s popiskem "Chat není na této stránce povolen.", jinak v http verzi chat je funkční. Nefunkčnost chatu na stránce mi ale nevadí, mám na to v Pidginu XMPP účet facebooku s luxusem libnotify a lokální historií

[Jendа]

Tak to netuším, FB nepoužívám. Jenom vím, že tam HTTPS šlo takhle zapnout.

[Jaromír Svoboda]

Tak už jsem zjistil, že nefunkční chat na FB v HTTPS verzi je známá chyba při používání doplňku HTTPS-Everywhere od EFF, píše se o tom na stránkách EFF ohledně 0.9.x verze doplňku. https://www.eff.org/https-everywhere
Čeká se na to, až to FB opraví.

[ElPraga]

Hm, ja treba mam shell na jednom stroji, ale VPN si tam asi nerozjedu. Me se to docela hodi..

[trekker.dk]

V jiném článku se píše o jedné z možností ochrany.

Základní možnost ochrany: pokud server neumožňuje SSL, nebudu se tam přihlašovat v internetové kavárně (nebo pravděpodobněji: nebudu se tam přihlašovat vůbec)

[Filip Jirsák]

Ono by úplně stačilo používat HTTP DIGEST autentizaci přes HTTP. Jenže to je moc jednoduché a účinné, takže nikdo z výrobců HTTP serverů i klientů nemá potřebu to implementovat dobře a uživatelsky přívětivě.

[Libor Chocholaty]

Coze? Mel jsem za to, ze tahle zakladni vec je normalne funkcni. Nikdy jsem se teda HTTP_DIGEST na apachi pouzit, ale ... vazne ne?

[Filip Jirsák]

Používal jsem HTTP DIGEST se serverem Jetty, a žádný problém jsem nezaznamenal. Pak server přešel na Apache, a na některých počítačích jsou problémy s MSIE. Těžko ale říct, v čem je problém. Já jsem zaznamenal, že MSIE se zeptá na heslo a pak HTTP hlavičku nepošle, ale v jiných případech mohl být problém v něčem jiném – tenkrát jsem se o problému na jiném počítači jen dozvěděl, dělo se to prý opakovaně, ale když jsem to chtěl zkoumat, spravilo se to samo. Další problém je v tom, jakým způsobem prohlížeče prezentují přihlašovací okno, často třeba chybí odlišení toho, co posílá server (a co by si měl uživatel kontrolovat), je to všechno nasypané do jedné věty. Snad ve všech prohlížečích pak chybí možnost odhlášení. Prostě je na tom vidět, že je to sice ve standardu, každý to nějak implementuje, aby si mohl udělat čárku, ale ve skutečnosti nikoho nezajímá, jestli to funguje a je to použitelné.

[Jirka]

Takze v kolik je ten sraz na ruzynskem letisti?

[Jakub Suchy]

Free wifi na ruzynskem letisti pro jistotu blokuje port 443, takze o to to bude jednodussi :) (Funguje tam pouze port 80, ani maily si clovek nestahne).

[vlastikroot]

By mě zajímalo, kterýho debila to napadlo

[petr_p]

Na letišti se ve dne v noci bojuje za mír^w^wproti terorismu: šifrování používají teroristi → na letišti je třeba jej zakázat.

[Jendа]

A pak objevili GNU httptunnel.

[gtz]

Pokud mají dokonalý FW což myslím mají, pak to odmítne spojení. Pokud mají něco jako je Fortinet Firewall/Gate pak je to celkem na nic. Ty mašiny dokáží celkem hodně sofistikovaně prolézat protokoly a vše ostatní. Jak mi říkal známý i ICQ, který forwardoval přes 80 tak tam nechodilo.

[Jendа]

Ale ten HTTP tunnel by měl vypadat jako kdyby někdo lezl po webu a vyplňoval do formulářů různá data. Jediný rozdíl je ve kvantitě.

[SPM]

Ale ten HTTP tunnel by měl vypadat jako kdyby někdo lezl po webu a vyplňoval do formulářů různá data. Jediný rozdíl je ve kvantitě.

No, on takový html formulář s vyplněnými hlavičkami ostatních protokolů je také dost podezřelý :)

[Mrkva]

Tak ono není problém tohle pak případně šifrovat, že..

[SPM]

To sice ne, nicméně vememe-li v úvahu, že máme wifi hotspot pro BFU, tak rozpoznat od sebe HTML stránky s textem a HTTP posty plné nesmyslného balastu nebude pořád až tak moc těžké... prostě ve chvíli kdy ten fw začne koukat i dovnitř, tají se to podstatně hůře...

[gtz]

a ty mašiny se dívají hodně dovnitř. Dokáží i takové prasárny jako číst IM komunikaci bez problémů.

[AsciiWolf]

lol

[xurfa]

No, stejně nechápu jednu věc a sice, proč naprostá většina webů nemění "session-id" po každém kliknutí?

[Jary]

Nevim. Kvůli tlačítku Zpět? Když se stiskne Zpět, tak se imho pošle úplně stejný požadavek, jako před chvílí. Se starým SID by mě to vyhodilo.

Navíc, proč to dělat? Čemu to pomůže?

[Blut]

Pokud mas napriklad session ID v odkazech, nemuzes odkaz otevrit v dalsim okne/tabu a pokracovat dal v puvodnim (popr. dve a vice dalsich oken/tabu), protoze v tu chvili uz bys odesilal neplatne session ID, coz jde ponekud proti smyslu hypertextu.

Samozrejme, session ID v URL je trosku problematicke, protoze se muze s referrerem dostat ven, ale session ID v cookies take, i kdyz opacnym zpusobem; muze se dostat dovnitr s podvrzenym linkem, napriklad kdyz nekdo na foru postne obrazek a jako src uvede link na logout.

Navic, dynamicke session ID ti moc nepomuze, slidil by mohl stejne dobre odchytit session ID z odezvy serveru (tj. platne) jako z zadosti (tj. uz neplatne). Jen si vsimnes, kdyz ho zacne pouzivat (odlogne te).

[pavlix]

No, stejně nechápu jednu věc a sice, proč naprostá většina webů nemění "session-id" po každém kliknutí?

Spoustu věcí by to rozbilo, například prohlížení v tabech.

[Zdeněk]

Inu, tohle až se dostane na Lupu, Živě a dál do vod pubescentní mládeže (už dostatečně obeznámené s instalací doplňku do firefoxu), to bude divočina:).

Toga - Nakreslete si Hitlera

[Matlák]

Tohle je známý problém. Zvláště úsměvné je to v případě facebooku, který nechává většina uživatelů laptopů přihlášený neustále, čili session ID je stále platné...

Ten addon jsem nezkoušel, nedávno kolem něj byl velký humbuk ale to ještě neexistovala verze pro linux. Ovšem například wireshark a pokročilý editor cookies ve FF dokáže to samé, a jako bonus je možné odchytit opravdu jakoukoli službu, ne jen tu kterou firesheep zná... hrál jsem si s tím už dávno..

[Matlák]

jinak je jasné, že hlavní problém v tomto případě je IPv4/NAT prostě server nemůže rozlišovat podle IP... já osobně už celá léta (po tom co jsem si tyhle "vychytávky" vyzkoušel ve školních WiFi sítích) používám minimálně dynamický SSH tunel či (častěji) rovnou VPN.

[Filip Jirsák]

Podle IP by server neměl rozlišovat nikdy, IP adresa se může měnit. Hlavní problém je, že se pro autentizaci používají cookie, když přitom protokol HTTP má definovánu bezpečnou metodu autentizace (HTTP DIGEST).

[trekker.dk]

Podle IP by server neměl rozlišovat nikdy, IP adresa se může měnit.

Tak teoreticky se ta IP nebude měnit tak často, takže když se právoplatný uživatel bude muset přihlásit při změně, nebude to pro něj tak velká zátěž. Čistě prakticky tu máme GPRS a spol., kde se IP mění dokonce snad podle toho, s jakou BTS si telefon povídá (jistě to nevim, ale rozhodně se mění často)

Hlavní problém je, že se pro autentizaci používají cookie, když přitom protokol HTTP má definovánu bezpečnou metodu autentizace (HTTP DIGEST).

Protokol HTTP se dá zašifrovat pomocí SSL a kdyby lidi nezdržovali s přechodem na IPv6, nebylo by potřeba řešit nic jiného.

[Jendа]

Tak teoreticky se ta IP nebude měnit tak často, takže když se právoplatný uživatel bude muset přihlásit při změně, nebude to pro něj tak velká zátěž. Čistě prakticky tu máme GPRS a spol., kde se IP mění dokonce snad podle toho, s jakou BTS si telefon povídá (jistě to nevim, ale rozhodně se mění často)

Tak BTS se může při pohybu v autobuse nebo vlaku měnit třeba každou půlminutu. Ale podle mě když už se mění, tak by se měla měnit s opuštěním svazku buněk řízených jedním BSC, ale o GSM toho zas tak moc nevím. Nicméně i tak to může být klidně každých pět minut. Takže proč znepříjemňovat uživateli život, když je efekt na bezpečnost nulový? To je jak s těmi aplikačními firewally, změnou hesla každé dva měsíce nebo zakazováním přihlášení na roota - když to tak otravuje, tak to určitě musí zvyšovat bezpečnost, ne snad?

[Jendа]

Ještě k tomu IPv6 - nemyslím si, že by třeba Facebook nebo Seznam e-mail běžely na sdílené IP(v4) s jinými weby. Přesto se muselo (nevím, jak teď) HTTPS explicitně vynutit.

A ani u sdílených hostingů na té jedné IP podle mě dost často neběží ani alespoň ten jeden HTTPS host. Jestli to nebude spíš o lenosti než o nedostatku IP…

[SPM]

Ono s SSL je to také trochu těžké... autority, které své certifikáty už protlačili alespoň někam, z toho mají dobrý byznys a každý přiblblý certifikát stojí fúru peněz... pravda, u věcí jako seznam nebo facebook je to šumák, u menších webů už zase tolik ne... jak mi tak přišlo, tak dobrý byznys z toho mají i autoři sw, co to používá, takže takové protlačení cacertu taky není úplně jednoduché. No a když se použije certifikát, jehož CA není přítomno v systému uživatele? Většina se pak na nějaký import CA (natož nějaké další ověřování) vykašle a přidá si výjimku... čímž se celý bezpečnostní efekt SSL ztrácí...

[Jendа]

Tak třeba StartCom už má své certifikáty leckde.

Nicméně přijde mi lepší šifrovat i v případě, kdy nemůžeme ověřit identitu druhé strany. MitM útok je přeci jen složitější než prostý odposlech a oběť se o tom po skončení útoku alespoň dozví.

[Filip Jirsák]

Proč by se o tom oběť měla dozvědět? Do porovnávání složitosti MitM útoku a odposlechu bych se taky nepouštěl, záleží na okolnostech. Pro odposlech potřebujete přístup k trase mezi obětí a původním serverem (třeba zachycení WiFi komunikace), MitM můžete udělat třeba posláním falešné DNS odpovědi, což můžete udělat z druhého konce světa. Takže by se dalo říct i to, že MitM je jednodušší než odposlech…

[Jendа]

Proč by se o tom oběť měla dozvědět?

Protože jí prohlížeč zařve, že se změnil certifikát protistrany, ne?

[vlastikroot]

Jako by někdo ty certifikáty řešil Většinou to lidi odkliknou a neřešej.

[Filip Jirsák]

Prohlížeč neřeší změnu certifikátu. Zkoumá jenom to, zda certifikát podepsala některá z autorit, které má v seznamu důvěryhodných.

[SPM]

Řekl bych že řeší... tedy ve chvíli, kdy CA pro certifikát není dostupný a uživatel odklikne tu výjimku, tak si to pamatuje jen ten konkrétní certifikát a na změnu to přijde...

[Filip Jirsák]

Záleží na prohlížeči. Každopádně pokud uživatel potvrdí důvěryhodnost nějakého pochybného certifikátu, je problém především v tom. Myslím, že pak klidně odklikne i hlášku o tom, že se certifikát změnil.

[Filip Jirsák]

Prakticky se ta IP adresa může měnit s každým spojením, takže se uživatel ani nepřihlásí. Kontrola IP adresy je typický příklad chybného zabezpečení – útočníkovi to v ničem nezabrání, jenom to otravuje uživatele.

[Jendа]

A že si s tou IP fakt pomůže… Uživatele by to akorát štvalo při cestování mezi sítěmi a útočník si po odpojení uživatele jeho adresu klidně nastaví.

[Matlák]

jo, to je fakt.. mnohem lepším řešením by byl zmiňovaný http/digest nebo rovnou ssl. Spíš jsem myslel to že z pohledu serveru je útočník na wifi a oběť jeden stroj- není možné určit ze kterého stroje byla autentizace heslem provedena (pokud vůbec byla, pravda, uživatelé jsou líní se odhlašovat a přihlašovat)

[imploder]

Není zatím verze pro Linux. Není náhodou potřeba na to pustit Firefox s právama adminitrátora (kvůli libpcap)? Nicméně zprávička je to zajímavá. Je dobré vědět, že odteď mi kdejaká lama může pohodlně krást nešifrované sessiony.