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

Helyi Kerberos megkerülés Windows-on

2010.08.17. 10:44 | buherator | 1 komment

A Kerberos protokoll mindig is a kedvenceim közé tartozott, így külön örömömre szolgál, hogy a velencei Ca'Foscari Egyetem kutatói hibát találtak a windowsos megvalósítás helyi bejelentkeztetést végző változatában, így bemutathatom magát a protokollt, valamint a vele kapcsolatos támadásokat.

Itt természetesen csak egy nagyvonalú áttekintést olvashattok, amely a protokoll lényegére igyekszik rávilágítani. Ha Kerberost akartok implementálni, ne tegyétek, inkább használjátok az MIT open-source megvalósítását! Ha támadásokon gondolkoztok, olvassátok el a teljes protokollspecifikációt ;)

A Kerberos protokoll központi autentikációt és autorizációt tesz lehetővé tetszőleges szolgáltatások számára nem megbízható kommunikációs csatornán keresztül. Mindehhez egyszerű közös titkokon alapuló szimmetrikus titkosítást használ, amivel képes biztosítani a hozzáférést kérő kliensek, a Kerberos kiszolgálók és az igénybe vett szolgáltatások hitelesítését is, valamint véd a lehallgatástól és a visszajátszáson alapuló támadásoktól is.

Nevét a halál római istene, Hádész háromfejű kutyájáról kapta, a hozzáférést igénylő kliensnek ugyanis három üzenetcserével kell bizonyítania jogosultságát az igénybevenni kívánt szolgáltatáshoz.

Az első "fej" az Authentication Service (AS), amely rendelkezik egy, a kliens és közte megosztott titokkal (kulccsal). A kliens első lépésben az AS-hez fordul (AS_REQ), és hozzáférést kér a köfetkező szolgáltatáshoz a Ticket Granting Service-hez (TGS). Ez az első kérés titkosítatlan, az AS pedig minden esetben egy ún. TGS tickettel (erről később), valamint a közös kulccsal titkosított adatcsomaggal válaszol, amely egyebek mellett tartalmazza a kliens által előzőleg küldött nonce-t (egyszer használatos, hosszú, véletlen érték),  másrészt egy egyszer használatos session kulcsot (AS_REP).

A TGS ticket egy, az AS és a TGS között megosztott kulccsal titkosított adatstruktúra, amely egyebek mellett tartalmazza az előzőleg a kliensnek is kiküldött session kulcsot. A kliens csak akkor tud hozzáférni a session kulcshoz, ha ismeri az AS-sel megosztott kulcsot, és ha az AS_REP valóban az AS-től érkezett (hiszen egy közbeékelődő támadó nem ismeri a szimmetrikus kulcsot). Így a kliens és az AS is hitelesítésre került azáltal, hogy az előbbi sikeresen megfejette az üzenetet, utóbbi pedig úgy tudta azt titkosítani, hogy megfejthető legyen a közös kulccsal. 

Nagyjából ugyanez játszódik le az autorizációt ellátó TGS és a szolgáltatás (Validator, V) irányában is, azzal a különbséggel, hogy ezeknél a titkosítás már az egyszer használatos session kulcsokkal történik a kapcsolat kezdetétől fogva (ez nem vonatkozik a ticketekre, azokat a "fejek" közti kulcsokkal külön titkosítják). Az AS és TGS funkciót legtöbbször összevonják, így készül a Key Distribution Center (KDC).

Ez a folyamat játszódik le akkor, mikor egy (modern) Windows tartományban egy távoli számítógépre próbálunk bejelentkezni, de az egyszerű hely bejelentkezések is megoldhatók ilyen módon. A most tárgyalandó támadások alapját az adja, hogy a helyi bejelentkezéshez igyekeztek a nem kifejezetten triviális protokoll egy egyszerűsített változatát használni.

KDC spoofing

A kezdeti, helyi bejelentkezést megvalósító Kerberos implementációk csak az első üzenetcserét valósították meg, mégpedig úgy, hogy az AS és a C kliens között használatos KC kulcsot a felhasználó által beírt (helyes vagy helytelen) kulcsból származtatták a kliensen. Mivel az AS a helyes kulcsot ismerte, az AS_REP-ben mindig a valódi, helyes kulcsot használták, így az AS_REP-ben érkező adatokat csak a helyes jelszó beírásával lehetett megfejteni. Igen ám, de egy, a C és az AS köz ékelődő, a C-hez helyben hozzáférő támadó kiserélhette az AS_REP választ a sajátjára, amelynek nem-ticket részét azzal a kulccsal titkosíthatta, amelyiket előzőleg a C-n megadott, így a visszafejtés sikerrel végződött, a támadó pedig bejelentkezhetett a rendszerbe.

Az eredeti protokoll esetén a támadó elbukna, mivel a TGS ticket-et nem tudná a következő lépés számára elfogadható módon reprodukálni.

A problémát a protokoll második üzenetcseréjének beiktatásával oldották meg: Minden kliens számára egy fiktív szolgáltatást regisztráltak a KDC-n, a bejelentkeztetést végző kliensek pedig ehhez kértek hozzáférést Kerberoson keresztül. Mivel KDC Spoofing esetében a támadó nem tudja előállítani a helyes TGS ticketet, az autentikáció meghiúsul. A TGS hitelességének megállapítására a kliens megfejti a V-nek szóló ticketet, amihez csak neki és a TGS-nek van kulcsa (hagyományos esetben csak V-nek és TGS-nek van kulcsa, és a ticketet a következő lépésben továbbítják V felé, itt C=V, ezért az utolsó lépést kihagyták).

Pass-the-ticket

A Windowsok ellen sikerrel bemutatott támadás a fenti továbbgondolása, megspékelve egy visszajátszással. A támadó először lehallgatja egy legitim felhasználó és a TGS között zajló forgalmazást, így hozzájut a V ticket-hez (amit még mindig nem tud megfejteni vagy módosítani, de erre nincs is szükség). Ezek után a támadó odasétál a klienshez, megad egy jelszót, közben pedig minden AS és TGS felé menő forgalmat blokkol, a válaszokat saját maga generálja. Az előzőleg megadott jelszóval titkosított válaszüzenetet küld a kliensnek, benne egy általa választott session kulccsal, a puszta formalitás kedvéért pedig mellékel mindehhez egy TGS ticketnek látszó bithalmazt. A kliens ezután megpróbálja elküldeni az autorizációs kérelmet a TGS felé, de újra csak a támadóval találja szembe magát, aki visszaküldi neki a lehallgatás során zsákmányolt V ticketet. Mivel a ticket valóban a klienshez rendelt fiktív szolgáltatás kulcsával lett titkosítva, a kliens beengedi a támadót, akármilyen jelszót is adott meg. 

A ticketek ugyan tartalmaznak egy "szavatossági" értéket, ami meghatározza, hogy kiadás után mennyi ideig használhatók fel, de ez az időtartam a vizsgált esetekben 24 óra, ami elég bőségesnek tűnik.

A velencei kutató egy Windows 2008 KDC-t és Windows XP, Vista ill. 7-es klienseket használtak a teszteléshez, az MIT-féle implementációk közül pedig Gentoo-Debian kliens-szerver párost használtak. A PoC - amely szintén elérhető - csak az utolsó esetben nem működött. A kutatók a protokoll mindhárom fázisának teljeskörű megvalósítását javasolják a probléma megoldására. A Microsoft a következő kedden fogja javítani a problémát.

Címkék: windows bug kriptográfia kerberos

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.

|Z| 2010.08.18. 11:28:42

A pass the ticket-ről kb. 2007 óra beszélnek (forrást most nem találtam), hogy megcsinálják, de végre sikerült összehozniuk :) A black-hat-es előadás témában erősen kapcsolódik a vasárnapi 10 perces bemutatóhoz.
süti beállítások módosítása