Взлом Бундестага: возможные предпосылки и методы защиты

  1. Как ИТ-системы могут быть приняты
  2. Возможен ли такой же сценарий взлома, что и взлом в Бундестаге, с Univention Corporate Server?
  3. Передайте хэш
  4. Так какую форму может принять эффективная защита?
  5. Есть ли какие-либо различия между тем, как Active Directory реализуется Samba в UCS и Microsoft Windows?
  6. Вектор атаки: Боковой перескок сервера с локальным администратором.
  7. Вектор атаки: Боковое переключение сервера с хешем пользователя домена.
  8. Вектор атаки: Считывание хэшей через LDAP из службы каталогов Samba.
  9. Вектор атаки: Считывание хэшей через LDAP из OpenLDAP.
  10. Другие элементы стратегии глубокоэшелонированной защиты
  11. Вывод для взлома бундестага

Здесь, в Univention, мы, конечно, также обеспокоены нападением на ИТ-инфраструктуру парламента Германии, более известную как «взлом Бундестага»

Здесь, в Univention, мы, конечно, также обеспокоены нападением на ИТ-инфраструктуру парламента Германии, более известную как «взлом Бундестага». Напомним: кажется, что там были некоторые поддельные электронные письма, в том числе ссылки на вредоносные программы. Некоторые ПК под управлением Windows в сети «Parlakom» бундестага были или могут быть заражены вредоносной программой, которая, как утверждается, искала и копировала определенные конфиденциальные документы Word. Согласно отчету в Tagesspiegel (немецкий) газете, это позволило хакерам получить «административные права на инфраструктуру». Атака была проведена как «продвинутая постоянная угроза» или «атака APT» для краткости: другими словами, сложная, многоэтапная атака на IT-сеть парламента Германии «Парлаком».

Как ИТ-системы могут быть приняты

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

Однако существуют также передовые методы взлома, которые не являются такими явными (как атака методом перебора) и не требуют огромных вычислительных усилий для взлома хэшей паролей. Институт SANS опубликовал документ на эту тему с подходящим названием « Зачем взламывать, когда можно передать хеш? ».

Возможен ли такой же сценарий взлома, что и взлом в Бундестаге, с Univention Corporate Server?

Как вы можете прочитать здесь, например, теперь мы знаем, что парламент Германии использует OpenLDAP и Active Directory в качестве центральных служб каталогов. OpenLDAP также является центральной службой каталогов в UCS, а службы Active Directory предоставляются в UCS программным обеспечением с открытым исходным кодом Samba. Следовательно, мы были вынуждены спросить себя, был ли бы тот же тип атаки успешным, если бы использовалась UCS, и какие защитные меры безопасности потребовались бы. Это ставит вопрос о том, существуют ли известные сценарии атак на Active Directory, применяются ли они также для UCS и Samba и какие меры безопасности могут быть реализованы в случае необходимости.

Передайте хэш

Передача хеша является примером метода взлома, который использует уязвимость проекта в протоколе аутентификации, а не конкретную уязвимость безопасности в самом коде. Таким образом, хэш пароля (а не фактический пароль) используется для входа в удаленную систему Windows.

Взлом может произойти следующим образом:

1. Хакер начинает с приобретения прав локального администратора в доменной системе (обычно это клиенты Windows), например, с выявления уязвимости в системе безопасности или с помощью фишинговой электронной почты, как это могло быть в случае взлома в Бундестаге.

2. Затем хэши паролей считываются, как правило, из внутренней памяти, но также, возможно, из локальных файлов. На сегодняшний день известные успешные хаки ограничиваются хешами LM и NTLM.

3. Эти хеши паролей также можно использовать для входа в службы сервера, которые разрешают проверку подлинности NTLM. Также доступны инструменты, которые могут генерировать поддельный билет Kerberos из хеша NTLM.

4. Домен может быть полностью скомпрометирован, если хэш пароля пользователя KRBTGT может быть считан на контроллере AD / Samba, так как он может быть использован для генерирования столько билетов Kerberos, сколько вам нужно (ключевое слово: «золотой билет»).

В общем, это крайне неприятно и позволяет хакеру установить присутствие для себя в Active Directory на длительный период времени. Эти атаки известны как расширенные постоянные угрозы (APT).

В настоящее время неизвестные возможности для непривилегированного пользователя получить доступ к хэшу пароля пользователя KRBTGT на серверах Samba AD DC.
Напротив, привилегированный пользователь может легко получить доступ к хешу пароля пользователя KRBTGT, поскольку система фактически разработана с учетом этого. В Univention Corporate Server для этого требуется доступ с правами root, тогда как администратора домена достаточно для Windows AD DC. Атаки, такие как передача хэша, используют эту функцию, используя другие уязвимости безопасности для получения прав привилегированных учетных записей.

Это может быть дополнено уязвимостями безопасности, такими как MS14-068, которые описывают, как сигнатуры реализации Microsoft Kerberos KDC не проверяются корректно на корректность и, таким образом, позволяют подделывать данные аутентификации, содержащиеся в билетах службы Kerberos. Как далеко как мы знаем Samba не подвержена этой уязвимости.

Общий риск может быть уменьшен только с помощью соответствующих общеорганизационных мер безопасности - здесь оперативное слово «глубокоэшелонированная защита».

Так какую форму может принять эффективная защита?

Основным требованием для прохождения хакерских атак является локальный административный доступ к компьютеру домена. Таким образом, хакеру необходимо сделать как можно более трудным получение доступа к доменным системам. Если это уже произошло, у него не должно быть никакой возможности зачитать действительно важные пароли.
Поскольку шаблоны атак для Microsoft AD и Samba AD в этом отношении идентичны, следует также обратиться к анализам и техническим документам, касающимся хакерских атак на Microsoft AD.

Есть ли какие-либо различия между тем, как Active Directory реализуется Samba в UCS и Microsoft Windows?

Как уже упоминалось, основные возможности атаки ничем не отличаются Как уже упоминалось, основные возможности атаки ничем не отличаются. Чтобы быть совместимым с Microsoft Active Directory, существующий недостаток дизайна также должен быть реализован в Samba. Единственная разница заключается в том, каким образом можно получить доступ к компьютеру домена и какие учетные записи пользователей и хэши можно считывать.
В Microsoft Windows доступ локального администратора является основным требованием для этого типа атаки, чтобы иметь возможность первоначально перехватить хеш NTLM пользователя. Эквивалентом в UCS / Linux будет корневой доступ.

Стандартное кэширование паролей в Microsoft Windows - даже после повторного выхода пользователей из системы - не происходит в системах UCS ни для пользователя root, ни для пользователей домена.

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

  • На DC UCS все (NTLM) хэши паролей находятся в OpenLDAP и на Samba DC дополнительно в SAM.ldb. По этой причине эти системы требуют особой защиты.
  • В системах UCS, допускающих интерактивные входы пользователей, в / tmp могут быть кэши учетных данных Kerberos.
  • Учетные данные хоста, доступные для чтения для root, находятся во всех системах UCS (/etc/machine.secret, /etc/krb5.keytab).
  • На всех контроллерах домена Windows хеши паролей пользователей домена хранятся в Active Directory - в частности, в файле% SystemRoot% \ NTDS \ Ntds.dit.
  • Локальные пользователи хранятся в базе данных SAM в системах Windows (% SystemRoot% / system32 / config / SAM) - к этому также можно получить доступ через реестр.
  • Кроме того, существуют также инструменты, которые обращаются к хэшам паролей во внутренней памяти Windows и могут их считывать. Это позволяет получить хэш пароля (ранее) зарегистрированного администратора домена на скомпрометированном клиенте, даже если его хэш пароля не хранится локально.

Вектор атаки: Боковой перескок сервера с локальным администратором.

В системах Windows хеш пароля локального администратора обычно может также использоваться для доступа к другим системам Windows, если там используется тот же пароль. UCS или Linux-эквивалент локального администратора - «root», и это не пользователь Samba / Kerberos. Таким образом, невозможно войти в удаленную систему UCS, используя простой хэш. Локально сохраненный хэш пароля корневого пароля засолен, что значительно затрудняет взлом пароля с использованием радужных таблиц. Тем не менее, рекомендуется не использовать одни и те же пароли root во всех системах. Как правило, также практично отключать пароли root и просто использовать вместо этого sudo.

Альтернативно / дополнительно, вы можете использовать SSH-ключи с более сильной, специфичной для хоста парольной фразой.

Вектор атаки: Боковое переключение сервера с хешем пользователя домена.

В отличие от систем Windows, невозможно войти в удаленную систему UCS только с хешем NTLM.

Однако, как и в Windows, в UCS также возможно использовать кеш учетных данных Kerberos пользователя или хоста UCS для аутентификации в Kerberised службах других систем UCS. Ограничение авторизации является решающим (например, через переменные UCR auth / .*/ ограничено и auth / .*/).

Вектор атаки: Считывание хэшей через LDAP из службы каталогов Samba.

В принципе это возможно только через локальный сокет, а не через порт LDAP. Требуется локальный root-доступ. Присоединение дополнительного Samba AD или Microsoft AD DC в качестве средства атаки представляет собой исключение, поскольку контроллеры AD получают все хэши паролей через репликацию DRS. Для этого требуются учетные данные администратора домена, например хеши Kerberos.

Вектор атаки: Считывание хэшей через LDAP из OpenLDAP.

Это защищено списками ACL LDAP. По умолчанию, помимо администраторов домена, все контроллеры домена UCS могут также считывать хэши для репликации LDAP. Начиная с UCS 3.0, доступ к OpenLDAP всегда требовал аутентификации. Однако необходимо проверить, не отключена ли аутентификация вручную по причинам обратной совместимости (ldap / acl / read / anonymous и ldap / acl / read / ips). Репликация выполняется через TLS-зашифрованные соединения.

Другие элементы стратегии глубокоэшелонированной защиты

Без претензий на исчерпывающий характер:

  • Если клиенты и файловые серверы Microsoft Windows объединены в домене UCS, то для этих систем применяются все рекомендации Microsoft, в частности http://blogs.microsoft.com/cybertrust/2012/12/11/new-guidance-to-mitigate. -определенные-злоумышленники-любимые-атаки-пасс-хэш / и https://technet.microsoft.com/en-us/dn785092.aspx. Windows 8.1 и Windows Server 2012 R2 также повышают безопасность локальных служб входа, см. Http://blogs.microsoft.com/cybertrust/2014/07/08/new-strategies-and-features-to-help-organizations- лучше защитить, против миновать-зе-хэш-атак /.
  • Запретить доступ для постоянных пользователей на контроллерах домена. Это уже стандартная конфигурация для многих сервисов UCS (переменные UCR auth // restrict).
  • Кроме того, следует также учитывать целевое разделение различных типов учетных записей.
      Отключение администратора домена «Администратор» и использование персональной учетной записи администратора.
      Введение администраторов домена DC - кто может войти только на контроллеры домена.
      Представление администраторов клиентских доменов - которые могут входить только на рядовые серверы и клиенты
      Администраторы используют только учетные записи администраторов для администрирования, то есть как пользователи, так и администраторы выполняют свою повседневную работу с непривилегированными учетными записями.
  • Регулярная, быстрая и комплексная установка обновлений безопасности.
  • Полное шифрование диска
  • BIOS / UEFI, защищенный паролем
  • Вирусные сканеры с соответствующей отчетностью
  • Межсетевые экраны с соответствующей отчетностью
  • Системы обнаружения вторжений с соответствующей отчетностью
  • Правила брандмауэра: нет связи клиент-клиент; клиенты могут общаться только с необходимыми серверами.
  • Регулярная ротация всех паролей
  • Убедитесь, что, насколько это возможно, используются и принимаются только надежные методы шифрования / хэши.
  • Убедитесь, что локальные пользователи (например, администратор / root) не могут войти в другую систему удаленно, особенно с тем же паролем.
  • Убедитесь, что Windows не кэширует хэши паролей дольше, чем это абсолютно необходимо, особенно после того, как пользователь вышел из системы.

Вывод для взлома бундестага

То же самое относится и к ИТ-безопасности: нет такой вещи, как 100% безопасность - даже в UCS. Однако существует целый ряд мер, которые могут быть приняты, и которые, в случае такой критически важной инфраструктуры, как, например, парламент Германии, безусловно, также должны быть приняты. Действительно ли они были или нет, будет выявлено в результате недавно спровоцированного расследования.

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

Источник фото «Deutscher Bundestag»: Groman123 / CC BY-SA 2.0

Есть ли какие-либо различия между тем, как Active Directory реализуется Samba в UCS и Microsoft Windows?
Возможен ли такой же сценарий взлома, что и взлом в Бундестаге, с Univention Corporate Server?
Так какую форму может принять эффективная защита?
Есть ли какие-либо различия между тем, как Active Directory реализуется Samba в UCS и Microsoft Windows?