Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Moxie és az SSL

2009.02.19. 22:45 | buherator | 11 komment

Nos dióhéjban nézzük, miről is beszél Moxie Marlinspike:

Tanúsítvány láncolás

A PKI rendszerek bizonyos szint fölött definíció szerint a bizalmon alapulnak. Bár egy weboldal tanústványát kiállító entitásról általában egy másik hitelesítő intézmény kezeskedik, a lánc végén mindig ott a "Root CA" (gyökér hitelesítő hatóság), akiben kénytelenek vagyunk (technológiai értelemben) vakon megbízni.

Moxie mondja: csinálj egy köztes CA-t, és adj ki vele tanúsítványokat minden féle zsiványnak! A gézengúz tanúsító tanusítványai azonban visszavonhatók. Károk persze keletkeznek, de a világ nem dől össze.

Kesze-kusza böngészők

 Egy átlag felhasználó számára nem azonnal szembeötlő, hogy mikor jár hitelesített oldalon, a sok hamis riasztás pedig rossz reflexeket nevel az emberekbe (Igen, Akarom, Tényleg, Biztosan mantra...). Itt tényleg van merre előrelépni, de megint nincs szó a rendszer alapjainak döntögetéséről, ez egyszerű interfészfejlesztés. Ráadásul a jobb bankok kiterjesztett érvényességű tanúsítványai még mindig elég hivalkodóak szerencsére.

Senki nem írja le az s-t 

Mármint a http végére. Mert hogy még http://-vel is csak viszonylag kevesen kezdik az URL-jeik beírását. Így a forgalom először nem biztonságos csatornán indul el, ebbe pedig be lehet avatkozni, és még mielőtt az áldozat békés vizekre jutna, be lehet rántani az örvénybe. Persze a marhákat is igyekeznek megnyugtatni, mielőtt a vágóhídra küldik őket: az elcsent adatfolyamba beteszünk pár képet lakatokról, és mindenki a legnagyobb nyugalommal kürtöli szét az adatait a hálózatba.

De itt sem a HTTPS kapcsolatba ékelődtünk be, hanem a köztudottan védtelen HTTP-be. 

Szeretünk Unicode

Erről már volt szó. Moxie most azzal egészítette ki a dolgot, hogy mi van akkor, ha tetszőleges domain alá olyan aldomaint regisztrálunk, ami látszólag megegyezik a biztonságosnak hitt oldal megszokott URI-jával. Konkrétabban: pl. ha az aldomain a / és ? karakterekhez megtévesztésig hasonló Unicode karaktereket tartalmaz, elhitethejük, hogy a látogató jó helyen jár, miközben csak az aldomain hosszú-hosszú nevét látja, a valódi hoszt pedig elveszik a látszólagos paraméterek között, vagy már ki is lóg a címsor látható részéből.

Ez persze jó eleme lehet egy támadásnak, de az SSL-hez megint semmi köze.

Nagyjából ezek voltak az előadás fő pontjai. Ezek a támadások tényleg igen veszélyesek lehetnek az átlag felhasználók számára. és minden bizonnyal a rengeteg megszerzett belépési adatról sem füllentett a srác. De a problémák kezelésének nem tesz jót, ha az amúgy sem túl jó marketinggel rendelkező, de még mindig az e-kereskedelem masszív bástyájának tekinthető SSL-ről elkezdünk hülyeségeket beszélni.

Frissítés:

A "kísérletben használt" sslstrip program letölthető innen.

Címkék: ssl blackhat moxie marlinspike

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

M@rine 2009.02.20. 12:10:41

Egyetertek, tenyleg hatasvadasz az indexes cikk.

Ujdonsag nem kerult napvilagra, ez a fishing jellegu tamadas eddig is ismert elemekbol lett osszevaogatva...

Kockazat kezelere tippek:

- mindig meg kell nezni hogy mihez kapcsolodunk: https? url stimmel (teljes, nem csak ami latszik)?

- levelben jott linkeket NE nyissunk meg, meg akkor se ha ismert oldal neveben kuldik. (felado ugye tetszolegesen hamisithato)

- ha https oldalra akarunk menni, irjuk be kezzel, vagy bookmark. utobbi ellen lehet erv hogy a bongeszok idokozonkent serulkenyek lehetnek bookmark atirasra. noha kicsi a valoszinusege hogy pont a mi kedvenc bakunkat hamisitjak.... paranoidok tegyek el txt fileba a https linkeket - elkerulendo az elgepeles.

Egyebkent a masik root ca altal kiadott tanusitvanyok ellen jo lenne ha lehetne a browserral megjegyeztetni a mar latott tanusitvanyokat. Igy ha egyszercsak masik CA irja ala akkor tudna jelezni.

Erre esetleg van valami lehetoseg? En nem tudok ilyenrol.

Udv, Marine

r@ek (törölt) 2009.02.20. 14:46:32

Szamomra az a megdobbento, igy meg egyszer atfutva, hogy ezzel BlackHat.-en eloadast lehet tartani...

|Z| 2009.02.21. 16:32:23

Nekem van pár ff kiegészítőm/beállításom, ami némiképp segít az ilyen turpisságok ellen:

browser.identity.ssl_domain_display kulcs értéke 1
LocationBar - kiemeli a domain-t
SSL Blacklist - A gagyi tanusítványok ellen véd
Cipherfox - megmutatja az aktuális SSL rejtjelezést
Flagfox - ellenőrzi, hogy a domain és az IP cím tényleg azonos országban vannak-e

mindennapi böngészésben segítenek, lusta vagyok megnézni minden alkalommal a tanusítvány ujjlenyomatát...

kutyacica 2009.02.21. 18:30:01

Az ssl blacklist valóban hasznos... jut eszembe említettem már h van olyan BANK az usában aminek még mind md5-el hashelt a tanúsítványa? (wachovia) Különösen kellemes ha ez az ember bankja :)

Nem kevésbé bosszantó a belépési rendszer (a login oldal ahonnan elposztolod buttonnal a jelszavad még http) - ami h h nem ebben az előadásban is felbukkan. És ez egy bank.

Amúgy élmény velük levelezni, az ugyanis a policy h kizárólag a webes felületen belülről elküldött secure mailen keresztül hajlandókat ilyen témáról írni-olvasni (ennyi volt praktikusan a válasz az első érdeklődő mailemre). Nem tudom lehet-e érezni az ellentmondást ebben :)

sebcsaba 2009.02.21. 19:20:06

Szerintem olyan FF-plugin kellene (lehet hogy van is...) ami a https kapcsolatot veszi előre és azon próbálkozik, és a plain http lenne a fallback.

A megtévesztő címek ellen meg jól tud jönni a Chrome domainnév-kiemelése.

synapse · http://www.synsecblog.com 2009.02.22. 15:05:32

"Szamomra az a megdobbento, igy meg egyszer atfutva, hogy ezzel BlackHat.-en eloadast lehet tartani... "

Es mennnyire kurvara igazad van!!!

synapse

Hunger 2009.02.22. 16:45:42

Megy mindenhol az arcolás, hogy ebben nincs semmi extra, meg hogy béna aki nem veszi észre ezt és hasonlók, csak egy valamit felejt el mindenki... Moxie ezt a műsorát egy Tor exit node-on vitte véghez. Tor-t általában nem műszaki analfabéták használják és ha egy raklap jelszót és bankkártyaszámot tudott így szerezni, ráadásul úgy, hogy senki se fogott gyanút, akkor az jól mutatja, hogy a dolog mennyire működik és megspékelve a tavalyi BGP hijacking mutatvánnyal nagy számban lehet komoly információkhoz jutni, különösebb feltűnés nélkül.

Szóval szerintem van pár Tor user, aki szintén nagyban döngeti a mellét, hogy ő ezt tutira észrevenné, aztán közben meg már Moxie-nál vannak az adatai. ;)

r@ek (törölt) 2009.02.22. 23:48:30

@Hunger:

czarism.com/tor-vs-security-sniffing-exit-nodes


GET SOME!!


www.youtube.com/watch?v=S06nIz4scvI


p.s.: A videoban lathato tevekenyseget maximalisan elitelem, csak szemlelteto eszkozkent szerettem volna hasznalni, hogy kb ennyi egy exit node-on jelszavakat halaszni..

Hunger 2009.02.23. 22:06:28

@fiveeeee: Nekem nem kell bemutatni a tor sniffing témát, sok évvel ezelőtt szórakoztunk vele, amikor még nem volt visszhangja a médiában. Ez a módszer viszont az összes olyan account megszerzésénél is működik, ahol a POST data eredetileg már https csatornában menne, tehát a sima sniffeléssel nem szerezhetők meg az adatok, viszont a login képernyő (vagy akár csak a https redirect) még http-n jön...

Nem kell itt nagyon feltűnő jelenségre gondolni és nincs szükség legtöbbször mindenféle unicode trükközésre sem. A post data url-t elég átírni egy saját url-re (ahogy Moxie is írta, remekül nem látszik se a böngészők status sorában se máshol, hogy hova lesz elküldve az adat, max. a forrásból lehetne kibányászni a címet), aztán a beérkező adatokat loggolni és utána akár továbbítani is lehet a valódi https oldalra az egészet, onnantól akár kommunikálhat titkosítottan is a szerver meg a kliens, kit érdekel, megvan a user/pass... 100-ból 100 felhasználó ebből nem vesz észre semmit, az tuti.

Hunger 2009.02.24. 00:51:12

Ja! És a Youtube linkre nekem egy Full Metal Jacket részlet jön be, biztos, hogy ezt akartad linkelni? :)