Проблема конфиденциальности данных в Active Directory

Автор оригинала: Andy Green
  • Перевод


Я занимался тестированиями на проникновение с использованием PowerView и использовал его для извлечения информации о пользователях из Active Directory (далее – AD). В то время я делал акцент на сборе информации о членстве в группах безопасности, а затем использовал эту информацию, чтобы перемещаться по сети. В любом случае, AD содержит конфиденциальные данные о сотрудниках, некоторые из них действительно не должны быть доступны всем в организации. Фактически в файловых системах Windows существует эквивалентная проблема «Everyone», которая также может использоваться как внутренними, так и внешними злоумышленниками.

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

Active Directory — это корпоративный Facebook


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

Системные администраторы, конечно, знакомы со скриншотом ниже. Это интерфейс Active Directory Users and Computers (ADUC), где они устанавливают и редактируют информацию о пользователях и назначают пользователей в соответствующие группы.



AD содержит поля c именем сотрудника, адресом и номером телефона, поэтому он похож на телефонный справочник. Но там есть гораздо больше! На других вкладках также есть адрес электронной почты и веб-адрес, непосредственный руководитель и заметки.

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

Конечно, нет! Проблема усугубляется, когда данные высшего руководства компании доступны для всех сотрудников.

PowerView для всех


Здесь вступает в игру PowerView. Он предоставляет очень удобный интерфейс PowerShell для лежащих в основе (и запутанных) функций Win32, которые обращаются к AD. Короче говоря:
это делает получение полей AD таким же простым, как ввод очень короткого командлета.

Давайте возьмем пример сбора информации о сотруднице Cruella Deville, которая является одним из руководителей компании. Для этого используем командлет PowerView get-NetUser:



Установка PowerView не является серьезной проблемой – убедитесь в этом сами на странице github. И что более важно, вам не нужны повышенные привилегии для выполнения многих команд PowerView, таких как get-NetUser. Таким образом, мотивированный, но не очень технически подкованный сотрудник может начать ковыряться в AD без особых усилий.

Из приведенного выше скриншота видно, что инсайдер может быстро узнать много нового о Cruella. Вы тоже заметили, что в поле «info» раскрывается информация о личных привычках и пароле пользователя?

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

В Active Directory есть свои ACL


Интерфейс AD Users and Computers позволяет устанавливать разрешения для объектов AD. В AD существуют ACL, и администраторы могут назначать или запрещать доступ через них. Вам нужно нажать «Advanced» в меню ADUC View, а затем, когда вы откроете пользователя, вы увидите вкладку «Security», в которой вы устанавливаете ACL.

В моем сценарии с Cruella я не хотел, чтобы все прошедшие проверку пользователи (Authenticated Users) могли видеть ее личную информацию, поэтому я запретил им доступ для чтения:



И теперь обычный пользователь увидит это, если попробует Get-NetUser в PowerView:



Мне удалось скрыть заведомо полезную информацию от посторонних глаз. Чтобы сохранить к ней доступ для релевантных пользователей, я создал другой ACL, чтобы позволить членам VIP-группы (Cruella и другим ее высокопоставленным коллегам) получить доступ к этим конфиденциальным данным. Другими словами, я реализовал разрешения AD на основе ролевой модели, что сделало чувствительные данные недоступными для большинства сотрудников, включая инсайдеров.

Тем не менее, вы можете сделать членство в группе невидимым для пользователей, установив соответствующим образом ACL для объекта группы в AD. Это поможет с точки зрения конфиденциальности и безопасности.

В своей серии эпических пентестов я показал, как можно перемещаться по системе, изучая членство в группах с помощью PowerViews Get-NetGroupMember. В моем сценарии я ограничил доступ для чтения к членству в конкретной группе. Вы видите результат выполнения команды до и после изменений:



Мне удалось скрыть членство Cruella и Monty Burns в группе VIP, что усложнило хакерам и инсайдерам разведку инфраструктуры.

Этот пост предназначался для того, чтобы мотивировать вас более внимательно изучить поля
AD и связанные с ними разрешения. AD — отличный ресурс, но подумайте, как бы вы
хотели делиться конфиденциальной информацией и персональными данными, особенно,
когда речь идет о первых лицах вашей организации.  
Varonis Systems
Компания

Комментарии 3

    +2
    имхо, эту «полезную» информацию лучше вообще не хранить, тем более в AD
      +3
      Чтобы сохранить к ней доступ для релевантных пользователей, я создал другой ACL, чтобы позволить членам VIP-группы (Cruella и другим ее высокопоставленным коллегам) получить доступ к этим конфиденциальным данным

      Насколько знаю, deny имеет приоритет над permit, если оба заданы для объекта в явном виде (т.е. не унаследованы от родительского объекта). Учитывая, что члены VIP-группы также входят в Authenticated Users, доступ к свойствам они не получат.
      И ещё соглашусь с первым комментарием. Решение выглядит костыльно, это как запретить пользоваться бумажными стикерами, чтобы сотрудники не писали на них пароли. Также сам Microsoft не рекомендуют вот так менять ACL на объектах AD, т.к. в результате можно поломать работу какого-нибудь нужного сервиса, который не учитывает подобную «кастомизацию» AD
        0
        Да, согласны, но поскольку AD является ядром инфраструктуры, то зачастую даже у организаций, уделяющих внимание поддержанию защищённого состояния AD,
        для интеграции и совместимости систем в полях расширенной схемы может храниться чувствительная информация или что-то, что позволяет косвенно к ней приблизиться. А пример из статьи это, возможно, крайность, но и такое в нашей практике встречалось.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое