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

További infók a TLS problémáról

2009.11.10. 10:41 | buherator | 3 komment

Először is a támadáról, kicsit pontosabban (bocs, az előző bejegyzést elég sietve kellett összedobnom):

A támadás aktív man-in-the-middle forgatókönyvet feltételez, és egy parancs/lekérdezés beszúrására ad lehetőséget a támadó számára egy hitelesített kliens nevében. A probléma kihasználásához a támadónak magán keresztül kell irányítania a hálózati forgalmat, kiépítenie egy SSL csatornát önmaga és az SSL szerver között, beszúrni a kívánt üzenetetet, majd a valódi kliens Client Hello üzenetének visszajátszásával és az ezt követő kliens-szerver üzenetek áteresztésével újraegyeztetni a kapcsolatot a kliens és a szerver között.

A támadásnak több variánsa is elképzelhető, de a legszélesebb felhasználói kört érintő probléma úgy alakul ki, hogy a sebezhető SSL kiszolgáló hozzáfűzi a támadó által küldött üzenethez a valódi kliens üzenetét, így pl. egy lezáratlan HTTP GET kéréssel a támadó el tudja fedni a valódi kliens kérését, de meg tudja tartani a kérés fejlécének többi részét, pl. a sütiket, így a támadó kérései a kliens munkamenet-azonosítójával fog lefutni:

GET /tamado/lekerdezese HTTP/1.0\r\n
Valami-fejlec:
GET /kliens/lekerdezese HTTP/1.0\r\n
Cookie: [a kliens sütijei, ill. további fejlécek]\r\n\r\n

A módszer segítségével nem olvasható ki adat a titkosított csatornából, ezért a beszúrt lekérdezés/parancs eredményét a támadó nem látja, így a CSRF ellen védett HTTP weboldalak pl. nincsenek veszélyben.

Sokat tudnak segíteni a megértésben az eredeti felfedező, Marsh Ray folyamatábrái.

A G-Sec folyamatosan frissülő információs weboldalt tart karban a nem rég bemutatott TLS sebezhetőséggel kapcsolatban, ennek leglényegesebb pontjai a következők (némi kiegészítéssel):

  • A sebezhetőséget a legnagyobb gyártók megerősítették. Az Apache, az OpenSSL és a GnuTLS implementációkhoz már rendelkezésre áll javítás, a Cisco biztonsági tanácslatot adott ki.
  • A Leviathan Security jóvoltából megjelent egy tesztalkalmazás, mellyel ellenőrizhető, hogy egy kiszolgáló támogatja-e a kliens által kezdeményezett kapcsolat-újraegyeztetést, ami potenciálisan sebezhetővé teszi a protokollmegvalósításokat a támadással szemben. A legtöbb fontos külföldi és magyar webhely jelenleg sebezhetőnek tűnik...

Érdemes ezeken kívül követni Thierry Zollert a Twitteren, ő valós időben csiripeli a fejleményeket.

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.

dnet 2009.11.10. 11:39:05

A Marsh Ray folyamatábráira mutató link 404.

Aron bacsi 2009.11.11. 09:48:32

A CSRF-es, Moxie Marlinspike-os cikk jol ertheto anyag... Ez alapjan viszont az a gyanum, hogy ha a sima SSL "client authentication" nem is, de az SSL handshake-tol fuggetlenul, az elkuldott adatok kliens altali digit alairasa mar ved az ilyen tamadasok ellen.

A banki peldajuk azonban pont emiatt picit santit... Anno varrtam be netbanki fizetesi tranzakciot atado modult a ceges oldalba (talan OTP-s vagy K&H-s volt), es azok rem egyszeruen, de hasznalnak digit alairast. Tehat megvannak a parameterek URL-ben (GET), hogy kitol, kinek mennyi lovetta megy, es a vegere meg beszur egy digit alairast is (csak base64-ben a PKCS#1 strukturat), amit olyan kulccsal hozott letre, amit a bank osztott ki nevreszoloan a cegnek.

Tehat, ha azt kerdezik a banki alkalmazastol a szerveren, hogy a ket (eredeti es ujrajatszott) adathalmaz kozul melyiket hajtja vegre, akkor nyilvan azt fogja valasztani, amelyik a jo kulccsal volt alairva, a masikat meg eldobja, sot, siman riaszthat is a rosszra... Ja, meg persze ehhez meg fontos, hogy vigyazzunk a titkos kulcsra (a p12/pfx-et dobjuk fel Aladdin-ra, vagy valami hasonlora, aminek van Linuxra is drivere)!