Napake varnosti Active Directory, ki jih vidim v vsakem slovenskem podjetju

Penetracijske teste za slovenska podjetja izvajam že več kot 5 let. Okolja Active Directory so moja specialnost - in iskreno povedano, so razlog za mojo visoko uspešnost. Ne zato, ker bi bil nek genialni heker, ampak ker se iste napake pojavljajo v skoraj vsakem podjetju, ki ga testiram.

Naj vam povem, kaj dejansko najdem, ko pridem v slovensko korporativno omrežje. To niso teoretični napadi z varnostnih konferenc. To so resnične napačne konfiguracije, ki mi omogočijo dostop do Domain Admina, običajno že prvi dan testiranja.

Dokumentacija za Windows LAPS, gMSA in podpisovanje SMB opisuje delovanje navedenih zaščit in pogoje njihove uvedbe. Microsoft: Windows LAPS; Microsoft: secure group managed service accounts; Microsoft: SMB signing.

Iluzija "Imamo LAPS"

Obožujem, ko mi podjetja povedo, da so uvedla LAPS (Local Administrator Password Solution). To povedo s takim samozaupanjem, kot da so za vedno rešili problem lokalnega administratorja.

Nato poženem preprosto LDAP poizvedbo in najdem:

• 30% računalnikov sploh nima nameščenega LAPS
• Geslo LAPS lahko berejo "Domain Users", ker je nekdo napačno konfiguriral ACL-je
• Stari računalniki, ki bi jih "morali upokojiti", še vedno uporabljajo isto geslo lokalnega administratorja iz leta 2018

Na enem izmed projektov lansko leto sem kompromitiral strežnik, za katerega je IT ekipa prisegala, da je "popolnoma izoliran." Imel je isto geslo lokalnega administratorja kot 47 drugih naprav. Geslo? Ime podjetja s "2019!" na koncu.

Storitveni računi: ponavljajoč se vir tveganja

Kerberoasting bi moral biti že dobro poznan. Vsak varnostni ponudnik govori o njem. Pa vendar sem v zadnjih 20 projektih uspešno izvlekel poverilnice s Kerberoastingom v 18 primerih.

Vzorec je vedno enak:

1. Najdem storitvene račune s SPN-ji
2. Zahtevam njihove vozovnice (to lahko stori vsak uporabnik domene)
3. Gesla razbijam brez povezave - običajno v nekaj minutah
4. Ti storitveni računi imajo pravice Domain Admin, "ker je aplikacija to potrebovala"

Moj najljubši primer je bil storitveni račun za varnostno kopiranje z geslom "Backup2020!". Imel je pravice Domain Admin, geslo pa ni bilo spremenjeno 4 leta. Obramba IT ekipe? "Nismo ga mogli spremeniti, ker nismo vedeli, kaj bi se pokvarilo."

Zato vedno priporočam Group Managed Service Accounts (gMSA). Geslo ima 240 bajtov, se samodejno rotira in vam ga ni treba nikoli ročno upravljati. Ampak to razlagati podjetjem, ki so "preveč zaposlena" za pravilno uvedbo? To je pravi izziv.

Priložnosti za NTLM Relay

SMB-podpisovanje je privzeto onemogočeno na Windows delovnih postajah. Večina slovenskih podjetij tega nikoli ne spremeni. To pomeni, da lahko:

1. Sedim v omrežju z zagnanim orodjem Responder
2. Čakam na zahteve za avtentikacijo (ali jih izsilim s PetitPotam)
3. Te poverilnice preusmerim na druge naprave
4. Dobim lupine na strežnikih brez razbijanja enega samega gesla

Popravek je preprost - omogočite SMB-podpisovanje. Ampak ko to omenim v poročilih, je odziv pogosto "to bo upočasnilo prenose datotek." Ja, za začnemarljivo količino. Ampak očitno je to huje, kot da imam poln dostop do vaših datotečnih strežnikov.

LDAP-podpisovanje je se slabše. Ocenjujem, da ga ima omogočenega manj kot 10% slovenskih podjetij. To pomeni, da lahko preusmerim poverilnice na LDAP in neposredno spreminjam objekte Active Directory. Na enem testu sem se dodal v skupino Domain Admins v 15 minutah od začetka.

BloodHound razkrije vse

Ob vsakem penetracijskem testu poženem BloodHound. Vsakič mi pokaže napadalne poti, za katere IT ekipa ni vedela, da obstajajo.

Pogoste ugotovitve:

• Uporabniki pomoči uporabnikom lahko ponastavijo gesla za IT administratorje (ki lahko ponastavijo gesla za Domain Admine)
• Marketinški uporabnik ima GenericAll pravice na objektu računalnika (kar vodi v RBCD napad)
• Vgnezdena članstva v skupinah, ki dajejo nepričakovan administratorski dostop
• Storitveni računi, ki so člani 15 različnih skupin "za vsak slučaj"

Najslabše? Te napadalne poti pogosto obstajajo, ker je nekdo potreboval začasen dostop pred 3 leti in tega nihče ni počistil. Dovoljenja AD se kopičijo kot tehnični dolg, le da večina podjetij sploh ne ve, da imajo ta dolg.

Dvorana sramote konfiguracij krmilnikov domene

V slovenskih podjetjih redno najdem:

Print Spooler, ki teče na DC-jih: Ta storitev ne bi smela nikoli teči na krmilnikih domene. Omogoča napade PrinterBug, ki lahko prisilijo DC, da se avtenticira pri moji napravi. V kombinaciji z NTLM relay je to pogosto konec igre.

Neomejena delegacija: Nekatere aplikacije jo "zahtevajo", zato jo IT omogoči brez razumevanja posledic. Kadarkoli se Domain Admin prijavi na napravo z neomejeno delegacijo, lahko zajamem njihov TGT in se predstavljam kot oni.

Brez večnivojskega administratorskega modela: Isti račun, ki ponastavi uporabniška gesla, upravlja tudi krmilnike domene. Ko kompromitiram eno delovno postajo, se lahko pogosto povzpnem do Domain Admina v nekaj urah, ker administratorji ponovno uporabljajo svoje poverilnice povsod.

Problem gesel

Politike gesel v Sloveniji se zdijo obtičale v letu 2005. Pogosto najdem:

• Minimum 8 znakov (razbito v sekundah)
• 90-dnevno potekanje (kar vodi v Password1!, Password2!, Password3!...)
• Brez preverjanja razkritih gesel
• Ime podjetja kot del gesla za "dosledno blagovno znamko"

Ko poženem napade razprševanja gesel, skoraj vedno najdem račune z gesli kot:

• [ImePodjetja][Leto]!
• Geslo123!
• Ljubljana2024
• Poletje2024!

Eno podjetje je imelo politiko, da se morajo gesla začeti z veliko začetnico in končati s številko. Uganete, kakšen vzorec je sledilo 80% njihovih uporabnikov?

Vrzel Azure AD

Več slovenskih podjetij se seli v hibridna okolja, vendar delajo nove napake:

• Strežniki Azure AD Connect obravnavani kot navadne delovne postaje
• Brez politik pogojnega dostopa
• Še vedno omogočena podedovana avtentikacija (ki omogoča napade razprševanja gesel)
• Brez MFA za administratorske račune, ker je "neprijetno"

Videl sem podjetja, ki so močno vložila v varnost na lokaciji, medtem ko so njihovo okolje Azure pustili široko odprto. Oblak ni samodejno varen - zahteva enako pozornost pri konfiguraciji.

Kaj dejansko deluje

Po letih iskanja istih težav, tukaj je, kaj povem podjetjem, naj dajo prednost:

1. Omogočite SMB in LDAP-podpisovanje. Ja, povsod. Vpliv na zmogljivost je začnemarljiv v primerjavi z varnostnim dobičkom.
2. Pravilno uvedite LAPS. To pomeni namestitev na VSE naprave in omejitev, kdo lahko bere gesla. Redno revidirajte.
3. Uporabljajte gMSA za storitvene račune. Prenehajte uporabljati navadne račune s statičnimi gesli. gMSA popolnoma rešijo ta problem.
4. Poženite BloodHound v svojem okolju. Preden jaz najdem te napadalne poti, bi jih morali najti vi. Počistite nepotrebna dovoljenja.
5. Uvedite večnivojsko administracijo. Administratorski računi za delovne postaje se ne bi smeli uporabljati za upravljanje strežnikov. Administratorji strežnikov ne bi smeli z istimi računi upravljati krmilnikov domene. To omeji obseg škode ob kompromitaciji.
6. Onemogočite Print Spooler na DC-jih. Preprosto to storite. Karkoli mislite, da potrebujete za tiskanje, obstaja boljša rešitev.
7. Sodobna politika gesel. 15+ znakov, brez zahtev po kompleksnosti (ne pomagajo), blokirajte razkrita gesla, prepovejte izraze povezane s podjetjem.
8. MFA povsod. Še posebej za administratorje, še posebej za oddaljeni dostop, še posebej za oblačne storitve.

Pravi problem

Tehnični popravki niso tako težki. Pravi izziv je organizacijski. Podjetja ne namenjajo proračuna za varnostne preglede AD. IT ekipe so preobremenjene z vsakodnevnimi operacijami. Vodstvo varnost pogosto vidi samo kot strošek in spregleda njen pomen za poslovanje.

Nato nekega dne udari izsiljevalska programska oprema in nenadoma je proračun na voljo. Le da je zdaj za odziv na incident, ne za preprečevanje.

Te ugotovitve napišem v vsako poročilo in vem, da večina ne bo uvedena, dokler ne pride do vdora. To je neprijetna plat varnostnega svetovanja v Sloveniji. Ampak jih še naprej pišem, ker vsako podjetje, ki posluša, pomeni eno žrtev manj.

Če to berete in prepoznavate svoje okolje, imate dve izbiri: popravite zdaj, ko imate čas, ali popravite pozneje, ko boste svojemu direktorju razlagali, zakaj je izsiljevalska programska oprema pravkar šifrirala vse vaše krmilnike domene.

Vem, katero možnost bi jaz izbral.

Povezano branje: LAPS, gMSA in večnivojska administracija: trije stebri obrambe AD; Varnost Microsoft Entra ID in pogoste napačne nastavitve.