повышение прав администратора windows 7
Как сделать себя администратором в Windows 7
Чтобы получить права администратора в Windows 7, необходимо внести изменения в соответствующие параметры операционной системы (ОС). Всего есть четыре способа назначить другого пользователя админом. Выполнение поставленной задачи не требует установки стороннего программного обеспечения.
Активация возможности передачи прав в редакторе групповых политик
По умолчанию в системе каждый пользователь может обладать повышенными полномочиями, для этого основной администратор должен выдать такое право другой учетной записи. Но если в групповые политики были внесены изменения, функция отключится.
Активировать соответствующую опцию можно следующим образом:
Как дать пользователю права администратора в Windows 7
Включение юзеров в список суперпользователей производится с помощью встроенных средств ОС. Поменять тип учетной записи способен только профиль, который имеет наивысшие права доступа.
Важно! Сделать самого себя администратором в Windows 7 нельзя.
Через «Панель управления»
Настроить права доступа других аккаунтов можно через « Панель управления ». Для этого необходимо:
Обратите внимание! Если на компьютере нет второго профиля, предварительно потребуется создать аккаунт.
С помощью «Командной строки»
Включить учетную запись администратора в Windows 7 другому юзеру можно посредством выполнения определенной команды в консоли. Пошаговое руководство:
В утилите «Локальные пользователи и группы»
В системе есть специальное меню для управления аккаунтами, в котором можно произвести создание админа. Получение повышенных привилегий производится следующим образом:
Посредством редактирования системного реестра
Поменять права аккаунта можно через редактор реестра, внеся правки в соответствующие параметры. Пошаговое руководство:
Важно! Если параметра из списка в реестре не оказалось, необходимо создать вручную через контекстное меню.
Заключение
Неопытным пользователям для выполнения поставленной задачи рекомендуется вносить изменения через « Панель управления » или утилиту « Локальные пользователи и группы ». Применение редактора реестра и « Командной строки » требует определенных знаний от юзера.
Основы повышения привилегий в Windows
Решил для себя и для тех, кому будет полезно, собрать все что знаю, но не помню по теме, в этой статье. Делитесь советами. Основным источником этой статьи является эта.
Я вольно перевел и добавил немного от себя, того, что насобирал и узнал из других источников.
В общем, тут представлены способы, которые помогут нам достигнуть цели повышения привилегий.
Отправной точкой для этой небольшой статьи является непривилегированная оболочка (учетная запись). Возможно, мы использовали эксплойт или провели атаку и получили эту оболочку.
В принципе, в начальный момент времени мы не понимаем машину: что она делает, к чему она подключена, какой уровень привилегий у нас есть или даже какая это операционная система.
Сначала нам нужно получить нужную нам информацию, чтобы понять, где мы вообще находимся и что имеем:
Эта команда позволяет определить, как из нее видно, Название и версию ОС. Можно выполнить ее и без параметров, тогда вывод команды будет более полным, но нам достаточно и этого.
Далее важно узнать имя машины и имя пользователя, под которым мы подключились.
Сначала глянем на имеющиеся интерфейсы и таблицу маршрутизации.
где
/query — Вывод данных о всех запланированных задачах,
/fo LIST — Вывод в список.
/v — Вывод подробных сведений о задании.
Следующая команда связывает запущенные процессы с запущенными службами.
где,
/SVC — Отображение служб для каждого процесса.
Также посмотрим список запущенных служб Windows.
Полезно также посмотреть информацию о драйверах скомпрометированной системы.
Далее хочется упомянуть о, наверное, самой полезной команде Windows — wmic. Команда WMIC (Windows Management Instrumentation Command) используется для получения сведений об оборудовании и системе, управления процессами и их компонентами, а также изменения настроек с использованием возможностей инструментария управления Windows (Windows Management Instrumentation или WMI). Хорошее описание.
К сожалению, некоторые конфигурации Windows по умолчанию не разрешают доступ к WMIC, если пользователь не входит в группу Администраторов (что действительно хорошая идея). Любая версия XP не позволяла доступ к WMIC с непривилегированной учетной записи.
Напротив, Windows 7 Professional и Windows 8 Enterprise по умолчанию позволяли пользователям с низкими привилегиями использовать WMIC.
По обычаю — параметры программы:
Прежде чем идти дальше стоит пробежаться по собранной информации. Также стоит обратить внимание на установленные в системе патчи, так как любая информация о дырах в системе даст нам дополнительную опору для повышения своих привилегий. По номеру HotFix можно поискать уязвимости по повышению привилегий.
Далее мы рассмотрим автоматическую установку. Если существует необходимость установки и настройки большого парка машин, то как правило, технический персонал не будет перемещаться от машины к машине для настройки персонального каждой. Существует несколько решений для автоматической установки. Для нас не так важно, что это за методы и как они работают, а важно то, что они оставляют конфигурационные файлы, которые используются для процесса установки, содержащие много конфиденциальной информации, такой как ключ продукта операционной системы и пароль администратора. Что нас больше всего интересует, так это пароль администратора, который мы можем использовать для повышения наших привилегий.
Как правило, это следующие каталоги:
Данные файлы содержат пароли в открытом виде или кодировке BASE64.
Примеры:
Sysprep.inf — пароль в открытом виде.
«
Sysprep.xml — пароль в кодировке base64.
«
Unattended.xml — пароль в кодировке base64.
Также для хостов, подключенных к домену можно поискать файл Group.xml, который содержит зашифрованный AES256 пароль, но который можно расшифровать, т.к. ключ выложен на msdn (https://msdn.microsoft.com/en-us/library/cc422924.aspx) и других источниках. Но это в случае, если используется политика создания локальных пользователей на хостах или, например, задании пароля локальному Администратору.
Например, у меня лежит тут:
Открыв его, ищем параметр “cpassword”.
Далее нужно расшифровать данную последовательность. Используем, например, CrypTool. Сначала раскодируем Base64.
Особенности Base64 в том, что его длина должна быть кратна 4. Поэтому считаем блоки по 4, и если в последнем блоке не хватает символов, то недостающие дописываем символами «=».
У меня вышло 2 «=».
Далее расшифруем. Применяя тот ключ, что выше.
Убираем лишние точки, разделяющие знаки и получаем пароль.
В дополнение к Group.xml вот несколько других файлов предпочтений политики, которые могут иметь дополнительный набор атрибутов «cPassword”:
Для того, чтобы иметь возможность использовать это, мы должны проверить, что оба раздела реестра установлены, и если это так, мы можем получить SYSTEM shell. Проверим:
В состав Metasploit входит специальный модуль exploit/windows/local/always_install_elevated, который создает MSI-файл со встроенным в него специальным исполняемым файлом, который извлекается и выполняется установщиком с привилегиями системы. После его выполнения msi-файл прекращает установку, чтобы предотвратить регистрацию действия в системе. К тому же если запустить установку с ключом /quiet, то даже не выведется ошибка.
Ну и немного полезных команд по поиску по системе:
Команда ниже будет искать в файловой системе имена файлов, содержащие определенные ключевые слова. Вы можете указать любое количество ключевых слов.
Поиск определенных типов файлов по ключевому слову, эта команда может генерировать много выходных данных.
Аналогично две команды ниже могут быть использованы для grep реестра по ключевым словам, в данном случае „password“.
На данный момент у нас уже есть достаточно, чтобы получить системный шел. Но есть еще пара направленbй атаки для получения желаемого результата: мы рассмотрим службы Windows и разрешения для файлов и папок. Наша цель здесь — использовать слабые разрешения для повышения привилегий сеанса.
Мы будем проверять много прав доступа, в этом нам поможет accesschk.exe, который является инструментом от Microsoft Sysinternals Suite. Microsoft Sysinternals содержит много отличных инструментов. Пакет можно загрузить с сайта Microsoft technet (https://docs.microsoft.com/ru-ru/sysinternals/downloads/sysinternals-suite).
Мы можем проверить необходимый уровень привилегий для каждой службы с помощью accesschk.
Мы можем видеть разрешения, которые имеет каждый уровень пользователя.
Accesschk может автоматически проверять, есть ли у нас доступ на запись к службе Windows с определенным уровнем пользователя. Как правило, как пользователь с низкими привилегиями, мы хотим проверить „Пользователей“. Удостоверьтесь, что проверили, к каким группам пользователей вы принадлежите.
-c В качестве имени указана служба Windows, например ssdpsrv (укажите “*” для вывода на экран всех служб)
-d Обрабатывать только каталоги
-e Выводить только явным образом заданные уровни целостности (только для ОС Windows Vista)
-k В качестве имени указан раздел реестра, например hklm\software
-n Выводить только объекты, не имеющие правил доступа
-p В качестве имени указано имя или идентификатор процесса (PID), например cmd.exe (укажите в качестве имени “*”, чтобы вывести на экран все процессы)
-q Опустить заголовок
-r Выводить только объекты, к которым есть право доступа на чтение
-s Рекурсивная обработка
-v Выводить подробную информацию
-w Выводить только объекты, к которым есть право доступа на запись
Также есть еще одна интересная команда:
Позволяет найти запись в реестре о файле, который запускался автоматически, но сейчас уже отсутствует в системе. Запись могла остаться, если например, сервис был неправильно удален. При каждом запуске система безуспешно пытается запустить этот файл. Этой ситуацией также можно воспользоваться для расширения своих полномочий. Просто на место этого файла можно подставить наш.
Далее рассмотрим две уязвимости:
Первая: реплицируем результаты поста, написанного Parvez из GreyHatHacker; „Elevating privileges by exploiting weak folder permissions“ (http://www.greyhathacker.net/?p=738).
Этот пример является частным случаем угона dll. Программы обычно не могут функционировать сами по себе, у них есть много ресурсов, которые им нужно подключить (в основном dll, но и собственные файлы). Если программа или служба загружает файл из каталога, к которому у нас есть доступ на запись, мы можем злоупотребить этим, чтобы запустить оболочку с привилегиями, под которыми работает программа.
Как правило, приложение Windows будет использовать предопределенные пути поиска, чтобы найти dll, и он будет проверять эти пути в определенном порядке. Dll угон обычно происходит путем размещения вредоносных dll по одному из этих путей. Эта проблема может быть устранена путем указания приложению абсолютных путей к необходимой dll.
Порядок поиска dll:
Так как dll не существует, мы в конечном итоге прохождения всех путей поиска. Как пользователь с низким уровнем привилегий у нас немного шансов положить вредоносный dll в п. 1-4, 5. Но если у нас есть доступ на запись в любой из каталогов, то наши шансы на победу велики.
Давайте посмотрим, как это работает на практике, для нашего примера мы будем использовать IKEEXT (модули ключей IPSec IKE и AuthIP) сервис, который пытается загрузить wlbsctrl.dll.
Любой каталог в „C:\“ даст доступ на запись для аутентифицированных пользователей, это дает нам шанс.
F — полный доступ.
(OI) — наследование объектами.
(CI) — наследование контейнерами.
(IO) — только наследование.
(NP) — запрет на распространение наследования.
(I)- наследование разрешений от родительского контейнера.
Прежде чем перейти к действию, необходимо проверить состояние службы IKEEXT. В этом случае мы можем увидеть, что он установлен на „AUTO_START“!
Теперь мы знаем, что у нас есть необходимые условия, и мы можем создать вредоносную dll и перехвата оболочки!
После передачи evil.dll на наш целевой компьютер все, что нам нужно сделать, это переименовать его в wlbsctrl.dll и переместить в „C:\Python27“. Как только это будет сделано, нам нужно терпеливо ждать перезагрузки машины (или мы можем попытаться принудительно перезагрузить), и мы получим системную оболочку.
После этого осталось только дождаться перезагрузки системы.
Для нашего последнего примера мы рассмотрим запланированные задачи. Опишу принцип, т.к. у всех могут быть разные случаи.
Находим процесс, службу, приложение запускаемое планировщиком задач от SYSTEM.
Проверяем права доступа на папку, где находится наша цель.
Ясно, что это серьезная проблема конфигурации, но еще хуже тот факт, что любой прошедший проверку Пользователь (аутентифицированный пользователь) имеет доступ на запись в эту папку. В этом примере мы можем просто перезаписать двоичный исполняемый файл файлом, сгенерированным в metasploit.
Можно закодировать дополнительно.
Теперь остается только загрузить вредоносный исполняемый файл и перезаписать его в папку выполняемого файла. Как только это будет сделано, мы можем спокойно идти спать и рано с утра получить системный шел.
Эти два примера должны дать нам представление об уязвимостях, которые необходимо искать при рассмотрении разрешений для файлов и папок. Потребуется время, чтобы изучить все пути binpath для служб windows, запланированные задачи и задачи автозапуска.
Напоследок пара советов по использованию accesschk.exe.
Найти все слабые разрешения для папок на диске.
Найти все слабые разрешения для файлов на диске.
Повышение привилегий в Windows-среде
Практика управления информационной безопасностью: 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. Сбор информации о внутренней сети
Итак, мы действуем от лица нарушителя. На данном шаге нам нужно собрать информацию о:
> 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 — иметь возможность произвести аутентификацию пользователя при недоступности контроллера домена.
В кэше лежат данные паролей трех учетных записей. Последняя учетная запись (***user) нас не интересует, вторая учетная запись искомых привилегий не имеет, а вот пользователь shadmin похож на искомого администратора. К сожалению, алгоритм MS-CACHE2 имеет большую вычислительную сложность и атака прямым перебором на него неэффективна. Функция MS-CACHEv2 содержит «вычислительный секрет» — salt (в качестве “salt” используется имя учетной записи) что делает её защищенной от атаки по Rainbow-таблицам. Однако, в будущем возможно появление таблиц значений хэша для стандартных учетных записей – “Administrator”, «Администратор» и т.д. Ради интереса отправляем найденный «кэш-хэш» в облачный сервис [8] — [11] (о результатах и эффективности таких сервисов в конце статьи). Пока «облако думает» пытаемся найти другие DCC. Анализируем список хостов, полученный на шаге 0, проверяем, на какие сервера мы можем зайти под локальным администратором используя пароли, полученные на шаге 1. Т.к., на контроллере домена локальный администратор заблокирован, а почтовый сервер обычно лучше защищен, экспериментировать надо с второстепенными серверами. В нашем случае в списке серверов был найден сервер с неприметным именем Upd. Вход с найденным на шаге 1 паролем “Pa$$word2” оказывается успешным. Обнаруживаем, что на хосте Upd:
Теоретически, можно попробовать подобрать пароль к Administrator через облачный сервис. Однако, как я уже упоминал выше, атака перебором на MS-CACHEv2 бесполезна (хотя, возможно, через пару лет ситуация изменится). Оставляем в покое DCC и переходим к поиску Logon-сессий. Проверяем, кто из пользователей вошел в систему на хосте Upd:
Видим, что на машине Upd висят две неактивные сессии – администратора и уже знакомого нам пользователя Shadmin, а значит, мы можем получить NT-хэши их паролей путем кражи LSA-secret. Это ключевой момент, определивший успех всей атаки. Для кражи хэша используем эксплойт Lslsass [3]. Для его выполнения необходимы права локального администратора (вернее, права на отладку процессов), которые у нас уже есть. Получаем список секретов LSA (в формате «домен\учетная запись:LM-хэш:NT-хэш. »):
Выделенные болдом строки содержат искомые парольные хэши. Также обратите внимание на выделенный курсивом хэш в шестой строчке. Где-то мы его уже видели, правда?
Результат. Успех. У нас на руках 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 контроллера домена.
Резюме
Успеху атаки способствовали:
На основании этого можно вывести общие рекомендации по защите:
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