Хроники пентестера #1: Безопасность в сетях Microsoft

Предположил, что многим будет интересно почитать невыдуманные истории из жизни, в которых удавалось воспользоваться слабостями защитных механизмов в крупных компаниях и реализовать различные угрозы информационной безопасности. В силу того, что подобных историй за время работы в компании Positive Technologies накопилось огромное множество и маленькая тележка, данную рубрику предполагаю вести по всем направлениям enterprise security. А чтобы защищающейся стороне данный материал также являлся полезным, в конце каждого подобного поста буду приводить практическое решение по избеганию описываемых (типовых) проблем безопасности. Итак, поехали!


В большинстве компаний, как у нас, так и за рубежом в качестве основной системы управления аутентификацией используется каталог Active Directory. И, разумеется, одной из типовых задач внутреннего пентеста является демонстрация максимального доступа к иерархии доменной инфраструктуры (получение привилегий "enterprise admins")...

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



Само собой подобный сценарий работает в компаниях, которые до этого не проводили пентесты и не задумывались о подобной угрозе. К слову, в подобных компаниях приходиться часто наблюдать, как обслуживание самых обычных доменных рабочих станций корпоративных пользователей (!) беззаботно протекает от имени самой что ни на есть привилегированной учетной записи в домене.

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

- Установка запрета изменения членства наиболее чувствительных групп для всех, кроме членов группы Enterprise Admins.
- Изменение расположения наиболее чувствительных групп в пространстве каталога Active Directory (кроме "Builtin\ Administrators", имхо ее так просто не перенести).
- Запрет просмотра любых атрибутов у наиболее чувствительных групп для всех, кроме их членов (видимо, чтоб никто не догадался:)).

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



Описанная ситуация встречается довольно часто, ровно, как ситуации с активными/отключенными сессиями администраторов домена (или серверов) расположенные на соседних терминалах при получении уже упомянутого доступа к системам. И тут на помощь приходит инструмент "incognito" [1, 2], который реализует перехват токена зарегистрированного пользователя в системе. Стоит также заметить, что на возможности указанного инструмента в свое время не повлиял и пресловутый патч MS09-012.

Но нужно быть честным. Несмотря на свою распространенность и популярность, "incognito" был и остается довольно нестабильным и ограниченным инструментом. Совершенно другие перспективы открывает инструмент под названием "Windows Credentials Editor" [3]. Это настоящий швейцарский нож, который сводит задачу к минимуму и просто вытягивает живые хеши из сессии активного/отключенного пользователя (со вторым к слову довольно плохо справляется "incognito"). Кроме того, "Windows Credentials Editor" позволяет элегантно использовать хеши, что также может применяться для проведения атаки "Pass-the-Hash".

Ниже приведен пример, слабостей "incognito" и сильной стороны "Windows Credentials Editor".



Несмотря на подобный вывод команды "whoami" (на второй картинке) текущая сессия пользователя все-таки "DC\admin". К слову, аналогичным образом можно использовать LM/NTLM-хеши, полученные из других источников и полноценно проводить атаку "Pass-the-Hash" из под GUI-интерфейса.

Так как же защититься от подобных угроз?

- Я уже много раз говорил об этом, и повторюсь вновь, в доменной архитектуре рекомендуется отключить учетную запись локального администратора на всех рабочих станциях и серверах. Если же она потребуется, например, в контексте поиска неисправностей при отсутствии доступа к сети, то локальная учетная запись администратора по умолчанию (SID 500) всегда доступна при загрузке в безопасном режиме.
- Рекомендуется продумать/изменить существующий дизайн Active Directory, и, возможно, разнести по разным доменам сервера и рабочие станции пользователей. Более того, в некоторых случаях имеет смысл вынести в отдельный домен наиболее критичные ресурсы, например, СУБД или ERP-системы. При этом разумеется использовать разные пароли для учетных записей в разных доменах.
- Рекомендуется придерживаться следующей модели доступа (в том числе, жестко контролировать на уровне GPO): членам группы администраторов домена разрешен доступ только на контроллеры домены; членам группы администраторов серверов (или администраторам определенных сервисов) разрешен доступ только на заранее определенные ресурсы; членам администраторов рабочих станций разрешен доступ только на рабочие станции пользователей; все администраторы работают на своих компьютерах под непривилегированными учетными записями домена.
- Реализовать мониторинг событий безопасности, приближенный к реальному времени. Своевременно обрабатывать инциденты информационной безопасности.
- И, разумеется, не использовать словарные пароли, своевременно устанавливать обновления безопасности, использовать максимально безопасные конфигурации и рекомендации вендора. В общем, заниматься, заниматься информационной безопасностью :)

18 комментариев :

  1. А зачем логиниться на пользовательские машины под учеткой домен админа?
    Это же азы безопасности - не логиниться с чувствительными учетками на недоверенных машинах. Одно простое и действенное правило.

    ОтветитьУдалить
  2. ...верно, но администраторы зачастую пренебрегают простыми правилами безопасности...

    ОтветитьУдалить
  3. Разнести компьютеры и серверы по разным доменам...

    Дмитрий. Времена NT4 давно закончились.

    ОтветитьУдалить
  4. а причем тут NT4?
    возможность как-то обезопасить критически важные системы это вовсе не глупо...

    ОтветитьУдалить
  5. Огромное спасибо за writeup. Плотность полезной информации на единицу текста - мое почтение.

    p.s. Про Windows Credentials Editor услышал впервые. Раньше знал только про Pass the Hash Toolkit (http://oss.coresecurity.com/projects/pshtoolkit.htm).

    ОтветитьУдалить
  6. кстати, про WCE писал некто под псевдонимом m0r0 в последнем журнале ксакепа...

    ОтветитьУдалить
  7. Сравнивать плюсы и минусы incognito и pth нет смысла, т.к. это принципиально разные атаки.
    последнюю, кстати, зарелизили 10 лет назад.
    но к сожалению до сих пор не прикрыта во многих организациях.
    Дима, напиши про атаки посвежее. будет интересно почитать!

    ОтветитьУдалить
  8. Да нет, я понимаю, что в целом статья о другом.
    за статью: +1.
    мой комент про "Ниже приведен пример, слабостей "incognito" и сильной стороны "Windows Credentials Editor"

    ОтветитьУдалить
  9. так тут речь, собственно не столько про pth, сколько о стабильной альтернативе incognito

    ОтветитьУдалить
  10. На прошлой неделе встречался с новым заказчиком. После встречи решил посмотреть на сервера. Очень удивился, когда понял, что админ в своей повседневной работе использует учетную запись, которая входит в группы Domain Admins и Enterprise Admins. Еще больше удивился, когда заметил, что на контроллере домена что-то качает uTorrent. Вот тебе и безопасность %)

    ОтветитьУдалить
  11. дк вот я и говорю, что wce реализует атаку pass-the-hash (или я не прав?), а incognito реализует совсем другую атаку.
    поэтому это не взаимозаменяемые инструменты на пентесте, а взаимодополняемые.

    ОтветитьУдалить
  12. соль wce в первую очередь в возможности вытащить хеши зарегистрированных пользователей (мне например не известны аналоги) и только во вторую pth

    ЗЫ. о чем мы спорим?

    ОтветитьУдалить
  13. Если я не ошибаюсь, то wce работает с хешами, а incognito с токенами процесcов - в этом и отличие атаки.

    ОтветитьУдалить
  14. Возвращаясь к теме NT4 хочу сказать что вполне достаточно создать две группы (или Х групп) которым достаточно разрешить нужный тип входа на нужные сервера или станции.
    Городить огород доменов не стоит т.к. они подвержены тем же ошибкам - одинаковые пароли и пр.

    ОтветитьУдалить
  15. Кстати, только сегодня понял, что автор WCE тот же чувак, что написал pass the hash toolkit (зовут Hernan Ochoa)!
    Ваш Кэп.

    ОтветитьУдалить
  16. Hi Guys!,

    I apologize in advance, I don't speak Russian.

    I'm Hernan Ochoa. I'm the author of both PTH and WCE.

    I just wanted to let you know there's a new version of WCE available,
    version 1.2, you can find it here:

    http://www.ampliasecurity.com/research/wce_v1_2.tgz

    This new version has a new feature called 'Pass-The-Ticket'. It allows you
    to dump Kerberos tickets from a Windows system and inject/use those tickets
    on other machines (including Unix boxes). This is equivalent to
    Pass-the-Hash but for Kerberos.

    Also, I put together a FAQ here:

    http://www.ampliasecurity.com/research/wcefaq.html

    And yes, I want to confirm; incognito does something different than WCE/PTH.
    incognito works with tokens, WCE works with hashes (which are equivalent to
    the password) and also now supports Pass-The-Ticket (incognito does not).

    Also PTH does not work anymore, so you should stick with WCE. Read the FAQ
    as to why.

    Thank you!,
    Hernan

    ОтветитьУдалить