Комментарии 37
Одно непонятно: как можно перехватить хэш и сбрутить его, если используется WPA2 Enterprise, а не WPA2-PSK? Разве для этого есть инструментарий?
man aircrack-ng
А если серьёзно, то достаточно немного подумать нестандартно. А чём проблема с помощью airbase-ng создать honeypot?
Для перехвата хэша WPA Enterprise используется такая техника, как Evil Twin. Она заключается в том, что атакующий разворачивает точку доступа с именем (и настройками) целевой WiFi сети. Легитимный клиент, который подключается к подменной точке доступа передает ей свой хэш (или plain text пароль), который можно отправить на брут.
В ручном режиме эту атаку можно проводить с помощью hostapd-wpe или hostapd-mana (модификации hostapd). Для автоматизации можно использовать EAPhammer, airgeddon.
Конечно. Логин передается в открытом виде, хеширование пароля NetNTLMv1.
Например, можно использовать airgeddon, но это просто надстройка
Не увидел рассмотрения двух вариантов:
1)Забить на безопасность wi-fi, wi-fi даёт доступ только к VPN шлюзу. Безопасность за счёт VPN шлюза.
2)а если двухфакторку через радиус?
Не встречался с такими решениями в процессе тестирований, по этому точно не могу сказать, на сколько они будут жизнеспособные и безопасные. Хотя на мой взгляд они, как минимум, достойны рассмотрения и попытки внедрения (и тестирования на проникновение).
Подобные решения, которые представляют собой сочетания разных технологий, я не описывал, так как сам их не внедрял и не администрировал.
Также хотел ограничиться только тем, что уже есть на руках, чтобы не поднимать вопрос о дополнительных денежных тратах.
Мы используем сертификаты для подключения к WIFI которые выдаем на два года.
Так же встречал реализацию через CaptivPortal, клиент вводит учетные данные на портале и получает индивидуальный PSK для своего устройства. Сеть одна, а PSK у всех разные и каждое устройство персонализировано.
Выход есть)
Кажется про 18 этаж автор зря налегает. Недавно были новости про коптер севший на крышу, с оборудованием для взлома. Ну и не забываем про возможность "забыть" где-то raspberry pi. с хорошим powerbank.
Я бы выбрал просто направленную антенну.
Запарковать грузовичёк с брезентовым тентом. А под тентом хоть полутораметровая тарелка.
А на каком этапе вы бы предложили использовать дрон или закладку в виде Raspberry Pi?)
сразу ее закинуть, и через нее изучать куда мы попали.
Дрон в той истории, на мой взгляд, как doom запущенный в блокноте: интересно, но вряд ли применимо на каждый день :)
Закладку в виде Raspberry Pi действительно иногда удобно делать. Это может немного усложнить атаку (затраты, проникновение и пр.), но такие действия имеют место быть, если других вариантов не остается.
В обоих вариантах решения есть один общий шаг: мобильных клиентов надо убрать в отдельную PSK сеть с большим жирным паролем и доступом только в интернет
зачем в этом случае жирный пароль? если бы не всякие истории вроде этой, я бы рассматривал беспарольный wifi.
а для доступа во внутреннюю сеть тем, кому она нужна, вполне можно использовать vpn (например, ipsec сегодня из коробки есть практически везде).
P. S. давно думаю о том, что использование авторизации доменным паролем во всяких внешних сервисах — зло.
сохранённые плайнтекстом пароли в браузере, почтовом клиенте…
Мое представление о безопасности базируется на принципе, что надо выстраивать большое количество препятствий для атакующих (как больших, так и мелких), которые затрудняют его продвижение.
Сильный пароль в этом случае играет как раз именно роль небольшого препятствия. Можно ли его обойти? Конечно. Как минимум увидеть на табличках, спросить у секретаря и т.п. Усложнит это атаку? Немного, но да. И чем больше таких препятствий, тем меньшее количество атакующих будут тратить свои силы на них (им проще пойти на "старую дверь" у соседа).
Например, MAC фильтр конечно легко обойти, взяв MAC легитимного клиента. Но если вместе с ним включен Management Frame Protection, то легитимного клиента уже не отключишь. Следовательно, надо ждать, пока он сам уйдет. Это растягивает атаку во времени и делает ее дороже.
Также и здесь. Можем мы оставить гостевую сеть открытой? Можем. И возможно на данный момент развития техник, атакующий не сможет как то проникнуть внутрь из нее или получить дополнительные данные. Но время идет вперед и мы не можем знать, какие атаки появятся в будущем. На мой взгляд, проще не давать атакующему "ни пяди земли", полностью сковать его действия, нежели пускать хоть куда то, будучи уверенным в безопасности этой части инфраструктуры.
Мое представление о безопасности базируется на принципе, что надо выстраивать большое количество препятствий для атакующих (как больших, так и мелких), которые затрудняют его продвижение
ИМХО это идеологически ближе к security by obscurity.
с моей точки зрения правильнее минимизировать защищаемый периметр и сконцентрировать все усилия на ключевых точках.
На мой взгляд, проще не давать атакующему "ни пяди земли", полностью сковать его действия, нежели пускать хоть куда то, будучи уверенным в безопасности этой части инфраструктуры
тут я вижу два недостатка:
- теряется чёткое разграничение между защищённым и незащищённым, появляется соблазн вроде «ну wifi-сеть у нас защищена паролем, так что давайте сделаем из неё сделаем доступ к файл-серверу» (а пароль от сети в это время висит на бумажке на доске объявлений);
- «наворачивание» ступеней защиты портит жизнь не только злоумышленникам, но и обычным пользователям.
возможно на данный момент развития техник, атакующий не сможет как то проникнуть внутрь из нее или получить дополнительные данные
моё предложение: считаем весь wifi недоверенной средой, относимся к клиенту, подключенному через wifi, так же, как мы относимся к клиенту, подключенному через интернет (а с подключенными через интернет клиентами так и так приходится уметь работать).
какие угрозы вы рассматриваете?
что злоумышленник будет сниффить трафик/вламывать телефоны и ноутбуки сотрудников? так эти угрозы есть и в случае, если сотрудник со своим телефоном сидит в кафе, так или иначе с ними нужно бороться.
что злоумышленник взломает wifi-точки и попытается так проникнуть во внутренний периметр? так точки не должны быть в нём.
а что про проверку сертификата радиус сервера никто не написал? если прописать в настройках подключении сертификат, то телефон не будет разговаривать с поддельной точкой доступа
По проверке мобильным устройством сертификата RADIUS сервера при подключении ситуация такая: мы можем сгенерировать сертификат, например, с помощью ZeroSSL. Мобильный клиент не проверяет имя и принадлежность сертификата к серверу (а-ля HTTPS). Для него главное, чтобы сертификат был выпущен доверенным центром (коим ZeroSSL и Let`s Encrypt являются).
Что получаем:
iPhone - на тестах в лабораторных условиях мои исследования еще в процессе, но пока не удается заставить iPhone (с последними обновлениями и дефолтными настройками) подключиться без действий пользователя. Но в процессе выполнения реальных атак я получал подключение от Apple устройств и пользователь там ничего не выбирал сам (обстоятельства в процессе выяснения);
Android - совершенно без проблем подключается к точке без действий пользователя и в лабораторных условиях, и на реальных проектах.
Два слова: zero trust
Ещё одно доказательство того, почему не стоит пользователям в компании делать доступ на рабочие машины через wifi. Знал о такого рода возможностях, но не думал, что настолько "просто".
Еще один Плюс за " Вариант №2: аутентификация доменных компьютеров. " - соединение с сетью проиходит еще до User Login, практически сразу после загрузки.
3 года назад изменил в связке Cisco WLC - MS NPS на аутентификацию по учеткам компьтеров. С тех тор практически ни одной проблемы в корпоративной WiFi.
А все остальные , левые, гостевые и домашние, - в отдельную SSID, правда использую тоже 802.1X , без привязки к корпоративному MS NPS. Отдельный Radius с User Portal стоит.
Получается вы на NPS подкрутили профили таким образом, что вместо логина пароля у пользователя при подключении к сети проверяется принадлежность в устройства соответствующей доменной группе, которой разрешено подключение? Если есть возможность подкиньте пожалуйста ссылок как правильно подкрутить NPS?
на вскидку - https://networkguy.de/wlan-with-802-1x-radius-nps-authentication/
я работаю с Cisco, но принцип тот же:
Radius - Client - Cisco WLC
дальше по картинкам.
Auth - EAP (PEAP )
Netzwerkrichtlinien (network policies ) - из группы MS AD
пс. я из немногих ИТ-шников без английского. работаю на немецком.
Важно, разумеется все компьютеры должны иметь учетную запись в MS AD.
Автору спасибо за статью! Если можно подскажите где почитать как правильно реализовать Вариант №2 и не ошибиться в стыковке NPS и WLC от Huawei например?
У вас WPA Enterprise PEAP/TTLS? Тогда мы уже у вас