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

Penetracijske teste za slovenska podjetja izvajam ze vec kot 5 let. Okolja Active Directory so moja specialnost - in iskreno povedano, so razlog za mojo visoko uspesnost. 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 omrezje. To niso teoreticni napadi z varnostnih konferenc. To so resnicne napacne konfiguracije, ki mi omogocijo dostop do Domain Admina, obicajno ze prvi dan testiranja.

Iluzija "Imamo LAPS"

Obozujem, ko mi podjetja povedo, da so implementirala LAPS (Local Administrator Password Solution). To povedo s takim samozaupanjem, kot da so za vedno resili problem lokalnega administratorja.

Nato pozenem preprosto LDAP poizvedbo in najdem:

• 30% racunalnikov sploh nima namešcenega LAPS
• Geslo LAPS lahko berejo "Domain Users", ker je nekdo napacno konfiguriral ACL-je
• Stari racunalniki, ki bi jih "morali upokojiti", se vedno uporabljajo isto geslo lokalnega administratorja iz leta 2018

Na enem izmed projektov lansko leto sem kompromitiral streznik, 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.

Servisni racuni: Darilo, ki kar daje

Kerberoasting bi moral biti ze dobro poznan. Vsak varnostni ponudnik govori o njem. Pa vendar sem v zadnjih 20 projektih uspesno izvlekel poverilnice z Kerberoastingom v 18 primerih.

Vzorec je vedno enak:

1. Najdem servisne racune s SPN-ji
2. Zahtevam njihove vstopnice (to lahko stori vsak uporabnik domene)
3. Gesla razbijam brez povezave - obicajno v nekaj minutah
4. Ti servisni racuni imajo pravice Domain Admin, "ker je aplikacija to potrebovala"

Moj najljubsi primer je bil servisni racun 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 priporocam Group Managed Service Accounts (gMSA). Geslo ima 240 znakov, se samodejno rotira in vam ga ni treba nikoli rocno upravljati. Ampak to razlagati podjetjem, ki so "prevec zaposlena" za pravilno implementacijo? To je pravi izziv.

Igrissce NTLM Relay

SMB podpisovanje je privzeto onemogoceno na Windows delovnih postajah. Vecina slovenskih podjetij tega nikoli ne spremeni. To pomeni, da lahko:

1. Sedim v omrezju z zagnano orodjem Responder
2. Cakam na zahteve za overitev (ali jih izsilim s PetitPotam)
3. Te poverilnice preusmerim na druge naprave
4. Dobim lupine na streznikih brez razbijanja enega samega gesla

Popravek je preprost - omogocite SMB podpisovanje. Ampak ko to omenim v porocilih, je odziv pogosto "to bo upocasnilo prenose datotek." Ja, za zanemarljivo kolicino. Ampak ocitno je to huje, kot da imam poln dostop do vasih datotecnih streznikov.

LDAP podpisovanje je se slabse. Ocenjujem, da ga ima omogocenega 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 zacetka.

BloodHound razkrije vse

Ob vsakem penetracijskem testu pozenem BloodHound. Vsakic mi pokaze napadne poti, za katere IT ekipa ni vedela, da obstajajo.

Pogoste ugotovitve:

• Uporabniki pomoci uporabnikom lahko ponastavijo gesla za IT administratorje (ki lahko ponastavijo gesla za Domain Admine)
• Marketinski uporabnik ima GenericAll pravice na objektu racunalnika (kar vodi v RBCD napad)
• Vgnezdena clanstva v skupinah, ki dajejo nepricakovan administratorski dostop
• Servisni racuni, ki so clani 15 razlicnih skupin "za vsak slucaj"

Najslabse? Te napadne poti pogosto obstajajo, ker je nekdo potreboval zacasen dostop pred 3 leti in tega nihce ni pocistil. Dovoljenja AD se kopicijo kot tehnicni dolg, le da vecina podjetij sploh ne ve, da imajo ta dolg.

Dvorana sramote konfiguracij krmilnikov domene

V slovenskih podjetjih redno najdem:

Print Spooler, ki tece na DC-jih: Ta storitev ne bi smela nikoli teciti na krmilnikih domene. Omogoca napade PrinterBug, ki lahko prisilijo DC, da se overja pri moji napravi. V kombinaciji z NTLM relay je to pogosto konec igre.

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

Brez vecnivojskega administratorskega modela: Isti racun, ki ponastavi uporabniska 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 obtickane v letu 2005. Pogoste 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 pozenem napade razprsevanja gesel, skoraj vedno najdem racune z gesli kot:

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

Eno podjetje je imelo politiko, da se morajo gesla zaceti z veliko zacetnico in koncati s stevilko. Uganete, kaksen vzorec je sledilo 80% njihovih uporabnikov?

Vrzel Azure AD

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

• Strezniki Azure AD Connect obravnavani kot navadne delovne postaje
• Brez politik pogojnega dostopa
• Se vedno omogocena podedovana overitev (ki omogoca napade razprsevanja gesel)
• Brez MFA za administratorske racune, ker je "neprijetno"

Videl sem podjetja, ki so mocno vlozila v varnost na lokaciji, medtem ko so njihovo okolje Azure pustili siroko odprto. Oblak ni samodejno varen - zahteva enako pozornost pri konfiguraciji.

Kaj dejansko deluje

Po letih iskanja istih tezav, tukaj je, kaj povem podjetjem, naj dajo prednost:

1. Omogocite SMB in LDAP podpisovanje. Ja, povsod. Vpliv na zmogljivost je zanemarljiv v primerjavi z varnostnim dobickom.
2. Pravilno implementirajte LAPS. To pomeni namestitev na VSE naprave in omejitev, kdo lahko bere gesla. Redno revidirajte.
3. Uporabljajte gMSA za servisne racune. Prenehajte uporabljati navadne racune s staticnimi gesli. gMSA popolnoma resijo ta problem.
4. Pozenite BloodHound na sebi. Preden jaz najdem te napadne poti, bi jih morali najti vi. Pocistite nepotrebna dovoljenja.
5. Implementirajte vecnivojsko administracijo. Administratorski racuni za delovne postaje ne bi smeli nikoli dotakniti streznikov. Administratorji streznikov ne bi smeli nikoli dotakniti krmilnikov domene. To omeji obseg skode ob kompromitaciji.
6. Onemogocite Print Spooler na DC-jih. Preprosto to storite. Karkoli mislite, da potrebujete za tiskanje, obstaja boljsa resitev.
7. Sodobna politika gesel. 15+ znakov, brez zahtev po kompleksnosti (ne pomagajo), blokirajte razkrita gesla, prepovejte izraze povezane s podjetjem.
8. MFA povsod. Se posebej za administratorje, se posebej za oddaljeni dostop, se posebej za oblacne storitve.

Pravi problem

Tehnicni popravki niso tako tezki. Pravi izziv je organizacijski. Podjetja ne namenjajo proracuna za varnostne preglede AD. IT ekipe so preobremenjene z vsakodnevnimi operacijami. Varnost je videna kot stroskovni center, ne kot omogocitelj poslovanja.

Nato nekega dne udari izsiljevalska programska oprema in nenadoma je proracun na voljo. Le da je zdaj za odziv na incident, ne za preprecevanje.

Te ugotovitve napisem v vsako porocilo in vem, da vecina ne bo implementirana, dokler ne pride do vdora. To je frustrirajoca realnost varnostnega svetovanja v Sloveniji. Ampak jih se naprej pisem, ker vsako podjetje, ki poslusa, pomeni eno zrtev manj.

Ce to berete in prepoznavate svoje okolje, imate dve izbiri: popravite zdaj, ko imate cas, ali popravite pozneje, ko boste svojemu direktorju razlagali, zakaj je izsiljevalska programska oprema pravkar sifrirala vse vase krmilnike domene.

Vem, katero moznost bi jaz izbral.