Freeradius
FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.
yum install freeradius freeradius-utils freeradius-ldap -yLinux
Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.
Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.
Будем подключаться по домену. Поэтому нужен сертификат удостоверяющего центра, у которого был приобретен наш сертификат.
Все подключение делается в одном окне. Выбираем нашу сеть:
anonymous — clientdomain — домен, на который выпущен сертификат
Non-samsung
C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:
domain — домен, на который выпущен сертификатanonymous — client
Samsung
Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.
Скачиваем сертификат себе на устройство и устанавливаем его.
Когда сертификат установлен, можно переходить к подключению:
сертификат — указываем тот, который устанавливалианонимный пользователь — guest
Windows 10
Сложность сводится к тому, что Windows пока еще не умеет подключаться к корпоративному WiFi по домену. Поэтому приходится вручную закидывать наш сертификат в хранилище доверенных сертификатов. Здесь можно использовать как самоподписанный так и от центра сертификации. Я буду использовать второй.
Далее нужно создать новое подключение. Для этого идем в параметры сети и Интернет -> Центр управления сетями и общим доступом -> Создание и настройка нового подключения или сети:
Вручную прописываем имя сети и меняем тип безопасности. После нажимаем на изменить параметры подключения и во владке Безопасность выбираем проверку подлинности сети — EAP-TTLS.
Заходим в параметры, прописываем конфиденциальность аутентификации — client. В качестве доверенного центра сертификации выбираем добавленный нами сертификат, ставим галочку «Не выдавать пользователю приглашение, если не удается авторизовать сервер» и метод проверки подлинности выбираем — незашифрованный пароль (PAP).
Возможные вопросы
В:
как передавать профиль/сертификат сотруднику?
О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп. Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.
В: почему не использовать схему с MSCHAPv2? она же более безопасная!
О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность
В: можно ли авторизовывать устройтсва по mac-адресам?
О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах
В: зачем вообще все эти сертификаты использовать? можно же и без них подключаться
Как взламывают корпоративный wi-fi: новые возможности
В статье рассказывается о взломе WPA2-Enterprise с аутентификация через RADIUS-сервер.
Автор: Дмитрий Трифонов, исследовательский центр Positive Technologies
Статей о взломе Wi-Fi в Интернете достаточно много, но большинство из них касаются режима работы WEP/WPA(2)-Personal, в котором необходимо перехватить процедуру «рукопожатия» клиента и Wi-Fi-точки. Во многих корпоративных Wi-Fi-сетях используется режим безопасности WPA2-Enterprise, с аутентификацией по логину и паролю — как наименее затратный способ. При этом аутентификация осуществляется с помощью RADIUS-сервера.
ОС клиента устанавливает соединение с RADIUS-сервером, используя шифрование при помощи TLS, а проверка подлинности в основном происходит при помощи протокола MS-CHAPv2.
Для тестирования на проникновение в такой сети мы можем создать поддельную Wi-Fi-точку с RADIUS-сервером — и получить логин, запрос и ответ, которые использует MS-CHAPv2. Этого достаточно для дальнейшего брутфорса пароля.
Нам необходимы Kali Linux и карточка, поддерживающая работу в режиме Access Point, что можно проверить при помощи команды iw list, нас интересует строка:
* #{ AP, mesh point } <= 8,
Еще год назад нужно было проделать множество манипуляций для того, чтобы подделать такую точку доступа с возможностью получения учетных данных. Необходимо было пропатчить, собрать и правильно настроить определенные версии hostapd и FreeRADIUS. В августе 2021 года появился набор инструментов Mana Toolkit, позволяющий автоматизировать множество векторов атак на беспроводные клиенты.
Поскольку использовать ноутбук не всегда удобно, будем использовать более компактный вариант — телефон. Кроме того, можно использовать Raspberry Pi FruityWifi. WiFi Pineapple, к сожалению, не поддерживает Mana.
Запускаем Kali
Подключаем Wi-Fi-карточку через USB-OTG-кабель. Запускаем приложение NetHunter.
Первое, что необходимо сделать, — определить интерфейс подключенной Wi-Fi-карточки. Для этого в меню выбираем Kali Launcher и запускаем Wifite.
В нашем случае это интерфейс wlan1.
В меню выбираем MANA Evil Access Point.
Настраиваем точку:
- интерфейс, определенный на предыдущем шаге (interface),
- SSID взламываемой Wi-Fi-сети (ssid)
- использование протокола аутентификации 802.1x(ieee8021x=1),
- опции wpa(wpa) (0 = без WPA/WPA2; 1 = WPA; 2 = IEEE 802.11i/RSN (WPA2); 3 = WPA и WPA2),
- список принимаемых алгоритмов управления ключами (wpa_key_mgmt=WPA-EAP),
- набор принимаемых алгоритмов шифрования (wpa_pairwise),
Отключаем karma (enable_karma=0), указываем буфер, в который будут направляться полученные логины и хеши (ennode).
В нашем распоряжении комплект из пяти скриптов, которые запускают, помимо точки доступа, дополнительные утилиты для осуществления MITM-атак. Нас интересует скрипт mana-noupstream-eap, который предназначен для точек с аутентификацией 802.1x.
По умолчанию скрипт пытается «сбрутить» полученный хеш, подключить клиент и провести MITM-атаку. Поскольку взлом хешей на телефоне — не самая лучшая идея, комментируем ненужные строки, добавляем команду, которая будет записывать перехваченные данные в файл на флешке, — и запускаем Mana.
Как только Wi-Fi-клиент окажется достаточно близко к нашей точке доступа, он попробует аутентифицироваться на ней. Хорошее место для засады — у входа в офис или бизнес-центр, время — начало или конец рабочего дня, когда потенциальные жертвы минуют проходную.
Останавливаем Mana и проверяем, что же мы поймали.
Формат полученных данных: Protocol | Login | Challenge | Response
Теперь можно в спокойной обстановке на нормальном компьютере взламывать полученные хеши.
В этом нам помогут:
— Asleap (используется в оригинальном скрипте),
— John the Ripper (требуется слегка модифицировать полученные хеши: cat HASHES.txt | sed ‘s/://g’ | sed ‘s/([^|]*)|([^|]*)|([^|]*)|([^|]*)/2:$NETNTLM$3$4/’ > john-HASHES.txt)
Полученные учетные записи можно использовать для дальнейшего проникновения в корпоративную сеть через Wi-Fi или VPN, а также для получения доступа к корпоративной почте.
Как оказалось, перехватить хеши пользователей можно не всегда. Настольные ОС (Windows, MacOS, Linux), а также пользователи iOS защищены лучше всего. При первичном подключении ОС спрашивает, доверяете ли вы сертификату, который используется RADIUS-сервером в данной Wi-Fi-сети. При подмене легитимной точки доступа ОС спросит про доверие к новому сертификату, который использует RADIUS-сервер. Это произойдет даже при использовании сертификата, выданного доверенным центром сертификации (Thawte, Verisign).
При использовании устройств на базе Android сертификат по умолчанию не проверяется, но существует возможность указать корневой сертификат, который может использоваться в данной Wi-Fi-сети.
Устройства на основе Windows Phone по умолчанию проверяют сертификат. Также доступны опции проверки сертификата сервера:
- нет;
- всегда спрашивать;
- центр сертификации.
Резюмируя все сказанное, эксперты Positive Technologies рекомендуют следующие меры безопасности:
- пользователям — проверять сертификаты при подключении не только к интернет-банку, но и к корпоративному Wi-Fi;
- пользователям Android — установить корневой сертификат, который используется в корпоративной сети;
- администраторам — перейти на использование аутентификации на основе сертификатов (или не удивляться, если перед входом в офис периодически будут появляться люди с телефоном и антенной).
Контроллер ubiquiti
На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24
Идем в настройки -> профиль. Cоздаем новый:
Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:
Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:
Все сохраняем, применяем и идем дальше.
Настройка клиентов
Начнем с самого сложного!
Немного о методах eap
Прежде чем приступить к выполнению задачи, надо определиться какой метод аутентификации будем использовать в нашем решении.
Из википедии:
EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями называемыми методами EAP. Существует множество методов EAP, как определенных вместе с самим EAP, так и выпущенных отдельными производителями. EAP не определяет канальный уровень, он только определяет формат сообщений. Каждый протокол использующий EAP имеет собственный протокол инкапсуляции сообщений EAP. Сами методы:
- LEAP — проприетарный протокол, разработан CISCO. Найдены уязвимости. В настоящее время не рекомендуется использовать
- EAP-TLS — хорошо поддерживаемый среди вендоров беспроводных соединений. Является безопасным протоколом, поскольку является преемником SSL стандартов. Настройка клиентской достаточно сложна. Нужен клиентский сертификат помимо пароля. Поддерживается во многих системах
- EAP-TTLS — широко поддерживается во многих системах, предлагает хорошую безопасность, используя PKI сертификаты только на сервере аутентификации
- EAP-MD5 — другой открытый стандарт. Предлагает минимальную безопасность. Уязвим, не поддерживает взаимную аутентификацию и генерацию ключей
- EAP-IKEv2 — основан на Internet Key Exchange Protocol version 2. Обеспечивает взаимную аутентификацию и установление сеансового ключа между клиентом и сервером
- PEAP — совместное решение CISCO, Microsoft и RSA Security как открытый стандарт. Широко доступен в продуктах, обеспечивает очень хорошую безопасность. Схож с EAP-TTLS, требуя только сертификат на серверной стороне
- PEAPv0/EAP-MSCHAPv2 — после EAP-TLS, это второй широко используемый стандарт в мире. Используется клиент-серверная взаимосвязь в Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — создан Cisco как альтернатива PEAPv0/EAP-MSCHAPv2. Не защищает аутентификационные данные в любом случае. Не поддерживаются в Windows OS
- EAP-FAST — метод, разработанный Cisco для исправления недостатков LEAP. Использует Protected Access Credential (PAC). Полностью не доработан
Из всего этого разнообразия, выбор все таки не велик. От метода аутентификации требовалось: хорошая безопасность, поддержка на всех устройствах (Windows 10, macOS, Linux, Android, iOS) и, собственно, чем проще, тем лучше. Поэтому выбор пал на EAP-TTLS в связке с протоколом PAP.
Возможно возникнет вопрос — Зачем же использовать PAP? ведь он передает пароли в открытом виде?