Методичка для лабораторных

o=ipaca

…

Если вы успешно подключитесь к серверу, то увидите показанный выше результат. Полученная информация о сервере будет содержать множество важных деталей, включая версию LDAP-сервера. Теперь отправим на LDAP-сервер запрос, чтобы больше узнать о сети. Большинство LDAP-серверов блокируют запросы неавторизованных пользователей, поэтому изменим код клиента info_probe.py так, чтобы он проходил процедуру аутентификации в сервисе LDAP. Мы применим метод аутентификации с привязкой пароля для подключения к LDAP-серверу и поиска всех пользователей в домене. LDAP-сервер предусматривает три учетные записи по умолчанию, каждая из которых имеет пароль Secret123. Однако для прохождения процедуры аутентификации вы также можете использовать NTLM-хеш пароля, извлеченный из памяти:

from ldap3 import Server, Connection, ALL, SUBTREE server = Server(host = 'ipa.demo1.freeipa.org', use_ssl=True)

conn = conn = Connection(server, user='uid=admin,cn=users,cn=accounts,dc=demo1, dc=freeipa,dc=org', password="Secret123", auto_bind=True)

conn.search(search_base = 'dc=demo1,dc=freeipa,dc=org' ,search_filter = '(objectClass=person)'

,attributes=['cn', 'givenName', 'mail'] ,search_scope = SUBTREE)

print(conn.entries)

Сначала мы подключаемся к LDAP-серверу, передавая уникальное имя пользователя в качестве значения параметра user. Обратите внимание на то, что это имя указывает путь от листа до корня DIT. Мы также задаем значение true для параметра auto_bind. Благодаря этому библиотека ldap3 выполнит привязку, как только инициирует соединение, избавив нас от необходимости писать лишнюю строку кода. Затем мы вводим свой поисковый запрос. Аргумент search_base представляет начальный узел в DIT, и в качестве его значения мы задаем корневой узел. Второй параметр позволяет фильтровать результаты. Мы ограничимся объектами типа person. Фильтры также могут включать логические операторы. Например, следующий фильтр возвращает объекты типа person с атрибутом, который начинается с Test: \& (objectClass=person) (cn=Test*). Обратите внимание на то, что логический оператор предшествует условным. Эта структура может отличаться от структур, использующихся в других знакомых вам языках запросов. Наконец, мы указываем интересующие нас атрибуты. Запустите программу Python:

$ python3 info_probe.py

[DN: uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org - STATUS:. cn: Administrator

, DN: uid=manager,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org - STATUS: cn: Test Manager

givenName: Test

mail: manager@demo1.freeipa.org

,DN: uid=employee,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org - STATUS: Read cn: Test Employee

givenName: Test

mail: employee@demo1.freeipa.org

,DN: uid=helpdesk,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org - STATUS: Read cn: Test Helpdesk

givenName: Test

mail: helpdesk@demo1.freeipa.org ]

Здесь мы видим данные четырех содержащихся в DIT пользователей. Поскольку LDAP-сервер общедоступен, это дерево может быть изменено вами и другими пользователями. Поэтому при отправке своего запроса вы можете обнаружить дополнительные записи. Чтобы увидеть то, что видит системный администратор, введите логин admin и пароль Secret123 в форму аутентификации на странице https://ipa.demo1.freeipa.org/ .

5.5 Атака на протокол Kerberos

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

Рис. 27 – Процесс аутентификации по протоколу Kerberos

Сначала клиент инициирует соединение с сервером аутентификации (AS) и запрашивает разрешение на доступ к сервису выдачи мандатов (TGS)(1). Это сообщение в виде открытого текста содержит идентификатор пользователя, идентификатор сервиса, IP-адрес пользователя и запрошенное время жизни мандата на получение мандата (TGT). Сервер аутентификации ищет пользователя в сервисе Active Directory, и если такой пользователь существует, то AS извлекает хеш его пароля. Затем этот хеш будет использоваться в качестве симметричного ключа для шифрования ответа сервера аутентификации. Копия хеша есть у AS и у пользователя, поэтому расшифровать сообщение могут только пользователь и сервер аутентификации.

Затем AS отправляет два зашифрованных сообщения, ответ и мандат на получение мандата(2). Ответ, зашифрованный с помощью хеша пароля пользователя, содержит идентификатор сервиса, временную метку, время жизни сеанса и сеансовый ключ, который будет применять пользователь для шифрования канала связи с сервисом выдачи мандатов. Это сообщение означает следующее: «Вы прошли процедуру аутентификации. Если вы действительно тот пользователь, за которого себя выдаете, то сможете расшифровать это сообщение и извлечь сеансовый ключ, с помощью которого затем сможете безопасно обмениваться данными с сервисом выдачи мандатов». Второе сообщение (мандат на получение мандата) зашифровано с использованием секретного ключа сервиса выдачи мандатов, то есть прочитать его может только сервис TGS. Это сообщение содержит идентификатор пользователя, идентификатор TGS, время,

IP-адрес пользователя, время жизни TGT и тот же сеансовый ключ, который используется клиентом. Этот мандат эквивалентен следующему сообщению сервера: «Предоставьте этот мандат сервису выдачи мандатов в качестве доказательства того, что у вас есть разрешение на обращение к нему. Сервис знает, что делать с этим мандатом».

Пользователь расшифровывает первое сообщение с помощью хеша своего пароля и извлекает сеансовый ключ(3). Затем шифрует свой идентификатор и хеш пароля с помощью сеансового ключа. Результат этого процесса называется аутентификатором пользователя. После этого пользователь отправляет запрос в виде открытого текста с указанием сервиса, к которому он хочет получить доступ (например, файловый сервер), и запрошенного времени жизни мандата, и прикрепляет к этому запросу TGT в качестве доказательства того, что у него есть разрешение на получение доступа к сервису выдачи мандатов.

Сервис выдачи мандатов проверяет TGT, расшифровывая его с помощью своего секретного ключа(4). Затем TGS извлекает сеансовый ключ из расшифрованного мандата и использует его для расшифровки аутентификатора пользователя и извлечения его идентификатора. Затем TGS обращается к сервису Active Directory, чтобы выяснить, имеет ли пользователь право на получение доступа к этому сервису. Если да, то сервис выдачи мандатов генерирует два сообщения: ответ и мандат сервиса. Ответ, зашифрованный с помощью сеансового ключа, содержит идентификатор сервиса (например, идентификатор файлового сервера), временную метку, время жизни и новый сеансовый ключ файловой системы, который будет использоваться для шифрования канала связи между файловым сервером и пользователем. Второе сообщение представляет собой мандат сервиса, зашифрованный с помощью секретного ключа файлового сервера, поэтому только файловый сервер может его расшифровать. Этот мандат содержит идентификатор пользователя, идентификатор сервиса, временную метку и новый сеансовый ключ файловой системы. Данный мандат предоставляет конкретному пользователю доступ к определенному сервису.

Пользователь расшифровывает ответное сообщение, извлекает сеансовый ключ файлового сервера(4) и использует его для шифрования сообщения, содержащего запрос на получение доступа к файловому серверу. Затем отправляет запрос и мандат сервиса файловому серверу. Наконец, сервер выполняет те же действия, что и сервис выдачи мандатов(5). Сначала он использует свой секретный ключ для расшифровки мандата сервиса и извлечения сеансового ключа, который затем применяет для расшифровки запроса пользователя. Если файловый сервер может расшифровать это сообщение, то аутентифицирует пользователя и отправляет ему сообщение о предоставлении доступа, зашифрованное с помощью сеансового ключа.

Насколько безопасен протокол Kerberos? Обратите внимание на то, что злоумышленнику не обязательно иметь хеш пароля пользователя для запроса TGT. Допустим, он отправляет идентификатор пользователя на сервер аутентификации. В этом случае сервер отправит в ответ мандат на получение мандата, содержащий зашифрованный сеансовый ключ. Затем злоумышленник может попытаться взломать этот мандат, используя инструмент Hashcat для выполнения «перебора по словарю».

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

Атака типа Golden Ticket

Обсуждая протокол Kerberos, мы не сказали о том, что все сообщения подписываются хешем пароля, связанным с аккаунтом krbtgt, специальной учетной записью на всех контроллерах домена с длинным и сложным паролем, который генерируется автоматически. Однако предположим, что злоумышленнику удалось взломать контроллер домена и украсть хеш пароля учетной записи krbtgt. В этом случае хакер может подделать любой мандат, подписав его этим хешем. Это позволит злоумышленнику создавать мандаты, которые он сможет использовать спустя многие годы после взлома системы. Вот почему так важно сменить пароль учетной записи krbtgt при первом подозрении на взлом системы. Поскольку такая атака позволяет хакеру в любое время подделать любой мандат, она называется атакой типа golden ticket (золотой мандат).

Для реализации атаки такого типа вам потребуется хеш пароля учетной записи krbtgt. Но как можно получить этот хеш, не взламывая контроллер домена? Дело в том, что, когда сетевой администратор добавляет в сеть новый контроллер домена, тот просит существующие контроллеры домена отправить ему копию своих баз данных. Этот запрос обеспечивает синхронизацию контроллеров домена. Однако эти БД также содержат хеши паролей, в том числе хеш пароля учетной записи krbtgt. Выдав свой компьютер за контроллер домена, выполняющий синхронизацию, злоумышленник может украсть хеш пароля учетной записи krbtgt.

Для того чтобы сделать Golden Ticket, нам необходимо знать следующее:

●SPN домена

●SID домена

●NTLM-хеш доменной учетной записи krbtgt

●Имя пользователя, под которым будет работать оператор (даже если такого пользователя не существует)

Так как имя пользователя может быть любым, остается найти три недостающих компонентов. Название, SID домена и NTLM-хеш можно узнать с помощью команды (не забудьте повысить привилегии):

mimikatz # sekurlsa::logonPasswords

Теперь у нас есть все для создания Золотого билета на рис. 28:

mimikatz # kerberos::golden /domain:<example.local> /sid:<SID> /rc4:<NTLM-хеш> /user:<ID АДМИНИСТРАТОРА> /id:500 /ptt

Если в данной команде не использовать параметр /ptt, то билет будет просто сохранен в текущей директории.

Рис. 28 – Создание Golden ticket

В данном случае он сразу будет кэширован в памяти. Проверим это, вызвав командную строку.

mimikatz # misc::cmd

Теперь, выполнив команду klist, наблюдаем кэшированный Golden Ticket на рис. 29.

Рис. 29 – Создание Golden Ticket с помощью mimikatz

Контрольные вопросы

1.С помощью каких сервисов контроллер домена управляет доменами и их политиками безопасности?

2.Опишите как происходила атака на сервис DNS.

3.Как происходит процесс аутентификации по протоколу Kerberos?

4.Что такое Golden Ticket и для чего он нужен? Какие данные нужны злоумышленнику для его создания?

5.Как можно устранить уязвимость, эксплуатируемую в данной работе?

Лабораторная работа № 6 Отчет о тестировании на проникновение во внутреннюю

корпоративную сеть

Цель работы - подготовить полный отчет о проникновении в корпоративную

сеть.

6.1Отчет должен содержать

●описание корпоративной сети;

●описание уязвимостей;

●методику проникновения;

●описание технических результатов;

●вывод;

●используемые инструменты;

●приложение.

Пример отчета

6.2 Описание корпоративной сети

Этап 1. Сбор информации.

Задача на этапе сбора информации в ходе теста на проникновение заключается в том, чтобы максимально приблизиться к этому уровню понимания без помощи сетевых инженеров рис. 30. Чем больше информации будет собрано, тем выше шансы обнаружить слабое место.

Рис. 30 – Этапы сбора информации Самый простой и, вероятно, наиболее эффективный способ обнаружения

сетевых хостов – использовать Nmap для запуска эхо-запросов (ping-sweep, пингование). Пингование эхо-запросами (pingsweep) означает, что вы отправляете эхо-запрос на всевозможные IP-адреса в заданном диапазоне, чтобы определить, какие из них отправят ответ и, следовательно, считаются активными или действующими.

Чтобы проиллюстрировать идею использования ping в качестве средства обнаружения активных хостов в заданном диапазоне, вы можете протестировать эту команду, применив ее к локальной сети (LAN), в которой расположен IP-адрес вашей виртуальной машины пентеста. Вы можете определить этот сетевой диапазон с помощью команды ifconfig, включенной в пакет net-tools, который вы установили при настройке вашей виртуальной машины рис.31.

Рассказ об атаке – его следует писать так, как если бы вы рассказывали историю. Объясните, как перешли от начала к концу. Опишите все системы, которые пришлось скомпрометировать, чтобы захватить сеть, но оставьте детали взлома для следующего раздела.

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

Способность мыслить как злоумышленник, единственная цель которого – проникнуть внутрь любыми доступными средствами, имеет решающее значение для выявления слабых мест в вашей целевой среде.

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

Пример

Бэкдор, тайный вход — дефект алгоритма, который намеренно встраивается в него разработчиком и позволяет получить несанкционированный доступ к данным или удалённому управлению операционной системой и компьютером в целом.

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

Они могут быть доступны каждому, кто знает об их существовании или случайно их находит. Существует и другой вид, доступ к которому есть только у злоумышленника или разработчика.

6.4 Методика проникновения

Методика проникновения – объясняет методологию, которую была использована для выполнения задания. Обычно также описывается типаж моделируемого злоумышленника, а затем излагаете цели и возможные действия.

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