В этом посте хочу поделиться историей одной гениально простой атаки, которую наблюдал в прошлом году, и обсудить последствия. Здесь не будет «мяса» для хакеров, но будет:
В принципе, все актуально и для корпоративных сетей, но для них я уже писал. А тут соседний пост заставил глянуть на проблему под несколько иным углом.
Прежде всего, я не навязываю и не призываю срочно бежать и покупать крутой Wi-Fi с WIPS и RTLS. В каждой ситуации будут свои нюансы и приоритеты: кто-то прикроется пользовательским соглашением, кому-то просто плевать на пользователей, в каких-то странах не предусмотрено ответственности, где-то достаточно частичных мер, у кого-то еще какие-то нюансы. Я описываю — каждый выбирает сам.
История приключилась с моим коллегой в гостинице, где мы остановились. Я под раздачу не попал только потому, что к этому времени еще не подключился к гостиничной WLAN. Гостиница предоставляет Wi-Fi бесплатно всем своим гостям. Сеть запаролена, PSK выдается на бумажке и меняется раз в несколько месяцев.
Коллега подключает ноутбук к сети, открывает Firefox, пишет адрес какого-то хорошо знакомого сайта. Вместо сайта появляется красивая страничка с заголовком сайта гостиницы и сообщением вида «Ваш браузер несовместим с сайтом, который вы пытаетесь открыть. Установите патч отсюда». Коллега впечатляется, запускает Chrome — та же страничка. Подключаем к сети Android и iPod Touch — то же самое. При этом «патч» всегда один и тот же :) Скачиваем «патч» — вполне ожидаемо ругается антивирус (нашли 3 разных типа malware).
В общем, сюжет очевиден — албанский вирус, распространяющийся фишингом и небольшим хаком в сети. Сам вирус интереса не представляет — интерес представляет понять, как всё это работает, чтобы таки получить доступ в Интернет без «патча».
Путем некоторых простых исследований (на уровне ipconfig/ping) было выяснено, что на сайты можно заходить по IP. Значит проблема в DNS. Прописав DNS 8.8.8.8 мы получили полноценно работающий интернет. Теперь можно разбираться, как же работает атака.
Было выяснено следующее:
Как видите — все очень просто и не требует особых навыков для реализации. Вопрос: сколько «обычных людей» на это поведется?
Также, странно, что злоумышленник ограничился «патчем» и не нарисовал заглавных страниц GMail/Bing/Facebook и т.д. — можно было бы насобирать аккаунтов, даже с HTTPS: сколько людей обращает внимание на кривые сертификаты или на то, что их только что редиректнули с HTTPS на HTTP? Хотя, если на машине три трояна — они уже сами все насобирают…
При построении любой сети доступа важно не только защитить эту сеть и проводную инфраструктуру от «излишнего интереса» пользователей, но и защитить одних пользователей от других, менее порядочных. Это актуально и для корпоративных (приватных) сетей, и для публичных сетей (хотспоты, гостиницы, кафе-бары-рестораны и т.д.). При этом стоит помнить, что «беспроводная безопасность» — это не только шифрование: должны также присутствовать идентификация, аутентификация, разделение трафика и много чего другого. Описанная выше атака — не единственная чисто беспроводная атака, которую не определит ни один Firewall или IPS в проводном сегменте. Что же делать, чтобы такой проблемы не возникло?
Самое простое решение — запретить коммуникации между пользователями. Обычно, это делается включением/выключением одной галочки в настройках WLAN («Disable MU-to-MU communication», Cisco PSPF и аналоги). Однако, это не всегда нравится пользователям хотспотов и может противоречить целям использования сети (геймерские тусовки, VoWLAN в корпоративных сетях, и проч.). Хотя — если не противоречит — как уже было сказано, проще всего сделать именно так, и прописать этот пункт в «правилах пользования».
Лучший способ — запретить DHCP-, DNS- и (за компанию) и ARP-ответы в беспроводной сети. Для этого нужно иметь файрвол прямо на точке доступа, способный фильтровать трафик WLAN-to-WLAN (периодически это называют Wireless Firewall для подчеркивания отличия от традиционных FW). Для меня в свое время было большим удивлением, что некоторые именитые вендоры этого не умеют (и по сей день).
DNS и DHCP ответы разрешаются только от проводных хостов. ARP ответы от клиентов вообще не нужны — точка все равно знает все MAC-адреса клиентов (при ассоциации) и сможет ответить на запросы через Proxy ARP, так что заодно уменьшается количество паразитного трафика в сети.
Таким образом мы избавляемся от DHCP/DNS/ARP-spoofing'а, rogue DHCP/DNS, APR-poisoning'а, связанных с ними MiTM-атак (и, наверное, еще много чего — дополняйте в комментариях).
Теперь, давайте обратим внимание на другой аспект. Вот я обнаружил поддельный сервер в сети. Я могу его заблокировать по MAC. Но если злоумышленник не дурак и периодически проверяет активность своей мышеловки, он это заметит, сменит MAC, и все продолжится. Кроме того, зная PSK, злоумышленник может вбрасывать пакеты в сеть пользователям даже не будучи подключенным к точек доступа, и даже с WPA2. Для этого надо изрядно постараться, т.к. в WPA/WPA2 распределение ключей посложнее, чем в WEP, но это возможно. Единственный способ избавиться от супостата — поменять PSK. А потом поменять его для всех клиентов! Да и это, хоть и отобьет атаку, не позволит найти и наказать злоумышленника (если не использовать системы позиционирования). А что уж говорить про открытые хотспоты?
Таким образом, в публичных сетях, даже если они защищены PSK, как сеть нашей гостиницы, злоумышленник остается безнаказанным практически всегда.
Другое дело — использовать Captive Portal (только грамотно использовать) или 802.1x (заодно решает проблему с вбросом трафика, но в публичных сетях использовать 802.1x cложновато все-же). Каждый пользователь получает индивидуальные имя и пароль, к которым при логине привязывается MAC-адрес, аккаунт работает ограниченное время (в гостиничных системах строят автоматизацию для привязки к вписке-выписке). Таким образом, мы всегда можем вычислить, кто это забавляется, или, хотя бы, через кого произошла утечка идентификационных данных.
Оба этих нюанса чрезвычайно важны в такой опасной и увлекательной игре как перекладывание ответственности. Если у вас в пользовательском соглашении не зафиксирован отказ от ответственности (а не всегда это можно сделать, плюс, надо убедиться, что пользователь не может получить доступ к сети не согласившить с правилами использования ресурса), если через вашу сеть будут идти взломы, порно, пропаганда расизма/насилия и проч, и если вы не сможете найти крайнего — крайним назначат вас. Именно поэтому, в результате буйного разгула фишинга на хотспотах в Европе ввели обязательную идентификацию каждого пользователя на законодательном уровне (чаще всего, требуется ввести номер мобильного на который приходит SMS с индивидуальным кодом доступа). Понятно, что от этого тоже можно скрыться, но таким образом провайдер хотспота перекладывает ответственность на провайдера SIM-карты. Даже без использования аутентификации Captive Portal может перед тем как дать доступ показать заставку с «правилами использования ресурса» и заставить пользователя ткнуть в галочку «я принимаю условия», чего во многих случаях уже достаточно с правовой точки зрения (и пользователь потом не отвертится, что не видел соглашения). Так что, иногда открытая сеть с Captive Portal'ом может оказаться безопаснее закрытой сети с PSK — для ее владельцев :)
Как альтернатива, некоторые вендоры (Aerohive, Ruckus) реализуют нестандартную технологию «индивидуальных PSK», где каждому клиенту выдается свой уникальный ключ. Таким образом тоже решаются проблемы идентификации пользователей и массовой смены PSK при его утечке. Однако, доступность их в странах СНГ весьма ограничена, и иногда наблюдаются проблемы с совместимостью.
В беспроводных сетях защита беспроводных пользователей от целиком беспроводных атак не менее важна, чем защита проводного сегмента. С помощью довольно несложных технических средств можно наладить фишинг в промышленных масштабах и другие атаки — и ни один проводной Firewall/IPS не поможет.
Существуют технические меры, позволяющие ограничить доступ беспроводных пользователей к другим беспроводным пользователям:
Все вышеперечисленное актуально для любых сетей (инсайдерские взломы никто не отменял), но особенно важно для сетей публичных (хотспоты, гостиницы, КаБаРе и т.д.) с точки зрения
Надеюсь, было интересно.
- Плюс одна поучительная байка в коллекцию «для бесед с пользователями» админам и безопасникам.
- Почему в беспроводных сетях защищать нужно не только LAN от WLAN, и зачем нужен т.н. Wireless Firewall.
- Рекомендации, как построить публичную сеть Wi-Fi для избежания подобных проблем.
- Почему в гостиницах и других публичных сетях даже незашифрованный Captive Portal может оказаться предпочтительнее шифрования с PSK.
В принципе, все актуально и для корпоративных сетей, но для них я уже писал. А тут соседний пост заставил глянуть на проблему под несколько иным углом.
Прежде всего, я не навязываю и не призываю срочно бежать и покупать крутой Wi-Fi с WIPS и RTLS. В каждой ситуации будут свои нюансы и приоритеты: кто-то прикроется пользовательским соглашением, кому-то просто плевать на пользователей, в каких-то странах не предусмотрено ответственности, где-то достаточно частичных мер, у кого-то еще какие-то нюансы. Я описываю — каждый выбирает сам.
Предыстория
История приключилась с моим коллегой в гостинице, где мы остановились. Я под раздачу не попал только потому, что к этому времени еще не подключился к гостиничной WLAN. Гостиница предоставляет Wi-Fi бесплатно всем своим гостям. Сеть запаролена, PSK выдается на бумажке и меняется раз в несколько месяцев.
История
Коллега подключает ноутбук к сети, открывает Firefox, пишет адрес какого-то хорошо знакомого сайта. Вместо сайта появляется красивая страничка с заголовком сайта гостиницы и сообщением вида «Ваш браузер несовместим с сайтом, который вы пытаетесь открыть. Установите патч отсюда». Коллега впечатляется, запускает Chrome — та же страничка. Подключаем к сети Android и iPod Touch — то же самое. При этом «патч» всегда один и тот же :) Скачиваем «патч» — вполне ожидаемо ругается антивирус (нашли 3 разных типа malware).
В общем, сюжет очевиден — албанский вирус, распространяющийся фишингом и небольшим хаком в сети. Сам вирус интереса не представляет — интерес представляет понять, как всё это работает, чтобы таки получить доступ в Интернет без «патча».
Разбираемся
Путем некоторых простых исследований (на уровне ipconfig/ping) было выяснено, что на сайты можно заходить по IP. Значит проблема в DNS. Прописав DNS 8.8.8.8 мы получили полноценно работающий интернет. Теперь можно разбираться, как же работает атака.
Было выяснено следующее:
- Во WLAN сидел еще один DHCP-сервер (rogue DHCP), который выдавал корректные IP/mask/GW, но выдавал «свой» DNS-сервер вместо правильного провайдерского.
- На том же хосте был поднят тот самый DNS-сервер, который все имена резолвил в один и тот же IP (который «по невероятному стечению обстоятельств» совпадал с IP DNS-сервера).
- На том же IP был поднят веб-сервер, который, собственно, и показывал страничку и отдавал файл.
Как видите — все очень просто и не требует особых навыков для реализации. Вопрос: сколько «обычных людей» на это поведется?
Также, странно, что злоумышленник ограничился «патчем» и не нарисовал заглавных страниц GMail/Bing/Facebook и т.д. — можно было бы насобирать аккаунтов, даже с HTTPS: сколько людей обращает внимание на кривые сертификаты или на то, что их только что редиректнули с HTTPS на HTTP? Хотя, если на машине три трояна — они уже сами все насобирают…
Выводы и способы решения
При построении любой сети доступа важно не только защитить эту сеть и проводную инфраструктуру от «излишнего интереса» пользователей, но и защитить одних пользователей от других, менее порядочных. Это актуально и для корпоративных (приватных) сетей, и для публичных сетей (хотспоты, гостиницы, кафе-бары-рестораны и т.д.). При этом стоит помнить, что «беспроводная безопасность» — это не только шифрование: должны также присутствовать идентификация, аутентификация, разделение трафика и много чего другого. Описанная выше атака — не единственная чисто беспроводная атака, которую не определит ни один Firewall или IPS в проводном сегменте. Что же делать, чтобы такой проблемы не возникло?
Самое простое решение — запретить коммуникации между пользователями. Обычно, это делается включением/выключением одной галочки в настройках WLAN («Disable MU-to-MU communication», Cisco PSPF и аналоги). Однако, это не всегда нравится пользователям хотспотов и может противоречить целям использования сети (геймерские тусовки, VoWLAN в корпоративных сетях, и проч.). Хотя — если не противоречит — как уже было сказано, проще всего сделать именно так, и прописать этот пункт в «правилах пользования».
Лучший способ — запретить DHCP-, DNS- и (за компанию) и ARP-ответы в беспроводной сети. Для этого нужно иметь файрвол прямо на точке доступа, способный фильтровать трафик WLAN-to-WLAN (периодически это называют Wireless Firewall для подчеркивания отличия от традиционных FW). Для меня в свое время было большим удивлением, что некоторые именитые вендоры этого не умеют (и по сей день).
DNS и DHCP ответы разрешаются только от проводных хостов. ARP ответы от клиентов вообще не нужны — точка все равно знает все MAC-адреса клиентов (при ассоциации) и сможет ответить на запросы через Proxy ARP, так что заодно уменьшается количество паразитного трафика в сети.
Таким образом мы избавляемся от DHCP/DNS/ARP-spoofing'а, rogue DHCP/DNS, APR-poisoning'а, связанных с ними MiTM-атак (и, наверное, еще много чего — дополняйте в комментариях).
Теперь, давайте обратим внимание на другой аспект. Вот я обнаружил поддельный сервер в сети. Я могу его заблокировать по MAC. Но если злоумышленник не дурак и периодически проверяет активность своей мышеловки, он это заметит, сменит MAC, и все продолжится. Кроме того, зная PSK, злоумышленник может вбрасывать пакеты в сеть пользователям даже не будучи подключенным к точек доступа, и даже с WPA2. Для этого надо изрядно постараться, т.к. в WPA/WPA2 распределение ключей посложнее, чем в WEP, но это возможно. Единственный способ избавиться от супостата — поменять PSK. А потом поменять его для всех клиентов! Да и это, хоть и отобьет атаку, не позволит найти и наказать злоумышленника (если не использовать системы позиционирования). А что уж говорить про открытые хотспоты?
Таким образом, в публичных сетях, даже если они защищены PSK, как сеть нашей гостиницы, злоумышленник остается безнаказанным практически всегда.
Другое дело — использовать Captive Portal (только грамотно использовать) или 802.1x (заодно решает проблему с вбросом трафика, но в публичных сетях использовать 802.1x cложновато все-же). Каждый пользователь получает индивидуальные имя и пароль, к которым при логине привязывается MAC-адрес, аккаунт работает ограниченное время (в гостиничных системах строят автоматизацию для привязки к вписке-выписке). Таким образом, мы всегда можем вычислить, кто это забавляется, или, хотя бы, через кого произошла утечка идентификационных данных.
Оба этих нюанса чрезвычайно важны в такой опасной и увлекательной игре как перекладывание ответственности. Если у вас в пользовательском соглашении не зафиксирован отказ от ответственности (а не всегда это можно сделать, плюс, надо убедиться, что пользователь не может получить доступ к сети не согласившить с правилами использования ресурса), если через вашу сеть будут идти взломы, порно, пропаганда расизма/насилия и проч, и если вы не сможете найти крайнего — крайним назначат вас. Именно поэтому, в результате буйного разгула фишинга на хотспотах в Европе ввели обязательную идентификацию каждого пользователя на законодательном уровне (чаще всего, требуется ввести номер мобильного на который приходит SMS с индивидуальным кодом доступа). Понятно, что от этого тоже можно скрыться, но таким образом провайдер хотспота перекладывает ответственность на провайдера SIM-карты. Даже без использования аутентификации Captive Portal может перед тем как дать доступ показать заставку с «правилами использования ресурса» и заставить пользователя ткнуть в галочку «я принимаю условия», чего во многих случаях уже достаточно с правовой точки зрения (и пользователь потом не отвертится, что не видел соглашения). Так что, иногда открытая сеть с Captive Portal'ом может оказаться безопаснее закрытой сети с PSK — для ее владельцев :)
Как альтернатива, некоторые вендоры (Aerohive, Ruckus) реализуют нестандартную технологию «индивидуальных PSK», где каждому клиенту выдается свой уникальный ключ. Таким образом тоже решаются проблемы идентификации пользователей и массовой смены PSK при его утечке. Однако, доступность их в странах СНГ весьма ограничена, и иногда наблюдаются проблемы с совместимостью.
Заключение
В беспроводных сетях защита беспроводных пользователей от целиком беспроводных атак не менее важна, чем защита проводного сегмента. С помощью довольно несложных технических средств можно наладить фишинг в промышленных масштабах и другие атаки — и ни один проводной Firewall/IPS не поможет.
Существуют технические меры, позволяющие ограничить доступ беспроводных пользователей к другим беспроводным пользователям:
- Запретить коммуникации между ними вообще (поддерживается почти всеми производителями, но не всегда приемлемо в сети)
- Запретить беспроводным пользователям посылать ответы важных сетевых сервисов: DHCP, DNS, ARP (гораздо лучше, но поддерживается не всеми и может не спасти от более сложных атак)
- Использование Captive Portal/802.1x/PPSK позволяет идентифицировать источки атаки или утечки пользовательских данных
- Специализированная Wireless IPS поможет прикрыться и от других атак
- Система позиционирования (RTLS) позволяет определить приблизительное физическое местоположение источника
Все вышеперечисленное актуально для любых сетей (инсайдерские взломы никто не отменял), но особенно важно для сетей публичных (хотспоты, гостиницы, КаБаРе и т.д.) с точки зрения
- Привлекательности для клиентуры: «меня/друга там хакнули — я туда больше не пойду» и т.п.
- Органиционных вопросов: можно быстро разрулить проблему и найти виновного; возможно, кто-то из своих сотрудников решил «подработать» и т.д.
- Легальных вопросов: можно переложить ответственность, если прижмут.
Надеюсь, было интересно.
