Практика управления информационной безопасностью: pentest

Повышение привилегий пользователя до уровня администратора домена Windows

Введение

Хорошая система управления информационной безопасностью (СУИБ) требует регулярной оценки своей эффективности. Существуют разные методики подобных оценок, одной из разновидностей которых является т.н. «тест на проникновение» или pentest – санкционированная симуляция хакерской атаки на информационную систему с целью выявления уязвимостей в её защите до того, как их обнаружит реальный злоумышленник. При этом могут использоваться любые доступные в реальной жизни хакерские инструменты, эксплойты, методы и т.д.

Данная статья содержит описание одной из таких антихакерских практик, ставившей своей целью повышение полномочий рядового пользователя домена Microsoft Windows до уровня администратора домена. В основу статьи был положен отчет о результатах теста, реализованного на практике. По соображениям конфиденциальности вся информация, позволяющая идентифицировать место проведения (имена домена и хостов, учетных записей и т.д.) удалена либо изменена. В статье показаны основные методики, для лучшего понимания я привел теоретические основы и используемые уязвимости конкретных версий операционных систем, а также общие рекомендации по защите. И хотя большинство указанных версий ОС Windows на момент публикации будут считаться устаревшими, статья может быть полезна начинающим системным администраторам для лучшего понимания методов защиты учётных данных в среде Windows.

Описание объекта тестирования

Объект тестирования достаточно стандартный – информационная система небольшой (менее 200 сотрудников) компании, специализирующейся на разработке ПО. Внутренняя сеть компании также типична: коммутируемый Gigabit Ethernet, домен Microsoft Windows (будем называть его CORP.LOCAL). Внутренние хосты разделены на IP- подсети на основании своей функциональной принадлежности (как то: группа разработчиков, инженеры по качеству, отдел управления кадрами, бухгалтерия, маркетинг, топ-менеджемент, facilities и т.д.), вся сегментация сделана на L3-коммутаторе. Также имеется выделенный в отдельную IP-подсеть парк внутренних серверов, содержащий: два контроллера домена Windows Server 2008 с интегрированной DNS, внутренний почтовый сервер под управлением Exchange, файл-сервер, терминальный сервер и некоторые другие вспомогательные сервера под управлением Windows и Linux. Отдельно стоит отметить тестовую лабораторию с парком машин под управлением разных версий Microsoft Windows (как десктопных, так и серверных) и предназначенных для тестирования разрабатываемого ПО. Доступ к хостам тестовой лаборатории имеют все сотрудники. Основная версия настольной ОС – Windows 7. На настольных компьютерах и серверах установлено плохо настроенное антивирусное ПО разных производителей (от компаний Symantec, Kaspersky и Trend Micro, почему плохо настроенное – об этом позже).

Модель нарушителя

Нарушитель – внутренний сотрудник, имеющий непривилегированную пользовательскую учетную запись в домене, настольный компьютер, физический доступ к тестовым компьютерам, (возможно, имеет корпоративный ноутбук), но не имеющий ни на одном из них привилегий локального администратора. Также учетная запись нарушителя не имеет возможности менять настройки антивирусного ПО. Цель нарушителя – получить доступ, эквивалентный доступу администратора, к контроллеру домена и/или файловому серверу.

Как видим, и модель нарушителя, и описание компании достаточно типично.

Реализация атаки

Шаг 0. Сбор информации о внутренней сети

Итак, мы действуем от лица нарушителя. На данном шаге нам нужно собрать информацию о:

• внутренней адресации и разбиении на подсети
• именах и IP-адресах хостов, в первую очередь нас интересует список серверов
• использовании протокола NetBIOS.

Сначала с помощью утилиты ipconfig мы получаем IP-адреса серверов DNS:192.168.12.1 и 192.168.12.2. Т.к. служба DNS интегрирована с Active Directory, это даёт нам основания считать, что мы знаем IP-адреса контроллеров домена. Далее используя утилиту nslookup в интерактивном режиме мы пытаемся получить список всех хостов в зоне corp.local:

> ls –d corp.local > file

Фактически, эта команда инициирует полный трансфер зоны DNS, с сохранением её в file. Многие администраторы забывают настроить ограничения на трансфер зоны для внутренней сети, чем облегчают потенциальному злоумышленнику сбор сведений об инфраструктуре компании, подробнее см. [12].

Результат. Успех. Незащищенный трансфер зоны дал нам полный список имен внутренних хостов, включая сервера, и их IP-адресов. Используя утилиты nbtstat, telnet а также любой из распространенных сканеров уязвимостей нарушитель может собрать информацию о платформе, работающих службах, версии ОС на интересующих его хостах.

Шаг 1. Получение привилегий локального администратора

Теория. Для получения пароля локального администратора применяется атака на сохраненное в системном реестре значение хэш-функции этого пароля. Несмотря на то, что математически хэш-функция является необратимой, вычисление пароля возможно путем прямого перебора её значений совместно с атакой по словарю. В Windows исторически применяется два алгоритма вычисления парольной хэш-функции: устаревший алгоритм LM и более новый алгоритм NT (иногда также называемый NTLM). Хэш-функция LM является уязвимой в силу своей малой вычислительной сложности, что делает возможным перебор её значений даже на слабом компьютере. Наличие в реестре системы одновременно LM- и NT-хэшей пароля гарантируют злоумышленнику его взлом за приемлемое время. Значение хэша LM при настройках по-умолчанию сохраняется в реестре ОС Windows XP/2003, что делает эти системы особо привлекательными для хакера. Хэш-функция NT является вычислительно более сложной, однако, перебор её значений значительно упрощается тем, что для нее существуют доступные таблицы pre-calculated значений (т.н. Rainbow-таблицы) – они сводят вычисление значения хэш-функции к поиску искомого хэша среди pre-calculated значений.

Объект атаки. Хэши паролей в базе SAM (реестр). В нашем случае это все машины, к которым мы имеем физический доступ. В первую очередь, это наш рабочий десктоп, во вторую – хосты для выполнения тестов.

Реализация. С машинами, к которым есть физический доступ, проделываем следующую операцию: загружаемся с внешнего носителя (используя Windows Pre-installation Environment CD или Linux Live CD), монтируем системный раздел NTFS и копируем ветви реестра HKLM\SYSTEM и HKLM\SAM (файлы %WINDIR%\System32\Config\System и %WINDIR%\System32\Config\Sam соответственно). Особое внимание уделяем машинам под управлением Windows XP\Windows 2003, на которых вероятно нахождение LM-хэша. Для дампа паролей из скопированных файлов реестра используем используем инструменты [1], [2] (все ссылки в конце статьи). Результат:



Последняя строчка содержит искомый NT-хэш локального администратора. На хостах из тестовой лаборатории (назовем эти хосты LAB1 и LAB2) находим ненулевой LM-хэш:





Итак, нами получены NT- и LM-хэши. Но как восстановить из них пароль? Для этого воспользуемся теми же инструментами [1], [2] а также он-лайн сервисами реверса хэша [8] — [11]:



Примечание: реальный пароль состоял из названия компании с небольшим модификатором и быстро сломался под атакой по словарю).

Результат. Успех. Получены пароли (пусть они будут «Pa$$word1» и «Pa$$word2») учетной записи локального администратора с нашего рабочего десктопа и двух тестовых компьютеров. Но помогут ли они получить права администратора домена? Об этом далее.

Шаг 2. Получение учетных данных администратора домена

Теория. В большинстве случаев для этого достаточно получить значение NT-хэша пароля администратора домена. Это связано с тем, что при проверке пользователя по протоколу NTLM аутентифицируемая система предъявляет аутентификатору только NT-хэш, а проверки пароля не происходит. NT-хэш может быть получен из т.н. хранилища LSA путем обращения к т.н. Logon-сессии администратора (Logon-сессия — специальной область данных, создаваемая процессом Winlogon, где хранится имя пользователя, домен входа и значение NT-хэша пароля, все вместе это называется LSA-secret). Этот NT-хэш используется процессом NTLMSSP при аутентификации по протоколу NTLM. Logon-сессия сохраняется все время пока учетная запись залогинена в систему. Также NT-хэш можно перехватить из NTLM-сессии аутентификации администратора. Кроме того, получение пароля администратора возможно из кэша Domain Cached Credentials (DCC). DCC — это локальный кэш, который заполняется при успешном входе пользователя в домен. Назначение кэша DCC — иметь возможность произвести аутентификацию пользователя при недоступности контроллера домена.

Объекты атаки:

• Хэши DCC (ветка реестра HKLM\Security).
• Logon-сессия администратора домена (LSA-secret).
• Перехват NTLM-сессии (не рассматриваем из-за большей практической сложности).

Практика. Многие Windows-администраторы для выполнения разного рода операций на компьютерах пользователей используют учетную запись администратор домена. При этом её данные попадают в кэш DCC. Поэтому сначала попытаемся получить пароль из кэша DCC. Заходим на нашу рабочую станцию, сохраняем ветвь реестра HKLM\Security и импортируем её в [1]. Т.к. у нас имеется пароль локального администратора, загружать машину с внешнего носителя для сохранения реестра уже не нужно:



В кэше лежат данные паролей трех учетных записей. Последняя учетная запись (***user) нас не интересует, вторая учетная запись искомых привилегий не имеет, а вот пользователь shadmin похож на искомого администратора. К сожалению, алгоритм MS-CACHE2 имеет большую вычислительную сложность и атака прямым перебором на него неэффективна. Функция MS-CACHEv2 содержит «вычислительный секрет» — salt (в качестве “salt” используется имя учетной записи) что делает её защищенной от атаки по Rainbow-таблицам. Однако, в будущем возможно появление таблиц значений хэша для стандартных учетных записей – “Administrator”, «Администратор» и т.д. Ради интереса отправляем найденный «кэш-хэш» в облачный сервис [8] — [11] (о результатах и эффективности таких сервисов в конце статьи). Пока «облако думает» пытаемся найти другие DCC. Анализируем список хостов, полученный на шаге 0, проверяем, на какие сервера мы можем зайти под локальным администратором используя пароли, полученные на шаге 1. Т.к., на контроллере домена локальный администратор заблокирован, а почтовый сервер обычно лучше защищен, экспериментировать надо с второстепенными серверами. В нашем случае в списке серверов был найден сервер с неприметным именем Upd. Вход с найденным на шаге 1 паролем “Pa$$word2” оказывается успешным. Обнаруживаем, что на хосте Upd:

1. Не установлено антивирусное ПО.
2. На нём работает Apache, являющийся сервером управления для корпоративного антивируса (это значит, что там же есть пароль учетной записи, используемой для удаленной установки антивирусного ПО и теоретически его можно оттуда вытащить).
3. На хосте не ведется аудит неудачных попыток входа.
4. Версия ОС – Windows 2008 R2.

Сделав дамп реестра HKLM\Security мы получаем DCC-хэш учетной записи СORP.LOCAL\Administrator (и ряда других):



Теоретически, можно попробовать подобрать пароль к Administrator через облачный сервис. Однако, как я уже упоминал выше, атака перебором на MS-CACHEv2 бесполезна (хотя, возможно, через пару лет ситуация изменится). Оставляем в покое DCC и переходим к поиску Logon-сессий. Проверяем, кто из пользователей вошел в систему на хосте Upd:



Видим, что на машине Upd висят две неактивные сессии – администратора и уже знакомого нам пользователя Shadmin, а значит, мы можем получить NT-хэши их паролей путем кражи LSA-secret. Это ключевой момент, определивший успех всей атаки. Для кражи хэша используем эксплойт Lslsass [3]. Для его выполнения необходимы права локального администратора (вернее, права на отладку процессов), которые у нас уже есть. Получаем список секретов LSA (в формате «домен\учетная запись:LM-хэш:NT-хэш:::»):

lslsass v1.0 - Copyright (C) 2010 Bjorn Brolin, Truesec (www.truesec.com)
Found Lsass pid: 520
Lsass process open
Found possible primary token
Found real token
UPD\Administrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>:::
Found possible primary token
Found possible primary token
Found possible primary token
Found real token
UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e:::
Found possible primary token
Found real token
UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e:::
Found possible primary token
Found real token
CORP.LOCAL\UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b:::
Found possible primary token
Found real token
CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b:::
Found possible primary token
Found real token
CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b:::
Found possible primary token
Found real token
CORP.LOCAL \Administrator::00000000000000000000000000000000: <b> c690e441dc78bc5da8b389e78daa6392 </b>:::
Found possible primary token
Found real token
CORP.LOCAL \shadmin::00000000000000000000000000000000: 
 <b> 5794cba8b464364eacf366063ff70e78 </b> :::

Выделенные болдом строки содержат искомые парольные хэши. Также обратите внимание на выделенный курсивом хэш в шестой строчке. Где-то мы его уже видели, правда?

Результат. Успех. У нас на руках NT-хэш пароля учетной записи администратора домена. Но какая польза от хэша, если восстановление исходного пароля по нему за приемлемое время невозможно? Об этом в следующем шаге.

Шаг 3. Обманываем NTLM-сессию аутентификации

Теория. Windows никогда не использует для аутентификации пароль в чистом виде, аутентифицируемая система всегда предъявляет хэш. Отсюда возникает идея: заменив имя пользователя, домен входа и NT-хэш в Logon-сессии зашедшего в систему пользователя на соответствующие значения доменного администратора мы можем аутентифицироваться по протоколу NTLM перед удаленной системой как администратор домена. Данная атака [7] возможна только при аутентификации по протоколу NTLM. Несмотря на широкое распространение протокола Kerberos, NTLM является единственным возможным способом аутентификации клиента, при доступе к сетевой шаре не по символьному имени, а по IP-адресу [13].

Объект атаки. Logon-сессия локального администратора.

Практика. Существует несколько доступных эксплойтов, позволяющих реализовать атаку на платформе Windows Server 2008 x86 и x64. Основным является эксплойт Windows Credentials Editor [4]. Для осуществления атаки заходим на хост LAB2, используя учетные данные “Administrator”\”Pa$$word2”. С помощью [4] подменяем имя учетной записи, домен входа и данные NT-хэша в Logon-сессии на соответствующие значения Shadmin, полученные нами на предыдущем шаге:



Имя учетной записи администратора домена и её NT- хэш передается команде wce в качестве аргумента из командной строки. Результат — хэш успешно изменен. Замечу, что членство пользователя в группе и токен доступа при атаке не изменяются:



Мы по-прежнему локальный Administrator, замазанное зеленым имя хоста на скриншоте выше — LAB2. Однако, при NTLM-аутентификации удаленной системе будет предъявлено имя домена CORP.LOCAL, имя пользователя Shadmin и хэш от пароля Shadmin. Вот дамп одного сетевого пакета, содержащего security blob сессии NTLM:



Замазано зеленым имя домена (CORP.LOCAL) и имя хоста (LAB2 ) ), предъявлена учетная запись – Shadmin. Теперь пытаемся подключиться к корневому разделу системного тома на контроллере домена командой net use используя IP-адрес контроллера домена:



Успешно. Для проверки доступа я создал в корне текстовый файлик (найдите его на скриншоте). Создав на диске контроллера домена батник с нужной нам последовательностью команд, мы можем, используя [5], выполнить на контроллере домена нужную операцию (например, добавить пользователя в группу администраторов домена). Операция будет выполнена с правами учетной записи Shadmin. Для иллюстрации создаем на удаленном хосте простой командный файл, добавляющий локального пользователя:

net user TstUsr Pa$$word /add

Удаленно запускаем его с хоста LAB2:



Он будет выполнен в удаленной системе 192.168.13.125 с привилегиями пользователя нашей текущей сессии – shadmin (т.е., администратора домена). Проверяем:



Второй вывод команды net user показывает нового пользователя. Несмотря на невозможность запуска таким образом приложений, требующих интерактивного взаимодействия с пользователем (например, оснасток MMC), можно выполнить широкий спектр действий с помощью скриптов.

Результат. Успех. Получен доступ к файловой системе и shell контроллера домена.

Резюме

Вкратце цепочка атаки выглядела следующим образом: Сбор информации о структуре сети -> Получение пароля локального администратора -> Использование этого пароля для входа на один из второстепенных серверов -> Кража «оставленных без присмотра» учетных данных администратора домена -> Модификация своей Logon-сессии и повышение привилегий до нужного уровня.

Успеху атаки способствовали:

1. Слабая защита зоны DNS от трансфера на недоверенные хосты.
2. Слабая парольная политика. На большинстве компьютеров домена для учетной записи локального администратора использовался одинаковый пароль, уязвимый к атаке по словарю.
3. Отсутствие либо слабая настройка антивирусного ПО на критичных хостах.
4. Слабая защита парольных хэшей – две неактивные администраторские Logon-сессии на хосте Upd, наличие хэшей LM в базе SAM.
5. Неудовлетворительная политика аудита.

На основании этого можно вывести общие рекомендации по защите:

0. Тщательно скрывать внутреннюю структуру сети от возможных злоумышленников. Так, у пользователей не должно быть возможности получить полное содержимое файла зоны DNS. Недоверенных пользователей (это могут быть, например, стажеры, сотрудники, у которых не закончился испытательный срок и т.д.) имеет смысл переносить в отдельную подсеть, используя NAT для подмены адресов (включая, например, модификацию DNS-ответов).

1. Правильная политика назначения паролей локального администратора. Пароль локального администратора должен быть разным на хостах, имеющих разную степень защищенности от НСД. Компрометация пароля локального администратора на любом из хостов домена должна сводить к минимуму возможность использования злоумышленником этого пароля.

2. Хранение LM-хэша в SAM должно быть запрещено политиками безопасности.

3. Не надо использовать в качестве части пароля администратора название компании или её домена ) Это затруднит злоумышленнику атаку по словарю. Но даже используя сложный пароль, не забывайте самостоятельно и регулярно проверять его хэш на стойкость используя онлайн-сервисы.

4. Не рекомендуется выполнять рутинные операции на компьютерах домена из-под учетной записи администратора домена. Это защитит учетную запись от перехвата данных Logon-сессии и от попадания хэша пароля в DCC-кэш.

5. Взять за правило не оставлять без присмотра Logon-сессию администратора домена. Best practice: закончил работу – разлогинься.

6. Утилиты подмены LSA достаточно малочисленны. Имеет смысл отслеживать их эволюцию и проверять их успешное детектирование корпоративным антивирусным ПО.

7. У пользователя, даже имеющего права локального администратора, не должно быть возможности изменять настройки корпоративного антивируса. Выключение службы антивируса на рабочих станциях домена должно приводить к оповещению администратора домена (в этом смысле в ходе теста неплохо отработал Symantec Endpoint Protection).

Дополнение 1. Поведение антивирусного ПО

На компьютерах компании использовалось антивирусное трех видов: KAV, актуальный на момент проведения теста Symantec Endpoint Protection и устаревший продукт от Trend Micro. В большинстве случаев использованные в ходе атаки инструменты определялись как Hack Tool/Rootkit/Trojan. KAV без предупреждения удалял их, а SEP (даже выключенный) выдавал предупреждение и перемещал в карантин не давая возможности запустить. Однако наличие прав локального администратора позволяет отключить KAV, а защита SEP была обойдена путем ручного прописывания пути-исключения для проверки, опять-таки, с использованием учетной записи локального администратора. Установленный на некоторых хостах антивирус от Trend Micro не запуск эксплойтов реагировал никак.

Дополнение 2. Эффективность использования онлайн-сервисов проверки хэша

Для проверки стойкости хэшей паролей существует множество онлайн-сервисов. Они позволяют работать с наиболее распространенными хэшами – LM, NTLM, MD4, MD5, WPA, с хэшами, использующими salt и т.д. Для проверки хэша используется прямой перебор с использованием вычислительной мощности современных GPU, перебор по словарю, гибридные атаки и т.д. Единожды вскрытый хэш может пополнить базу и использоваться в дальнейшем. Сервис может быть бесплатным для проверки короткого (менее 8 символов) пароля или брать небольшое вознаграждение. В процессе теста я использовал четыре таких сервиса, ссылки приведены в конце статьи. Я отправил несколько найденных на шаге 2 хэшей и через 15 месяцев получил от сервиса On-line Hash Crack [9] уведомление об успешном восстановлении одного из них )

Ссылки

Использованные инструменты

[1] Cain & Abel — a password recovery tool for Microsoft Operating Systems. It allows easy recovery of several kind of passwords by sniffing the network, cracking encrypted passwords using Dictionary, Brute-Force and Cryptanalysis attacks, recording VoIP conversations, decoding scrambled passwords, recovering wireless network keys, revealing password boxes, uncovering cached passwords and analyzing routing protocols.
[2] L0pht Crack.
[3] Lslsass exploit. Dumps active logon session password hashes from the lsass process.
[4] Windows Credentials Editor post-exploit. Инструмент для изменения Logon-credentials.
[5] PsExec из комплекта PS Tools

Подробные описания уязвимостей

[6] Серия статей «Эффективное получение хэша паролей в Windows» на сайте www.securitylab.ru
[7] Pass-the-Hash, описание атаки на удаленную систему путем предоставления ей скомпроментированного хэша.

Облачные сервисы взлома хэшей
[8] Question-defense.com (кажется, уже неработоспособен на момент публикации ( )
[9] www.onlinehashcrack.com
[10] www.cloudcracker.com
[11] On-line hash killer

Дополнительные материалы

[12] Безопасность и тюнинг DNS в Windows Server
[13] Kerberos is not used when you connect to SMB shares by using IP address