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

Szörfös János, aki átlát a HTTPS-en

2008.08.11. 21:40 | buherator | 4 komment

Legtöbbször nyugodtan vehetjük tudomásul, hogy fontos és bizalmas adatainkat nyilvános helyről ma már legtöbbször titkosított csatornán keresztül érhetjük el. Sandro Gauci azonban elrontja a kedvünket:

  • Az áldozat belép egy biztonságos oldalra, pl. https://somesecurebank.com
  • A biztonságos oldal küld egy sütit az áldozatnak, ami tartalmazza  a munkamenet-azonosítót
  • Mialatt belépett, az áldozat meglátogat egy másik oldalt egy másik fülön, pl. a http://www.example.com-ot
  • A támadó, a hálózatot figyelve látja az áldozat kapcsolatát a www.example.com-felé (pl. WLAN, ARP mérgezés, stb.)
  • A támadó küld egy választ az example.com nevében, melyben a 301-es HTTP kóddal elirányítja az áldozatot a http://somesecurebank.com-ra, ami már egy titkosítatlan kapcsolatot jelöl.
  • Az áldozat böngészője szépen elküldi a somesecurebank.com-hoz tartozó munkamenet-azonosítót a titkosítatlan csatornán, amit pedig a támadó szépen lehallgat.

A védekezés alapesetben biztonságos sütik beállításával, vagy kizárólag titkosított csatornán elérhető domainek beállításával oldható meg Martin O'Neal a SecurityFocus listán azt írta, hogy elég az áldozatot a http://somesecurebank.com:443-ra irányítani, így az SSL-only megoldás nem segít!

Demonstráció alant:


Surf Jacking Gmail demonstration from Sandro Gauci on Vimeo.

 

Címkék: defcon https surf jacking

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.

synapse · http://google.com 2008.08.12. 11:30:27

Ha fennall a MITM, akkor teljesen mindegy:
- Injektalok az oldalba trojanos flasht / javat
- Hamis ssl certet adok neki (userek 90% ugyis rakattint, nembaj hogy nem az eredeti)...
- stbstbstb...

Ja, az ilyen cookie-lopos tamadasokrol meg annyit, hogy ha rogziti sessionbe a generalaskor a kliens ip-jet es csak azzal engedi be, akkor love van az egesz.

synapse

atomgape 2008.08.13. 09:28:55

@synapse: Ha SSL titkosított a kapcsolat, akkor nem igen tudsz injektálni semmit...

A másik, hogy ha valaki ezt végre tudja hajtani, akkor egy IP-cím hamisítás már igazán ujjgyakorlat.

synapse · http://google.com 2008.08.13. 14:00:09

"- Hamis ssl certet adok neki (userek 90% ugyis rakattint, nembaj hogy nem az eredeti)..."

synapse

phr3ak 2008.08.18. 18:09:54

sőt, itt M.O.-n van bank akinek alapból nincs rendbe a tanusítvány érvényessége!