Атака пользователей WLAN через rogue-сервисы, или почему PSK — не самый лучший выбор для гостиницы

    В этом посте хочу поделиться историей одной гениально простой атаки, которую наблюдал в прошлом году, и обсудить последствия. Здесь не будет «мяса» для хакеров, но будет:
    • Плюс одна поучительная байка в коллекцию «для бесед с пользователями» админам и безопасникам.
    • Почему в беспроводных сетях защищать нужно не только 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) позволяет определить приблизительное физическое местоположение источника

    Все вышеперечисленное актуально для любых сетей (инсайдерские взломы никто не отменял), но особенно важно для сетей публичных (хотспоты, гостиницы, КаБаРе и т.д.) с точки зрения
    • Привлекательности для клиентуры: «меня/друга там хакнули — я туда больше не пойду» и т.п.
    • Органиционных вопросов: можно быстро разрулить проблему и найти виновного; возможно, кто-то из своих сотрудников решил «подработать» и т.д.
    • Легальных вопросов: можно переложить ответственность, если прижмут.

    Надеюсь, было интересно.
    Поделиться публикацией

    Похожие публикации

    Комментарии 25

      +1
      Интересно, но хочется больше конкретики. В частности есть ли бюджетные решения, позволяющие «запретить DHCP-, DNS- и (за компанию) и ARP-ответы в беспроводной сети», да ещё заставляющие принимать пользовательское соглашение.
        +1
        Любая нормальная реализация Captive Portal позволяет показать splah page и заставить пользователя ткнуть в галку.
        По Captive portal можно начать с этого: wiki.openwrt.org/doc/howto/wireless.hotspot. Насчет фильтрования WLAN-WLAN в бюджетных решениях точно сказать не могу — не мой профиль, не сталкивался. Но наверняка что-то есть. Спецы по Open/DD-WRT и проч. — отзовитесь! В крайнем случае, запретить разговоры между клиентами можно почти всегда.
          +2
          в dd-wrt делается
          элементарно
          image
            +1
            Это AP isolation, он убивает все коммуникации на корню — было бы странно, если бы его не было :)
            А можно именно ACL на WLAN повесить, чтобы выборочно трафик фильтровать?
              +1
              Если я правильно вас понял, то редактируются ACL тут. Но она вешается на out WLAN интерфейс.
          +2
          RB751U-2HnD 60-70 $
          RB951-2n 45-55 $
          умеет все вышеперечисленное и даже больше :)
            0
            MikroTik уважаю. RouterOS местами умеет то, чего не умеют некоторые Tier1 вендоры. Очень хороши как CPE. Некоторые на них провайдерские сети строят. Давно хотел себе взять, но если попытаться собрать достойную dual-radio точку доступа 2.4+5GHz (RB433/435 мать + 2xR52N-m + корпус + антенны = ) оказывается, что не так он и дешев… Да и взаимодействия между точками никакого.
          0
          А клиента защитит только его собственный VPN-сервер?

          Я долгое время пользовался DNS 8.8.8.8, но потом отказался — слишком часто бывали проблемы с недоступностью сайтов, в частности, самого Гугла.
            0
            Я не совсем понял про собственный VPN-сервер, но многие именно так и поступают, когда работают на открытых хотспотах. При этом сервер не обязательно должен быть собственным, если вы доверяете поставщикам сервисов типа OpenVPN.
            +1
            MiTM с DHCP и ARP спуфингом уже не особо взлетает. Зато остались еще более простые железобетонные способы харвестинга. Так что только VPN до доверенной сети, и всё.
              0
              Не совсем понял, почему злоумышленник остается безнаказанным, хотспот же распечатанный пароль к мак-адресу привязывает при первом подключении. Увидев такое в гостинице и обратившись к хозяину/менеджеру или кто там, можно узнать для кого был распечатан квиточек и сдать его в кутузку тут же. Разве нет?
                +2
                Пароль один у всех.
                  +1
                  А, ну это несерьезно. Зачем тогда вообще точку паролить, все равно, что секрет Полишинеля.
                  Я во Францию ездил, в отеле хотспот печатал одноразовые, как положено.
                    +1
                    Чтобы случайные прохожие не подключались как минимум. По сути сети с PSK являются почти публичными, работают на доверии, для «своих», но возможности идентифицировать злоумышленника или хотя бы канал утечки не предоставляют.

                    Не знаю как во Франции, но в России те цены, что предлагают интеграторы, для малого гостиничного бизнеса неприемлемы. Знаю не понаслышке — у друга две мини-гостиницы. Думали над этим вопросом, обращались в несколько контор с просьбой выслать коммерческое предложение — PSK компромисс между безопасностью (вернее несанкционированным доступом к сети) и стоимостью её обеспечения.
                      +1
                      Посмотрите на Ubiquiti UniFi. Достаточно интересное решение.
                      habrahabr.ru/company/comptek/blog/114722/
                        0
                        Спасибо. Оценим.
                        +1
                        Я работаю с железом Motorola. Посмотрите, доступны ли вам точки AP-6511 или AP-6521. Сеть до 24х точек работает без контроллера (распределенный форвардинг, одна из точек — виртуальный контроллер) с хотспотами, радиусами, роумингом, согласованием покрытия и прочими плюшками (полноценный роутер, stateful FW, и даже небольшой IPS в комплекте). Несколько ограничена по гибкости, по сравнению с решениями на «полновесном» контроллере, но лучше, чем отдельно стоящие точки. Цена — подороже, чем SOHO, но подешевле чем Cisco & Co.

                        AP-6511 сделана в формате телефонной розетки — специально для гостиниц (там есть некоторые интересные нюансы с размещением точек в гостиницах). Ставится за 2 минуты. Я когда-то писал статью на эту тему пару лет назад, но не уверен, что она актуальна для Хабра. AP-6521 — то же железо, но в стандартном исполнении.

                        Есть еще более забавное решение, работающее по телефонной паре (если в гостинице есть только телефония): MC-802. По-сути точки и контроллер с VDSL, точка ставится вместо телефонной розетки, контроллер «интегрируется» на кросс АТС. Но, говорят, по лапше работает плохо — нужен хотя бы Cat3.

                        В США Motorola уже выпустила «cloud controller» — нужны только точки и содинение с Internet (при разрыве все работает, просто теряется интерфейс управления), но когда оно доползет до СНГ — ХЗ.
                          0
                          6511 по цене вроде доступно, 6521 в продаже за минуту не нашёл. Спасибо за наводку. Хотя оверхид налицо — сеть точек не нужна, одной вполне хватает, но нужен именно гибкий файервол для клиентов (часть wifi клиентов — доверенные девайсы, должные получать «root-доступ» к сети, а часть гостевые, которым нужен интернет и, иногда, возможность коннектиться между собой, броадкастинга им не нужно даже слышать).
                    0
                    Правильно. Безнаказанность рассматривалась в сценарии «один PSK на всех» (перечитайте), и именно как следствие рекомендовалось ввести Captive Portal, которого в гостинице не было.
                    +3
                    Эта проблема так же актуальна и для проводных сетей. Кто-то (случайно, специально) может поднять второй DHCP сервер в вашей ЛВС. Вируса может и не закинут, но перебои со связью у отдельных клиентов наверняка будут (а что, если под раздачу попадет шеф?). Лечение: DHCP snooping.

                    По теме: у беспроводных контроллеров циско есть опция DHCP Address Assignment required. Она разрешает клиентский трафик только если клиент получил IP-адрес легитимно (у самого контроллера, либо через него). При получении адреса от «левого сервера» доступа просто не будет. Такая опция является рекомендованной именно для гостевых WLAN.
                      0
                      Согласен про проводные сети.
                      А что подразумевается под «доступом» — точка будет дропать пакеты (WLAN-WLAN) или только трафик LAN-WLAN? Работает ли это с FlexConnect (H-REAP)?
                      Забавно, что сама Cisco рекомендует его отключать: «The DHCP required state can cause traffic to not be forwarded properly if a client is deauthenticated or removed. To overcome this problem, ensure that the DHCP required state is always disabled.» (WLC Configuration Guide 7.2). Вот тут читал, что возникают проблемы при роуминге (если клиент не делает renew). До сих пор так?
                        +1
                        Точка будет считать клиента не до конца подключившимся (внутренний стэйт: DHCP_REQD), и никакого трафика для него пропускать не будет. Для H-REAP, на сколько я знаю, тоже.
                        Сама циска рекомендует отключать эту фичу при использовании встроенного DHCP сервера (который отстоен); пользуйте внешний сервер (на сервере либо роутере). При роуминге проблемы были со старыми версиями прошивок контроллеров и WLAN телефонов, сейчас их починили.
                      0
                      Был весной в командировке. Солидная гостиница. Халявный ваф-фай в баре, добивающий до моего второго этажа. И пароль на модем — admin. Как и имя входа…
                      Написал на бумажке
                      admin
                      admin
                      Попросил отдать местному компьютерщику, ответственному за инет.
                      За неделю так ничего и не поменялось…
                        +2
                        Ну зато радостный компьютерщик теперь точно знает логин и пасс от точки. Спасибо Вам.
                          0
                          Возможно такая связка логина и пароля используется там не только на этом модеме. Админ мог быть серьезно озадачен ;)

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое