Основные уязвимости Active Directory, 3 часть
Настоятельно рекомендую ознакомиться с предыдущими главами:
- Первая часть
- Вторая часть
Приятного чтения!
8. Пользователи без пароля
Еще один интересный флаг в Active Directory - это флаг PASSWD_NOTREQD. Если для учетной записи пользователя установлен этот флаг, это означает, что учетная запись не обязательно должна иметь пароль.
Это не означает, что у учетной записи пользователя нет пароля, это просто означает, что он не обязательно должен быть. Это означает, что подойдет любой пароль - короткий, несоответствующий (противоречащий политике паролей домена) или пустой. Просто любой.
Это, конечно, огромная угроза безопасности, и ни в одной учетной записи пользователя никогда не должен быть установлен этот флаг.
Прикладываю хеш пустого пароля:
Код:
31d6cfe0d16ae931b73c59d7e0c089c0 - пустой NTLM хеш
aad3b435b51404eeaad3b435b51404ee - пустой LM хешКак проверить:
Поиск пользователей с установленным флагом PASSWD_NOTREQD очень похож на поиск пользователей с паролями с неограниченным сроком действия. Мы снова можем использовать инструмент LDAPDomainDump .
Все, что нам нужно, - это учетные данные пользователя домена с низким уровнем привилегий и возможность доступа к порту LDAP любого контроллера домена.
1) Сначала соберите информацию с контроллера домена:
Код:
python ldapdomaindump.py -u <DOMAIN>\\<USER> -p <PASS> -d <DELIMITER> <DC-IP>
# Пример:
python ldapdomaindump.py -u example.com\\john -p pass123 -d ';' 10.100.20.12) После завершения дампа получите список пользователей с флагом PASSWD_NOTREQD, используя следующую команду:
Код:
grep PASSWD_NOTREQD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3}'
В качестве альтернативы можно использовать следующую команду PowerShell на контроллере домена, чтобы получить список пользователей с "ненужным" паролем:
Код:
Import-Module ActiveDirectory
Get-ADUser -Filter {UserAccountControl -band 0x0020}
9. Хранение паролей с использованием обратимого шифрования.
Некоторым приложениям требуется пароль пользователя в виде обычного текста для выполнения аутентификации, поэтому в Active Directory поддерживается хранение паролей с использованием обратимого шифрования <- тут ссылка на доку майкрософт, если что.Хранение паролей таким способом практически идентично хранению их в виде обычного текста. Это ужасная идея, но это реальность.
Единственным смягчающим фактором здесь является то, что злоумышленник должен иметь возможность получить данные пароля с контроллера домена, чтобы прочитать пароль в виде обычного текста. Это означает наличие либо:
- Права на выполнение операции DCSYNC (например, через Mimikatz)
- Доступ к файлу NTDS.DIT на контроллере домена
Как проверить:
Оба метода уже подразумевают полную компрометацию домена AD, так что на самом деле это не такая уж катастрофа.
Без этого невозможно узнать, у каких пользователей хранятся пароли с использованием обратимого шифрования. И даже если бы мы знали, какие из них, мы не смогли бы вытащить пароли, если у нас нет таких высоких привилегий, что мы практически уже владеем доменом AD.
Итак, чтобы проверить эту уязвимость, мы должны выгрузить файл NDTS.DIT с контроллера домена и извлечь из него хэши . Только тогда мы сможем увидеть, у каких пользователей пароли хранятся с использованием обратимого шифрования - их пароли будут просто распечатаны в виде обычного текста.
Обратите внимание, что мы также можем получить пароль в виде простого текста, используя Mimikatz, работающий в контексте пользователя с высокими привилегиями (который может выполнять DCSYNC).
Вот команда Mimikatz, которая сделает это:
Код:
mimikatz # lsadump::dcsync /domain:<DOMAIN>
# Пример:
mimikatz # lsadump::dcsync /domain:example.com
Я использовал флаг /user: чтобы вам было лучше видно, где можно найти пароль в открытом виде.
В любом случае пароли никогда не должны храниться в виде обычного текста. Эта уязвимость дает злоумышленникам, скомпрометировавшим домен AD (например, APT), и высокопривилегированным инсайдерам (например, администраторам домена) мгновенный доступ к паролям уязвимых пользователей в виде простого текста.
10. Хранение паролей с использованием LM хэшей
Другая уязвимость, которая обычно проявляется в Active Directory, - это хранение паролей в виде хэша LM.LM-хэш - это старый устаревший метод хранения паролей, который имеет следующие недостатки:
- Длина пароля ограничена 14 символами.
- Пароли длиной более 7 символов делятся на две части, и каждая половина хешируется отдельно.
- Все символы нижнего регистра перед хешированием преобразуются в верхний регистр.
Как проверить:
Эта проблема, как правило , выявляется после того , как домен скомпрометирован и NTDS.dit файл извлечен. Но и во время теста вы также можете её обнаружить.Вот краткий вид хешей LM и NTLM:
Если для части LM установлено значение, равное «aad3b435b51404eeaad3b435b51404ee» (пустая строка), значит, юзер защищен. Если отличное, то уязвим.
Более массовый анализ вы можете использовать с помощью этой команды (она выводит всех уязвимых юзеров):
Код:
grep -iv ':aad3b435b51404eeaad3b435b51404ee:' dumped_hashes.txt
11. Аккаунты, уязвимые к AS-REP Roasting'y.
Эта уязвимость очень похожа на Kerberoasting, но в этом случае атака злоупотребляет учетными записями пользователей, для которых не требуется предварительная аутентификация Kerberos.
Проще говоря, уязвимы пользователи домена с установленным флагом DONT_REQ_PREAUTH.
Вот подробная статья о уязвимости AS-REP:
Как проверить
Подобно Kerberoasting, эта атака была автоматизирована с помощью нескольких инструментов (например , Impacket или Rubeus ). Но есть некоторые тонкие различия.Чтобы протестировать AS-REP, нам не нужно знать какие-либо учетные данные пользователя домена! Единственное, что нам нужно знать, это то, какие пользователи уязвимы, найдя их следующей командой:
setspn -T domain.com -Q */*
Если у нас что-то не получилось, тогда мы можем попробовать список слов с именами пользователей, как в этом примере, с Impacket:
Код:
GetNPUsers.py <DOMAIN>/ -usersfile <USERLIST.TXT> -format [hashcat|john] -no-pass
# Пример:
GetNPUsers.py example.com/ -usersfile userlist.txt -format hashcat -no-passС другой стороны, если у нас есть какие-либо учетные данные пользователя домена с низким уровнем привилегий, мы можем сразу получить список уязвимых пользователей вместе с их хэшами Kerberos AS-REP. Вот как это сделать:
Код:
GetNPUsers.py <DOMAIN>/<USER>:<PASS> -request -format [hashcat|john]
# Пример:
GetNPUsers.py example.com/john:pass123 -request -format hashcat
[LEFT]Если мы получим хэши, нам есть о чем сообщить заказчику, и мы можем попытаться их взломать.
Вот пример с Hashcat, использующим атаку по словарю для взлома хэшей Kerberos AS-REP:
[/SIZE]
hashcat -m 18200 -a 0 hashes.txt wordlist.txt
# Быстрее, но длина до 31 символа:
hashcat -m 18200 -a 0 -O --self-test-disable hashes.txt wordlist.txt
[SIZE=4]
В качестве альтернативы можно использовать следующую команду PowerShell на контроллере домена для получения списка пользователей, которым не требуется предварительная проверка подлинности Kerberos:
Import-Module ActiveDirectory
Get-ADuser -filter * -properties DoesNotRequirePreAuth | where {$._DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name
12. Слабая политика паролей домена
Политика паролей - это тема, которая со временем развивается. Есть много разных взглядов и мнений о том, как должна выглядеть идеальная политика паролей.
Некоторые организации применяют длинные и сложные пароли, часто меняя их. Некоторые из них более доброжелательны, а некоторые могут даже полностью игнорировать принудительное использование надежных параметров пароля и просто сосредоточиться на усилении компенсирующего контроля в своей внутренней среде в целом, так что компрометация учетной записи имеет очень незначительное влияние.
Каждый подход, безусловно, имеет свои преимущества и недостатки, но, как тестеры на проникновение, мы должны придерживаться чего-то разумного и общепринятого, даже если клиенты в конечном итоге могут сделать свой собственный выбор.
Например, CIS Benchmark рекомендует следующую политику паролей Active Directory:
- Minimum password length: 14
- Enforce Password History: 24
- Maximum password age: 60 or fewer days
- Minimum password age: 1 or more
- Password must meet complexity: Enabled
- Store passwords using reversible encryption: Disabled
- Account lockout threshold: Up to 10, but not 0
- Account lockout duration (minutes): 15 or more minutes
- Account lockout observation window (minutes): 30 minutes
Как проверить:
Чтобы перечислить политику паролей, нам не нужны какие-либо особые привилегии - это может сделать любая учетная запись домена с низким уровнем привилегий.Вот как мы можем отобразить политику паролей AD с машины Windows, присоединенной к домену:
net accounts /domainВот как мы можем отобразить политику паролей AD из Linux (например, Kali Linux) с помощью команды polenum:
[/SIZE]
polenum --username <USER> --password <PASS> --domain <DC-IP>
# Пример:
polenum --username john --password pass123 --domain 10.10.51.11
[SIZE=4]
В качестве альтернативы можно использовать enum4linux:
enum4linux -P -u <USER> -p <PASS> -w <DOMAIN> <DC-IP>
# Пример:
enum4linux -P -u john -p pass123 -w dom.local 172.21.1.60
Последняя четвёртая часть выйдет в течение трёх суток.
