Active Directory Hardening – Deo 3: Kerberos, Kerberoasting i delegacija autentifikacije

Prva dva dela serije pokrila su privilegovane naloge, protokole autentifikacije, Group Policy i delegiranje ovlašćenja. Treći deo se bavi Kerberos protokolom — konkretno Kerberoasting napadom i delegacijom autentifikacije (delegation), dve teme koje spadaju među najozbiljnije, a istovremeno najređe pronađene ranjivosti u AD okruženjima, jer ne zahtevaju nikakvu poznatu propusnost (CVE) — koriste legitimne funkcije protokola onako kako su projektovane.

Kerberoasting — zašto funkcioniše

Svaki nalog koji ima registrovan Service Principal Name (SPN) — tipično servisni nalog za SQL Server, IIS ili sličnu aplikaciju — može biti meta Kerberoasting napada. Bilo koji autentifikovan korisnik u domenu, bez ikakvih posebnih ovlašćenja, može da zatraži Kerberos servisnu kartu (TGS) za taj nalog. Deo te karte je šifrovan lozinkom servisnog naloga, pa napadač kartu jednostavno odnese van mreže i pokuša da je razbije offline, bez ikakvog daljeg saobraćaja koji bi izazvao alarm.

Problem nije u samom protokolu — problem je što servisni nalozi tradicionalno imaju lozinke koje se postave jednom, nikad ne menjaju, i često nisu ni približno dovoljno složene za nalog koji faktički funkcioniše kao mala privilegovana pristupna tačka u mreži.

Šta treba uraditi

• Migrirati servisne naloge na Group Managed Service Account (gMSA), gde god je aplikacija to u stanju da podrži — gMSA ima nasumično generisanu lozinku dužine oko 120–240 karaktera koja se automatski rotira, tipično na 30 dana, i koju niko ručno ne unosi niti pamti
• Za aplikacije koje zahtevaju migraciju na više servera, koristiti isti princip — gMSA podržava korišćenje na više hostova (npr. farma servera ili klaster)
• Gde gMSA tehnički nije moguć, postaviti dugu, nasumično generisanu lozinku (25+ karaktera) i uvesti redovnu rotaciju — Microsoft-ov apsolutni minimum je 14 karaktera, ali to treba tretirati kao donju granicu, ne kao cilj
• Na svim servisnim nalozima postaviti atribut msDS-SupportedEncryptionTypes tako da dozvoljava isključivo AES128/AES256, bez RC4 — nakon izmene enkripcije obavezno odmah promeniti lozinku da bi promena stupila na snagu
• Uraditi kvartalni popis svih naloga sa registrovanim SPN-om — u praksi se često nađu "osirotele" SPN vrednosti vezane za servise koji više ne postoje, na nalogu čija lozinka nije menjana godinama
• U SIEM-u pratiti Event ID 4769 (zahtev za Kerberos servisnu kartu) sa tipom enkripcije 0x17 (RC4) — posebno kad takvi zahtevi stižu u kratkom vremenskom periodu sa jednog naloga prema više različitih SPN-ova, što je tipičan obrazac alata za Kerberoasting

Napomena o riziku: ograničavanje msDS-SupportedEncryptionTypes na isključivo AES može prekinuti autentifikaciju starijih uređaja, mrežne opreme ili aplikacija koje ne podržavaju AES i i dalje zavise od RC4 — pre izmene proveriti sve klijente koji se oslanjaju na dati servisni nalog. Migracija na gMSA takođe zahteva da aplikacija to tehnički podržava (ne mogu je koristiti sve starije aplikacije), pa promenu treba testirati van produkcije pre nego što se stari servisni nalog ugasi.

Delegacija autentifikacije — tri tipa, veoma različit rizik

Kerberos delegacija omogućava servisu da se autentifikuje ka drugom servisu u ime korisnika koji mu je prišao — na primer, veb aplikacija koja u ime prijavljenog korisnika pristupa bazi podataka. Ovo je legitimna i često neophodna funkcionalnost za višeslojne aplikacije, ali postoje tri načina da se implementira, sa dramatično različitim nivoom rizika.

Tip delegacije	Šta dozvoljava	Nivo rizika
Unconstrained (neograničena)	Nalog može da se predstavlja kao bilo koji korisnik, ka bilo kom servisu u domenu	Kritičan
Constrained (ograničena)	Nalog može da se predstavlja kao korisnik, ali samo ka unapred definisanoj listi servisa	Umeren — zavisi od konfiguracije
Resource-based constrained (RBCD)	Ciljni resurs sam kontroliše ko sme da mu delegira pristup	Najniži, uz pravilnu konfiguraciju

Neograničena (unconstrained) delegacija je posebno opasna jer, kad se korisnik autentifikuje ka servisu koji ima ovo podešavanje, domain kontroler unutar servisne karte prosleđuje i celu korisnikovu Ticket Granting Ticket (TGT) kartu, koju servis onda drži u memoriji. Napadač koji kompromituje taj servis ili mašinu na kojoj radi može da izvuče sve TGT karte iz memorije i njima se predstavlja kao bilo koji korisnik koji se u međuvremenu autentifikovao na tu mašinu — uključujući, ako je bio dovoljno "nesrećan" da se tu pojavi, i domain admin nalog.

Ovo se dodatno može isprovocirati: poznati "Printer Bug" napad tera domain kontroler da se sam autentifikuje ka mašini sa neograničenom delegacijom, nakon čega napadač izvlači TGT kartu domain kontrolera i time efektivno preuzima ceo domen.

Šta treba uraditi

• Popisati sve naloge (korisničke i računarske) sa atributom TrustedForDelegation postavljenim na tačno — svaki nalaz van domain kontrolera predstavlja nalaz najvišeg prioriteta u bilo kojoj bezbednosnoj proveri
• Migrirati sve aplikacije koje trenutno koriste neograničenu delegaciju na ograničenu (constrained) ili, gde je moguće, resource-based constrained delegaciju
• Kod ograničene delegacije, posebno obratiti pažnju na "protocol transition" opciju (Any Authentication Protocol) — ona dozvoljava nalogu da dobije kartu za bilo kog korisnika bez prethodne Kerberos autentifikacije, što je znatno rizičnije od standardnog Kerberos-only režima
• Sve administratorske i druge visoko privilegovane naloge označiti kao "Account is sensitive and cannot be delegated" — ovo sprečava da takav nalog uopšte bude meta bilo kog tipa delegacije
• Razmotriti uvođenje grupe Protected Users za administratorske naloge — članovi ove grupe ne mogu biti predmet delegacije, ne mogu koristiti stariju (DES/RC4) enkripciju, i imaju kraći vek trajanja TGT karte (4 sata umesto standardnih 10), uz obaveznu prethodnu proveru da nijedna postojeća aplikacija ne zavisi od isključenih mehanizama
• Pratiti Event ID 4768 i 4769 u kombinaciji sa promenama na msDS-AllowedToDelegateTo i msDS-AllowedToActOnBehalfOfOtherIdentity atributima, jer izmena ovih atributa van planiranog održavanja predstavlja jak indikator pokušaja zloupotrebe delegacije

Napomena o riziku: uklanjanje neograničene delegacije, obeležavanje naloga kao "cannot be delegated" i uvođenje Protected Users grupe mogu direktno prekinuti rad aplikacija koje su o tu delegaciju oslonjene za legitimnu funkcionalnost (npr. veb aplikacija koja u ime korisnika pristupa bazi). Protected Users dodatno isključuje starije mehanizme (DES/RC4, credential delegation/CredSSP) i skraćuje vek TGT karte, što može prekinuti stariji softver koji na njih računa. Svaku od ovih promena testirati na manjem broju naloga ili u test okruženju pre šire primene, i unapred identifikovati sve aplikacije koje zavise od pogođenog naloga.

Sledeći deo serije bavi se bezbednošću samih domain kontrolera — fizičkim i virtuelizacionim aspektima, patch management disciplinom i podešavanjima koja se odnose isključivo na uloge domain kontrolera, kao i pravilnim korišćenjem Read-Only Domain Controller-a (RODC) za lokacije koje nemaju isti nivo fizičke bezbednosti kao centralni data centar.