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.
dnet 2009.11.10. 11:39:05
buherator · http://buhera.blog.hu 2009.11.10. 11:46:49
Aron bacsi 2009.11.11. 09:48:32
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)!