NTLM relay все още работи в съвременна среда с AD

От всички техники, които надживяват „съвременните, обновени“ среди, NTLM relay е една от най-упоритите. Той не разбива пароли и не използва CVE. Той просто взема удостоверяване, предназначено за една услуга, и го препредава към друга — а в почти стандартно конфигуриран Active Directory това често е достатъчно, за да бъде прочетена цялата директория.

Механизмът, накратко

Когато Windows машина се удостоверява през NTLM, нападател, разположен по средата, може да препрати това удостоверяване към различен сървър и да бъде приет като жертвата. Две неща го правят опустошителен: нападателите могат да принудят машините да се удостоверяват по заявка (чрез редица вградени RPC методи), а ако приемащата услуга не изисква подписване, тя не може да разпознае, че удостоверяването е било препредадено.

Relay към LDAP: прочитане на цялата директория

Успешен relay към LDAP може да даде правата на препредадената идентичност. Обичайни удостоверени идентичности често четат значителна информация, но защитените атрибути и обекти остават подчинени на ACL. Установете защитите на целта и реално четимите данни, вместо да приравнявате успешен bind с неограничен достъп до цялата директория.

Настройките, които го спират

• Изисквайте подписване на SMB навсякъде, чрез групова политика. Това премахва примитива за relay при SMB цели.
• Налагайте подписване на LDAP и обвързване на канала на домейн контролерите — това преодолява конкретно relay към LDAP.
• Ограничете подмяната на отговори при разрешаване на имена. Изключете ненужните LLMNR, NBT-NS и mDNS пътища след проверка на съвместимостта. Това намалява възможностите за привличане на удостоверяване чрез подменени отговори, но не премахва независима RPC coercion или всеки източник на NTLM удостоверяване.
• Намалете NTLM. Там, където е възможно, ограничете или изключете NTLM в полза на Kerberos и наблюдавайте удостоверяването с NTLM за аномалии.
• Обновете векторите за принуждаване и ограничете RPC интерфейсите, които нападателите използват, за да задействат удостоверявания.

Relay се задържа, защото защитите са конфигурация, не кръпки — а конфигурацията се отклонява, получава изключения „временно“ и никога не бива преразгледана. Поправката е подписването и обвързването на канала да бъдат зададени като непреговаряеми базови нива и да бъде тествано, че действително се налагат.

Принуждаване: удостоверяване по заявка

RPC coercion механизми могат да предизвикат удостоверяване без подменено разрешаване на имена. Възможността зависи от интерфейса, правата, поправките и мрежовата политика. Прегледайте и ограничете ненужните интерфейси, приложете обновяванията и защитете целта с подходящо подписване или EPA. Не приемайте, че всеки хост може да бъде принуден, или че ограничаването на именните протоколи премахва този отделен път.

Защо само обновяването няма да ви спаси

Relay се задържа, защото е конфигурация, не единичен CVE. Можете да обновите всеки вектор за принуждаване и все пак да бъдете напълно уязвими на relay, ако подписването не е наложено — и можете да наложите подписване и все пак да бъдете принудени, ако векторите са отворени. Двете защити работят заедно и нито една не е кръпка, която инсталирате веднъж. Третирайте подписването и обвързването на канала като базови нива, които активно проверявате, защото денят, в който се отклонят, е денят, в който relay заработва отново.

Relay между протоколи: защо целта рядко съвпада с източника

Cross-protocol relay може да работи между съвместими NTLM услуги при липсващи или неефективни съответни защити. Успехът зависи от протоколите, договарянето, подписването, обвързването с канал или услуга, поправките и правата на идентичността. Самата поддръжка на NTLM не доказва, че всяка комбинация източник–цел позволява relay.

HTTP крайните точки заслужават особено внимание, защото са навсякъде и често остават неудостоверени на нивото на канала. Най-поучителният пример е уеб записването в AD CS (проблемът, обикновено каталогизиран като ESC8). По същество: уеб интерфейс за заявяване на сертификати приема NTLM удостоверяване през HTTP и ако тази предна част не настоява за обвързване на канала, препредадено машинно удостоверяване може да бъде използвано, за да бъде заявен сертификат като тази машина. Сертификатът представлява трайни, преносими данни за достъп — той надживява смените на пароли и може да бъде използван за последващо удостоверяване — което превръща мимолетно принудено влизане в дълготраен достъп. Други услуги с HTTP интерфейс (административни конзоли, интранет приложения, използващи интегрирано Windows удостоверяване, крайни точки в стил Exchange) представляват същата форма на риск. Урокът е, че HTTP целта за relay често е по-ценна от очевидната SMB или LDAP цел, именно защото защитниците забравят, че тя изобщо говори NTLM.

Подписването, MIC и обвързването на канала не са един и същ контрол

Тези три защити рутинно се смесват, а те спират различни неща и защитават различни услуги. Разбирането на разликата обяснява защо една единствена настройка никога не затваря целия клас.

• Подписването на сесията (подписване на SMB, подписване на LDAP) криптографски обвързва всяко съобщение с удостоверената сесия, така че нападател, който е препредал установяването на връзката, после не може да инжектира или подправя трафик в тази сесия. То преодолява употребата на препредадена сесия, но само там, където протоколът поддържа подписване и двата края го налагат.
• MIC (код за цялост на съобщението) защитава целостта на самия NTLM обмен за удостоверяване, като предотвратява нападател да отстрани полета — например флаговете, които биха поискали подписване — от съобщенията в пренос. Историческите техники за relay работеха именно чрез премахването на тези защити в движение; MIC съществува, за да направи това подправяне откриваемо.
• Обвързването на канала / разширената защита на удостоверяването (EPA) обвързва NTLM удостоверяването с външния TLS канал, по който е пристигнало. Тъй като препредаденото удостоверяване достига целта по различен TLS канал от онзи, който жертвата е установила, обвързването вече не съвпада и сървърът го отхвърля. Това е контролът, който защитава услугите с TLS интерфейс — LDAPS и HTTPS крайни точки, включително уеб записването — където самото подписване не се прилага.

Казано направо: подписването спира препредадените сесии да бъдат използвани, MIC спира установяването на връзката да бъде понижено, а обвързването на канала спира relay изобщо да попадне върху TLS крайна точка. Нужна ви е съответната комбинация при всяко местоназначение.

Кои услуги подписването може и не може да спаси

Подписването е налично само там, където протоколът го определя и двете страни го налагат. SMB и LDAP го поддържат; много услуги, базирани на HTTP, изобщо не подписват и трябва вместо това да разчитат на обвързване на канала. Остарелите и вградените в устройства услуги, които говорят NTLM, но не реализират нито подписване, нито EPA — услуги за печат, по-стари административни интерфейси, уеб приложения на трети страни с интегрирано Windows удостоверяване — често са слабото звено, защото за тях изобщо няма наличен контрол за цялост на транспортното ниво. Третирайте всяка такава услуга като уязвима на relay, докато не бъде доказано противното, и я поставете зад TLS с обвързване на канала или премахнете напълно приемането на NTLM от нея.

хост жертва  --(принудено удостоверяване, канал A)-->  relay на нападателя
relay на нападателя  --(същото удостоверяване, канал B)-->  целева услуга
целевата услуга  дава сесия като идентичността на жертвата