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.