Napadi NTLM Relay: Zakaj je vase omrezje odprta vrata

Če bi lahko za vsak interni penetracijski test izbral samo eno napadalno tehniko, bi izbral NTLM relay. Za začetek ne potrebuje nobenih poverilnic, ustvari minimalen šum in deluje v več kot 90% okolij, ki jih testiram. Razlog je preprost: večina organizacij ni uveljavila kontrol podpisovanja in vezave kanalov, ki bi to preprečile.

NTLM relay ni nov napad. Varnostni raziskovalci ga demonstrirajo že več kot desetletje. Pa vendar ostaja ena najzanesljivejših poti do dostopa Domain Admin, ker privzeta konfiguracija Windows pušča vrata široko odprta.

Microsoft opisuje podpisovanje SMB ter podpisovanje LDAP in vezavo kanala kot zaščite komunikacije pred posegi in posredovanjem avtentikacije. Microsoft: SMB signing; Microsoft: LDAP signing and channel binding.

Kako NTLM Relay dejansko deluje

Avtentikacija NTLM je protokol izziv-odgovor. Ko se odjemalec želi avtenticirati pri strežniku, strežnik pošlje izziv, odjemalec izračuna odgovor z uporabo zgoščene vrednosti gesla, strežnik pa ga potrdi. Kritična slabost je, da protokol kriptografsko ne veže avtentikacije na določeno storitev ali kanal.

Kot napadalec na omrežju prestrežem poskus avtentikacije odjemalca in ga posredujem na drug strežnik. Ta strežnik misli, da se odjemalec neposredno avtenticira pri njem. Uporabljam orodja kot ntlmrelayx za avtomatizacijo, pri čemer sedim med odjemalcem in izbranim ciljem. Odjemalec se avtenticira, vendar sejo dobim jaz.

Kar to naredi uničujoče, je prisiljevanje. Ni mi treba pasivno čakati, da se avtentikacija zgodi. S tehnikami kot PetitPotam, PrinterBug ali DFSCoerce lahko prisilim naprave -- vključno s krmilniki domene -- da se avtenticirajo pri mojem gostiteljskem računalniku. Ko se račun naprave krmilnika domene avtenticira pri meni in to preusmerim na LDAP na drugem DC-ju, lahko neposredno spreminjam objekte Active Directory. Na več projektih sem se na ta način dodal med Domain Admine v manj kot desetih minutah.

Protokoli v nevarnosti

NTLM relay ni omejen na SMB. Redno preusmerjam na več protokolov, odvisno od tega, kaj je na voljo in katere zahteve po podpisovanju so nastavljene:

• SMB na SMB: Klasicna preusmeritev. Če na cilju ni zahtevano SMB-podpisovanje, preusmerim avtentikacije SMB in dobim oddaljeno izvajanje kode. To privzeto deluje na večini delovnih postaj.
• SMB na LDAP/LDAPS: Če LDAP-podpisovanje ali vezava kanalov ni uveljavljena, preusmerim na LDAP in spreminjam objekte AD. To je moja prednostna pot, ker mi omogoča, da si podelim kakršnokoli privilegijo želim.
• HTTP na LDAP: Spletna avtentikacija NTLM pogosto nima razširjene zaščite za avtentikacijo (EPA). Tudi to preusmerim na LDAP.
• SMB na ADCS HTTP vpis: Če ima Active Directory Certificate Services omogočen spletni vpis brez EPA, preusmerim nanj in zahtevam certifikat kot uporabnik, katerega avtentikacijo sem posredoval. To je napadalna pot ESC8, ki mi zagotovi trajni dostop.

Zaznavanje: kaj spremljati

Zaznavanje NTLM relay zahteva razumevanje, kako izgleda normalen NTLM promet v vašem okolju, ter opazovanje anomalij. Tukaj so specifični indikatorji, za katere svetujem branilcem, naj jih spremljajo:

Najprej spremljajte dogodke avtentikacije NTLM, kjer se ime izvorne delovne postaje ne ujema s povezovalnim IP-naslovom. Pri napadu relay metapodatki avtentikacije pravijo, da prihaja iz žrtvine naprave, a omrežna povezava prihaja z napadalčevega IP-ja. Dogodek ID 4624 na ciljnem strežniku vsebuje tako ime delovne postaje kot izvorni omrežni naslov -- ko se ne ujemata, takoj raziščite.

Drugič, spremljajte račune naprav, ki se avtenticirajo pri LDAP ali spletnem vpisu ADCS iz nepričakovanih virov. Krmilniki domene se ne bi smeli avtenticirati pri vaši končni točki spletnega vpisa ADCS. Če vidite račun naprave DC-ja, ki zahteva certifikat prek HTTP vpisa, ste verjetno pod aktivnim napadom.

Tretjič, spremljajte neobičajne spremembe LDAP, zlasti spremembe atributa msDS-AllowedToActOnBehalfOfOtherIdentity na objektih računalnikov. Ta atribut je tisti, ki ga spreminjam pri izvajanju napadov delegacije omejene na osnovi virov prek preusmeritve. Dogodek ID 5136 v revizijskem dnevniku sprememb imeniških storitev te spremembe zabeleži.

Utrjevanje: zapiranje vrat

Odprava za NTLM relay je dobro dokumentirana, a redko v celoti uvedena. Tukaj je celoten kontrolni seznam, ki ga prilagam vsakemu poročilu:

1. Uveljavite SMB-podpisovanje na vseh napravah. Konfigurirajte GPO "Microsoft network server: Digitally sign communications (always)" na Omogočeno na vseh strežnikih in delovnih postajah. Ja, tudi na delovnih postajah. Vpliv na zmogljivost je na sodobni strojni opremi začnemarljiv.
2. Uveljavite LDAP-podpisovanje. Nastavite "Domain controller: LDAP server signing requirements" na "Require signing" na vseh krmilnikih domene. Nastavite tudi politiko na strani odjemalca za zahtevo po podpisovanju.
3. Omogočite vezavo kanalov LDAP. Nastavite registrsko vrednost LdapEnforceChannelBinding na 2 na vseh krmilnikih domene. To preprečuje preusmeritev na LDAPS tudi ko je podpisovanje obvozeno prek TLS.
4. Omogočite EPA na vseh spletnih storitvah. To vključuje spletni vpis ADCS, Exchange, SCCM in vsako interno spletno aplikacijo, ki uporablja avtentikacijo Windows. EPA veže avtentikacijo NTLM na kanal TLS in preprečuje preusmeritev.
5. Onemogočite NTLM, kjer je mogoče. Uporabite skupinsko politiko za omejitev avtentikacije NTLM. Začnite z revizijo uporabe NTLM s politikami "Restrict NTLM" v revizijskem načinu, nato postopoma blokirajte. Cilj je Kerberos povsod.

Testiranje vaših obramb

Organizacijam vedno priporočam, da proaktivno preverijo svoje zaščite pred NTLM relay. Poženite PingCastle ali Purple Knight proti svoji domeni -- obe orodji preverjata manjkajoče SMB-podpisovanje, LDAP-podpisovanje in konfiguracijo vezave kanalov. BloodHound Enterprise lahko prav tako identificira naprave, ki so ranljive za napade relay na osnovi njihove konfiguracije podpisovanja.

Ne predpostavljajte, da so vaši GPO-ji pravilno uveljavljeni. Videl sem mnogo okolij, kjer je bila politika definirana, a ni bila povezana s pravo OU, ali kjer je konfliktna politika na nižji ravni preglasila varnostno nastavitev. S pravo analizo omrežnega prometa preverite, da je podpisovanje res uveljavljeno, ne samo konfigurirano.

NTLM relay je s tehničnega vidika rešen problem. Vse kontrole, potrebne za njegovo preprečitev, danes obstajajo in obstajajo že leta. Edini razlog, da še deluje, je, da organizacije teh kontrol niso uvedle. Če iz tega članka naredite eno stvar, uveljavite SMB in LDAP-podpisovanje povsod. To je ena sprememba z največjim vplivom, ki jo lahko naredite za varnostno stanje svojega AD okolja.

Povezano branje: Zakaj zahtevati SMB-podpisovanje; Active Directory Certificate Services: prednostne naloge pri penetracijskem testu in odprava tveganj.