Дисклеймер:
Внимание! Данная статья носит исключительно информационный характер и предназначена для образовательных целей.
Представим себе типичный внутренний пентест. Вы приезжаете к заказчику, подключаетесь к Ethernet-розетке. Вы заранее предупредили о своём приезде, попросили себе рабочее место с Ethernet-розеткой и договорились отключить 802.1x. В итоге нашли тонну критических уязвимостей и в деталях расписали, как всё плохо исправить. Вы выдали красивый отчёт, оценили риски и составили рекомендации. Заказчик смотрит в отчет, хмурит брови и выдает непробиваемый довод: просто я отключил 802.1х. Добились бы вы таких же результатов без доступов к сети?
В этом посте я продемонстрирую, как легко можно обойти 802.1x на внутреннем пентесте. За редкими исключениями, но их мы тоже обсудим.
Оглавление
Матчасть
IEEE 802.1X ― это стандарт, который используется для аутентификации и авторизации пользователей и рабочих станций в сети передачи данных. Он осуществляет контроль доступа и не позволяет неавторизованным устройствам подключаться к локальной сети. Наибольшее распространение протокол получил в беспроводных сетях, однако встречается и в проводных. В данной статье рассматривается его применение для проводных сетей.
Описание протокола 802.1x
Механизм аутентификации
В процессе аутентификации участвую 3 сущности:
Клиент (Client/Supplicant) ― программное обеспечение на стороне клиента, установленное на устройство пользователя и запрашивающее доступ к сети. Для запуска процесса аутентификации клиент использует Extensible Authentication Protocol via LAN (EAPoL)
Аутентификатор (Authenticator) ― устройство, которое обеспечивает связь клиента с сервером аутентификации по протоколу 802.1х и, в случае успешной авторизации ― доступ к сети.
Сервер аутентификации (Authentication Server) ― ААА-сервер, интегрированный с той или иной базой данных пользователей.
Аутентификация клиента происходит в несколько этапов:
1. Инициализация
На этом этапе клиент подключается к порту аутентификатора. Аутентификатор распознает факт подключения и активизирует логический порт для клиента, сразу переводя его в состояние "неавторизован" (uncontrolled). В результате через клиентский порт возможен лишь обмен трафиком протокола 802.1x, для всего остального трафика порт заблокирован.
2. Инициация
Аутентификатор ожидает от клиента запрос на аутентификацию (EAPOL-Start). Когда аутентификатор получает запрос, он посылает клиенту EAP-request/identity. Клиент в ответ высылает EAP-response со своим идентификатором (например, именем пользователя), который аутентификатор перенаправляет в сторону сервера аутентификации, предварительно завернув в RADIUS Access-Request.
3. Обмен EAP
Сервер аутентификации и клиент договариваются о методе EAP, по которому будет проходить аутентификация.
4. Аутентификация
Может происходить по-разному, в зависимости от метода EAP. В результате сервер аутентификации разрешает (accept) или запрещает (reject) доступ, с пересылкой данного сообщения аутентификатору. В случае успешной аутентификации аутентификатор переводит порт клиента в состояние «авторизован» (controlled), и начинается передача трафика клиента.
EAP
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями, называемыми методами EAP. Рассмотрим самые распространённые методы EAP.
EAP-MD5
Алгоритм работы:
Сервер аутентификации посылает запрос EAP-Request-Identity клиенту.
Клиент в ответ посылает EAP-Response-Identity.
После получения EAP-Response-Identity сервер генерирует случайную строку (challenge string) и отправляет клиенту MD5-Challenge-Request с этой строкой.
Клиент объединяет имя пользователя, пароль в открытом виде и challenge string в одно значение и отправляет хэш MD5 этого значения на сервер аутентификации как MD5-ChallengeResponse
После получения MD5-Challenge-Response сервер аутентификации самостоятельно считает MD5-хэш от данных пользователя и отправленной строки challenge string и сравнивает с хэшом, полученным от клиента. Если хеши совпадают, аутентификация завершается успешно.
У этого метода EAP есть существенный недостаток: как MD5-Challenge-Request, так и MD5-Challenge-Response могут быть перехвачены. В результате можно сбрутить пароль пользователя.
EAP-PEAP/EAP-TTLS
Алгоритм работы:
Аутентификация проходит в 2 этапа – внешний и внутренний
1. Внешняя аутентификация:
1.1 Клиент посылает Authentication Request на сервер аутентификации.
1.2. Сервер в ответ посылает свой сертификат
1.3. Клиент проверяет сертификат сервера, и, если всё в порядке, внешняя аутентификация проходит успешно.
1.4. Клиент и сервер устанавливают TLS-соединение.
2. Внутренняя аутентификация через установленный безопасный канал. При этом существует много различных протоколов аутентификации, однако наиболее часто используется MS-CHAPv2.
Основная проблема такого подхода заключается в том, что соединение может быть установлено, даже если сертификат невалиден. Например, если в настройках не стоит галочка «Проверять сертификат сервера».
EAP-TLS
Отличие этого метода от предыдущего заключается в том, что на внешнем этапе аутентификации происходит проверка подлинности не только сервера, но и клиента. После взаимной проверки подлинности аутентификация проходит по протоколу TLS.
Это куда более безопасно, но сложнее в реализации. На всех клиентских устройствах нужно установить клиентский сертификат.
Основная проблема такого подхода заключается в том, что соединение может быть установлено, даже если сертификат невалиден. Например, если в настройках не стоит галочка «Проверять сертификат сервера».
MAB
MAB (MAC Authentication Bypass) – это вариант «аутентификации» для устройств, которые не поддерживают протокол 802.1x. Если к порту коммутатора, на котором настроена аутентификация, требуется подключить такое устройство, то, чтобы не отключать на этом порту аутентификацию, был придуман более слабый механизм. Весь процесс аутентификации по MAB заключается в проверке MAC-адреса устройства.
Атаки
А теперь самое интересное. Расскажу, как мы обходим 802.1X.
Обход MAB
Самый простой метод обхода. MAB вообще как будто был придуман специально для пентестеров. Даже в названии присутствует слово «Bypass».
В общем, находим старенький принтер (камеру, телефон, PDP-11…), узнаём его MAC-адрес и отключаем от коммутатора. Меняем свой MAC на МАС устройства и подключаемся вместо него.
В последнее время метод несколько потерял актуальность за счёт использования профилирования (подробнее в разделе «Как защититься»)
Классическая атака (Bridged-based)
Экскурс в историю
В 2005 году Стив Райли, исследователь из Microsoft, обнаружил уязвимость в протоколе 802.1x, которая приводила к возможности атак «Человек посередине». Суть уязвимости заключалась в том, что аутентификация по протоколу 802.1x происходит только при установке нового соединения. Когда клиент, подключившийся к порту коммутатора, проходит аутентификацию, порт переходит в состояние «controlled» и все последующие соединения от этого клиента не требуют аутентификации. Злоумышленник, разместивший хаб между аутентифицировавшимся клиентом и портом коммутатора, может подключить своё устройство к хабу и отправлять пакеты в сеть, подменив исходные MAC- и IP-адреса на адреса легитимного клиента.
Очевидно, что у такой атаки были проблемы, связанные с состоянием гонки (race condition ― https://en.wikipedia.org/wiki/Race_condition). Если легитимный клиент отвечал быстрее, то нелегитимный терял соединение:
Хост злоумышленника отправляет SYN-пакет в сеть.
В ответ приходит SYN / ACK, который попадает на оба устройства: и хост злоумышленника, и хост клиента.
Клиент отправляет RST / ACK.
Хост злоумышленника отправляет ACK.
Если клиент успел отправить RST/ACK раньше, соединение разрывается. Поэтому в классическом варианте атаки можно было отправлять только UDP-трафик.
Логичным развитием MITM-атаки стало использование моста.
Алгоритм атаки
Нам понадобится ноутбук с двумя интерфейсами и какой-нибудь сотрудник компании (а точнее, его девайс).
Одним интерфейсом подключаемся к девайсу, а другим – к порту коммутатора (розетке на стене). Дальше делаем следующее:
Разрешаем форвардинг
Переводим интерфейсы в Promisc-режим
Поднимаем между ними мост и тоже переводим в Promisc-режим
MAC девайса меняем на MAC коммутатора
Настраиваем SNAT для пакетов, которые отправляем сами – они должны выглядеть так, как будто их отправил девайс.
Добавляется маршрут в сеть за коммутатором через мост
Rogue Gateway Attack
Тот же Evil Twin, только в LAN. Работает в случае, если клиент сконфигурирован так, что соединение может быть установлено даже в случае невалидного сертификата сервера. Например, в настройках не стоит галочка «Проверять сертификат сервера».
Поднимаем мост и начинаем слушать трафик. В результате выясняем параметры клиента и аутентификатора:
MAC-и
IP-адреса
Маршрут по умолчанию
Маска подсети
Дальше начинается сама атака.
Поднимаем поддельный RADIUS-сервер и выключаем интерфейс, подключенный к аутентификатору.
Затем отправляем на поддельный RADIUS-сервер кадр EAPOL-Start с MAC-адресом клиента. В результате сервер отвечает клиенту запросом EAP-Request-Identity.
Если клиент примет сертификат, то он аутентифицируется у поддельного сервера.
Атакующий прослушивает MS-CHAPv2-challenge и response, сгенерированный на основе NTLM-хэша пароля. [AY1] В случае использования словарного пароля его можно получить перебором по словарю.
Если атака прошла успешно, можно отключить клиента от сети и авторизоваться с его данными.
Атака на EAP-MD5
EAP-MD5 ― это один из самых простых в настройке методов EAP. Он часто используется на периферийных устройствах.
Атака заключается в перехвате MD5-Challenge-Request и MD5-Challenge-Response с последующим брутом MD5-хэша. Для этого, как и в предыдущих атаках, поднимается мост между клиентом и аутентификатором.
Единственная проблема: клиент должен аутентифицироваться после того, как мы начали слушать трафик. Можно просто отключить его от сети и включить заново, однако это заметно и нельзя сделать удалённо (например, если мы оставили Raspberry Pi в офисе, а всю работу хотим сделать из дома). Можно заставить клиента ре-аутентифицироваться, просто отправив «EAPoL-start» аутентификатору от его имени.
Демо
Продемонстрируем классическую Bridged-Based атаку с использованием Fenrir.
Стэнд
Коммутатор Cisco
Радиус-сервер (Cisco-ISE, интегрированная с AD)
На Cisco ISE были использованы следующие политики:
802.1x c EAP-MD5 – для всех подключаемых устройств
802.1x c EAP-TTLS – для всех подключаемых устройств
Доменная машина с Windows
Kali с Fenrir-ом
Описание атаки
Пробуем подключиться к порту свича, сети нет.
Подключаем доменный комп в интерфейс нашей kali, другой интерфейс подключаем к коммутатору.
Запускаем консоль Fenrir и настраиваем параметры моста: указываем MAC- и IP- адреса свича и клиента. Вводим команду create_virtual_tap
Видим, что появился новый интерфейс FENRIR. Прописываем для него IP-адрес.
Вводим команду run в консоли Fenrir и подключаемся к сети. Теперь мы можем сканить nmap-ом и запускать другие полезные тулзы типа crackmapexec.
Ограничения
Нужно как-то пронести устройство на территорию. Более того, воткнуть между коммутатором и авторизованным устройством. Если нет авторизованного устройства, ничего не получится.
Мы получаем доступ аналогичный тому, который имеет авторизовавшееся устройство. То есть если мы воткнемся между принтером и коммутатором, с одной стороны классно – мы сразу попали в сеть… а с другой - мы всего лишь жалкий принтер.
Как защититься?
Для защиты от дурака обхода MAB придумали профилирование. Например, в Cisco ISE есть профили для Windows, для разных моделей принтеров и т.д. Если настроена политика разрешать доступ по MAB-у только принтерам, подмена MAC хакеру уже не поможет. Хорошо настроенное профилирование обойти достаточно сложно, так как злоумышленник не знает ни параметров профилирования (какие метрики собираются для идентификации устройства), ни параметров устройства (точные значения этих метрик).
Что касается защиты от атак на EAP, стоит отказаться от EAP-MD5 либо использовать достаточно сильные пароли. В случае с EAP-TTLS/EAP-PEAP/EAP-TLS/EAP-TTLS нужно принудительно запретить установку соединения, если сертификат сервера невалиден.
Для защиты от MITM-атак могут помочь разные виды детекта аномалий в сети. Если хакер, подключившись к порту, запустит брут или скан, неадекватное поведение хоста можно будет легко обнаружить и заблокировать порт. Однако, чем тише поведёт себя хакер, тем сложнее будет его обнаружить. Детект аномалий ― вещь хорошая, но 100%-ной защиты не даёт. Для 100%-ной защиты от MITM-атак нет ничего лучше, чем сейф шифрование. Например, IPsec.
А ещё есть 802.1xАЕ, также известный как 802.1x-2010, который предусматривает шифрование. Правда, уже после аутентификации.
802.1x AE
Разработан специально для решения проблемы с MITM-атаками и включает протокол MACSec для шифрования трафика на уровне L2.
Соединение проходит в 3 этапа:
Аутентификация и распределение ключей. Предполагается, что аутентификация проходит с использованием одного из методов EAP, однако протокол позволяет также использовать PSK.
Согласование сеансового ключа
Создание безопасной сессии
Рассмотрим пример с EAP-аутентификацией.
Как было описано ранее (см. «Механизм аутентификации), когда клиент впервые подключается к порту коммутатора, аутентификатор отправляет EAPRequest-Identity клиенту. Клиент отвечает EAP-response, который пересылается серверу Аутентификации.
На следующем этапе клиент и сервер аутентификации согласовывают метод EAP, который будет использоваться для аутентификации. Далее клиент аутентифицируется по выбранному методу EAP. В случае успешной аутентификации клиент и аутентификатор устанавливают зашифрованный канал связи по протоколу MACSec.
Как видим, MACSec хорошо работает против классических bridged-based атак: встроить свои пакеты в зашифрованный трафик уже не получится. Однако атаки на слабые методы EAP (Rouge Gateway или атака на EAP-MD5) остаются актуальными.
Выводы
Большинство современных организаций если и внедряют NAC в корпоративной сети, то ограничиваются первой версией протокола 802.1x, которая не предусматривает шифрования канала после аутентификации. Как показано в статье, для злоумышленников не составит труда встроить свой трафик в такой канал (классическая bridged-based атака).
Внедрение шифрования - 802.1AE либо IPSec сопряжено с большими трудностями: как минимум, потребуется установка дополнительных компонентов на каждое клиентское устройство.
Даже при успешном внедрении 802.1AE остаются актуальными атаки, направленные на уязвимости EAP (Rouge Gateway или атака на EAP-MD5).
Идеальная конфигурация, которая на 99,9% защитила бы LAN от обхода авторизации, выглядит примерно так:
Всем устройствам вроде принтеров, телефонов и тп, на которые нельзя поставить клиент для macsec, устанавливается минимальный необходимый доступ.
На всех остальных устройствах используется MAСsec+EAP-TLS (с обязательной проверкой сертификата сервера)
На всех транковых портах (которым коммутаторы соединяются между собой) используется macsec+NEAT (это когда вышестоящий коммутатор авторизует нижестоящий), чтобы минимизировать риск MITM-атаки на межкоммутаторных портах.