"Отважные герои всегда идут в обход": атакуем клиентские устройства на Wi-Fi сетях. Часть 2.

"Отважные герои всегда идут в обход": атакуем клиентские устройства на Wi-Fi сетях. Часть 2.

Пришло время поставить точку над "i" и рассмотреть оставшиеся аспекты атак на клиентские 802.11 устройства. Первое: в оригинале действительно "нормальные герои", Акелла промахнулся, но название статьи менять уже поздно :) И второе: в промежутке между статьями работал я в другом городе, и попался мне под руку клиентский Acer'овский лаптоп под Windows XP Professional SP2, который надо было настроить и подчистить от разного spyware. Поглядел я на настройки его встроенной miniPCI 802.11 карточки и ужаснулся: было выставлен флаг "Подсоединиться к Непредпочитаемым Сетям", и дополнительно добавлено "Подсоединиться к Сети с Наибольшей Силой Сигнала".

Андрей Владимиров (andrew arhont.com), соавтор книг  Wi-фу: "боевые" приемы взлома и защиты беспроводных сетей и Hacking Exposed Cisco Networks (Hacking Exposed)

Пришло время поставить точку над "i" и рассмотреть оставшиеся аспекты атак на клиентские 802.11 устройства. Но сначала - два небольших лирических отступления. Первое: в оригинале действительно "нормальные герои", Акелла промахнулся, но название статьи менять уже поздно :) И второе: в промежутке между статьями работал я в другом городе, и попался мне под руку клиентский Acer'овский лаптоп под Windows XP Professional SP2, который надо было настроить и подчистить от разного spyware. Поглядел я на настройки его встроенной miniPCI 802.11 карточки и ужаснулся: было выставлен флаг "Подсоединиться к Непредпочитаемым Сетям", и дополнительно добавлено "Подсоединиться к Сети с Наибольшей Силой Сигнала". При этом владелица лаптопа, работающая в отделе по продажам, даже и не подозревала о наличии встроенной беспроводной карточки и клялась, что в данные настройки не лазила и ничего там не меняла (чему я охотно верю). Wi-Fi сети не используются ни в офисе, ни дома у данной сотрудницы. Кто мог поменять настройки по умолчанию для Wi-Fi карточки упомянутого лаптопа - неизвестно (возможно, продавшая его компания), да и не суть важно. Важно то, что подобные случаи и устройства - существуют. И большинство консультантов по безопасности, не говоря уже о системных администраторах, скорее всего проглядели бы эту очень серьезную проблему конфигурации, которую не обнаружит ни один существующий на данный момент сканер проверки уязвимостей и уровня "запатченности".

    Вернемся же к описанию алгоритмов выбора точки доступа неассоциированными клиентскими устройствами. Как было справедливо замечено в комментариях к первой части статьи, Линукс - клиенты весьма неразборчивы в соединениях с точками доступа и в большинстве случаев готовы ассоциироваться с любой близлежащей точкой с максимальной силой сигнала. При этом, как было замечено нами еще года три назад, даже со старыми Hermes II чипсет карточками нет никакой необходимости прописывать номер канала с помощью команды iwconfig. С ESSID несколько сложнее, и многое зависит от установок файлов конфигурации беспроводного клиента. В некоторых случаях, при подьеме 802.11 интерфейса с помощью команды iwconfig [interface] up, ESSID оптимальной точки доступа будет приниматься автоматически, но расчитывать на это атакующему в целом не стоит. Более рационально прослушать эфир на предмет посылаемых Probe Request фреймов и принять ESSID, указанное в них. Probe Request фреймы отправляются всеми клиентскими устройствами под Линукс, к примеру Cisco Aironet карточки посылали их даже в режиме мониторинга (RFMON) под старыми ядрами до 2.4.14 версии. Данный баг в настоящее время устранен. Запущенная пользователем или автоматической утилитой (например, APhunter или APradar) команда iwlist [interface] scanning под Линукс форсирует посылку Probe Requests. В то время как "сассоциировать" клиентское устройство под Линукс несложно, на более высоких уровнях OSI модели атакующего могут ждать сюрпризы. А именно, конфигурация беспроводного интерфейса под Линукс глубоко индивидуальна и зависит от дистрибутива системы, его версии и настройки опций файлов конфигурации интерфейса пользователем. В отличие от Windows, наличие DHCP клиента на таком интерфейсе маловероятно, и даже статический IP адрес может быть неустановлен в расчете на его прописывание пользователем при подключении к беспроводной сети используя команду iwconfig. Безусловно, можно нарваться на устройство, на котором пользователем запущена какая-нибудь утилита для автоматического нахождения и подключения к Wi-Fi сетям, скажем APHopper . Однако вероятность такого случая мягко скажем невелика. Если на беспроводном интерфейсе прописан статический IP адрес, атакующий может использовать перебор адресов с помощью ARP запросов для его нахождения, используя Ettercap, THC-wardrive и прочие подобные утилиты. Разумеется, 192.168.0.0./16 - хороший выбор диапазона адресов для начального перебора. Следует также принимать во внимание, что беспроводное устройство под Линуксом может быть изначально настроено не как клиент, а как точка доступа, к примеру при использовании драйверов HostAP (ESSID по умолчанию - "test"), madwifi или Prism54g. Данные случаи только упрощают задачу атакующего, так как ему не требуется обладать возможностями точки доступа на устройстве, которое он пытается подсоединить.

    Несмотря на непрерывное распространение Линукса как операционной системы мобильных устройств, второй по частоте встречаемости после Windows операционкой беспроводных клиентов всё же является MacOS X. Рассмотрим же, как ведут себя эти клиенты в неассоциированном состоянии, и чем их поведение отличается от поведения устройств под Майкрософт Windows, рассмотренного в первой части статьи.

Алгоритм выбора беспроводных сетей в MacOS X и атаки против него

    Несмотря на непрерывное распространение Линукса как операционной системы мобильных устройств, второй по частоте встречаемости после Windows операционкой беспроводных клиентов всё же является MacOS X. Рассмотрим же, как ведут себя эти клиенты в неассоциированном состоянии, и чем их поведение отличается от поведения устройств под Майкрософт Windows, рассмотренного в первой части статьи. Для начала нам необходимо знать, где хранится список предпочитаемых Wi-Fi сетей под MacOS X. Данный список представляет собой XML файл, обычно /localhost/System/Library/DTDs/PropertyList.dtd. До версии MacOS X 10.3.3, списка предпочитаемых/доверяемых сетей не существовало, однако после открытия в 2003-ем году серьезной клиентской уязвимости,  данный список был создан для её устранения. Сама по себе, эта уязвимость достаточно знаменательна и сводится к тому, что подсоединившийся к точке доступа атакующего MacOS X клиент принимает через DHCP не только IP адреса себя, шлюза и DNS сервера, но и параметры полностью доверяемого фальшивого LDAP или NetInfo сервера, после чего становится возможным залогиниться на атакуемое устройство с uid 0 и любым именем пользователя. Следует отметить, что конфигурация беспроводных MacOS X хостов позволяет больший выбор опций по сравнению с Windows, а именно "всегда ассоциироваться с указанной сетью", "соединяться с последней ассоциированной сетью" и "соединяться с незащищенной сетью с наиболее сильным сигналом". Несмотря на кажущуюся относительную безопасность первых двух опций, они легко обходятся атакующим.

    Итак, как же работает сам алгоритм выбора? В отличии от Windows, он задействуется не каждые 60 секунд, а только когда логинится пользователь или "просыпается" клиентский хост. Поиск начинается с посылки Probe Request фрейма с ESSID последней ассоциированной сети и идет далее вниз по списку доверяемых сетей. Если ни одной из доверямых/предпочитаемых сетей не найдено, то перед пользователем автоматически открывается диалог, сообщающий об этом и предлагающий подсоединиться к сети с максимальной силой сигнала, опционально запоминая эту сетку как предпочитаемую. Если пользователь отказывается, то клиентские устройства AirPort, но не более новые AirPort Ехtreme, "запарковываются" сo статическим или динамическим псевдослучайным значением ESSID и установленным WEPом. AirPort Ехtreme карточки не генерируют никакого 802.11 трафика, если скан на наличие доступных сетей не запрошен пользователем. Выбор между статическим и динамическим ESSID у AirPort зависит от того, чем был вызван изначальный скан на наличие предпочитаемых сетей. Если скан происходит после загрузки или "просыпания" устройства - значение ESSID статическое (ака "dummy"). Если скан инициирован логином пользователя - значение ESSID динамическое.

    Слабости данного алгоритма очевидны. Во первых, также как и алгоритм беспроводной самонастройки Windows, Probe Request фреймы выдают список доверяемых сетей, каждая из которых может быть легко эмулирована атакующим. Во вторых, атакующий может принять значение ESSID "запаркованной" AirPort карточки и ассоциировать клиента к себе. Устанавливаемый автоматически WEP такой карточки не создает никаких проблем для беспроводных кракеров, так как всегда используется аппаратно прошитое 40-битное значение WEP ключа, равное 0x0102030405. Интересно, что даже при использовании (а вернее навязывании атакующим) аутентификации по общему WEP ключу (Shared Key Authentication), соединение с клиентом происходит без каких-либо препятствий и уведомления об этом пользователя. Тем не менее, индикатор меню AirPort всё-таки загорается, и при щелчке на него мышью показывает соединение с 802.11 сетью. Кроме того, так как сканирование не происходит через регулярные интервалы, для эмуляции сетей из заветного XML списка атакующий должен поймать удачный момент времени. Таким образом, атаковать MacOS X клиенты сложнее, чем их "беспроводных собратьев" под Windows. Тем не менее, подобные успешные атаки весьма и весьма возможны, особенно в случае использования старых 802.11b AirPort устройств.

Атаки против специфических уязвимостей клиентских 802.11 устройств.

Пришло время перейти от атак на общие алгоритмы поиска сетей для ассоциации к атакам на отдельно взятые имплементации данных алгоритмов, а вернее - их баги. Для начала мы рассмотрим так называемый "перехват ассоциации". Речь идет о том, что "прошивка" (firmware) ряда точек доступа и клиенстких карточек имеет логическую ошибку в дизайне, ведущую к предпочтительной ассоциации "дефективной" карточки с "дефективной" точкой доступа вне зависимости от выставленных на клиентской карточке значений ESSID и 802.11 канала. Сама ошибка сводится к некорректно выставленному значению единственного регистра в прошивке для беспроводных чипсетов Marvell Libertas и ADMtek ADM8638 для точек доступа, а также Hermes I/II, равно как и Prism 2/2.5 чипсетов для клиентских карточек. В результате получается следующая "летальная комбинация":

- "перехватывающая" точка доступа посылает Probe Response фреймы в ответ на любые Probe Requests от клиентов, даже если они (Probe Requests) не содержат широковещательное (ANY) или установленное на точке доступа значение ESSID. Такое поведение точки доступа ненормально.

- ассоциация уязвимого клиентского устройства инициируется первым полученным Probe Response фреймом от любой точки доступа, вне зависимости от соответствия значений ESSID в изначально посланном устройством Probe Request'е и полученном в ответ Probe Response. Такое поведение клиентской карточки ещё более абнормально и, очевидно, объясняется тем, что клиентское устройство смотрит только на MAC адрес хоста назначения в получаемом Probe Response фрейме и, удостоверившись в том, что это его MAC, начинает ассоциацию. Поле ESSID в Probe Response при этом не проверяется.

Таким образом, используя описанную уязвимость, атакующий может ассоциировать хосты к своей точке доступа даже в присутствии легитимной беспроводной сети (не забывайте про DoS через затопление фреймами деассоциации/деаутентикации!). Достаточно, чтобы первый полученный уязвимым клиентским устройством Probe Responsе фрейм был послан именно атакующим. Высокую вероятность этого можно достичь с помощью большей мощности сигнала точки доступа кракера по сравнению с точкой доступа атакуемой сети. Добиться этого несложно: в то время, как легально установленные точки доступа ограничены по мощности выходящего сигнала законодательными регуляциями (100 мВ для сетей топологии "точка-многоточка" в России), кракер ограничен только мощностью своего "железа", так как всё равно нарушает закон. Здесь можно вспомнить и дешевые в изготовлении самодельные "кантенны" с большим коэффициентом усиления выходящего сигнала (даже и не говоря о промышленных антеннах и усилителях в продаже), и коммерчески доступные беспроводные карточки значительной мощности, работающие под HostAP или madwifi Линукс драйверами. Примерами последних могут являться reliawave карточки, предлагаемые Демарктехом, скажем
http://www.demarctech.com/products/reliawave-rwu/reliawave-rwu-300mw-atheros-802.11a-b-g-cardbus.html
http://www.demarctech.com/products/reliawave-rwz/reliawave-rwz-300mw-prism2-5-pcmcia-card.html
http://www.demarctech.com/products/reliawave-rwu/reliawave-rwu-400mw-atheros-802.11g-mini-pci-card.html
Разумеется, для использования уязвимости "перехвата ассоциации", атакующему нет нужды обладать одной из "дефективных" точек доступа - достаточно всего лишь быть способным посылать Probe Response фреймы с MAC адресом уязвимого клиентского устройства (ESSID не имеет значения!). Далее в статье будут рассмотрены утилиты, позволяющие это делать без особого труда. Что же касается "дефективных" устройств, к таковым относятся например "Netgear WGR614 v4 wireless router", точка доступа "Linksys WAP11 v2.8", некоторые точки доступа производства D-Link и многие клиентские карточки с Hermes I/II и Prism 2/2.5 чипсетами и старыми, необновленными версиями прошивки. Говоря же об атаках на неассоциированные клиентские устройства в отсутствии легитимных сетей, вышеописанная уязвимость устраняет необходимость эмуляции сетей из списка доверяемых - любой ESSID на любом канале сделает свое темное дело, и не надо дожидаться посылки клиентом Probe Request фреймов и смотреть на их содержание.

Безусловно, этой уязвимости "перехвата ассоциации" уже два года, и многие из тогда уязвимых устройств сейчас работают под обновленной прошивкой. Тем не менее, её не стоит сбрасывать со счетов. Во первых, как часто пользователи меняют прошивку беспроводных карточек? "Если работает, зачем обновлять?"(С) Это не операционная система и не видимое для пользователя популярное сетевое приложение или сервис. Во вторых, не все обязательно пользуются 802.11g стандартом и клиентскими устройствами с более новыми чипсетами, такими как Atheros, Realtek и Рrism54g. Да и Hermes I/II и Prism 2/2.5 карточки в связи с новыми стандартами и чипсетами сейчас значительно подешевели и более доступны. Популярна ли до сих пор Lucent ORiNOCO Silver PCMCIA карточка ? Да. Уязвима ? Аналогично. В третьих, само наличие данной уязвимости даже и не рассматривалось как проблема безопасности. Она была обнаружена как сбой на 802.11 сетях работниками беспроводного провайдера, и именно в этом качестве доложена на ISP-Wireless и broadbandreports.com форумы, но не на Bugtraq, Packetstorm, в CERT и так далее. Таким образом, сообществу специалистов по сетевой безопасности данная проблема весьма малоизвестна. Но есть и другая подобная, и ещё менее известная дыра.

Данные о ней были опубликованы только на Sourceforge orinoco-devel форуме ещё в 2003-ем году, тем не менее они не получили огласки, не были восприняты как уязвимость, и для многих Ориноко карточек (Hermes I/II чипсет) "воз и ныне там". А использовать этот вариант "перехвата ассоциации" предельно просто. Если атакующий поднимает ад-хок сеть с таким же ESSID как и у легитимной точки доступа, клиентские устройства предпочитают ассоциироваться не с этой точкой доступа, а с хостом атакующего. Впервые эта уязвимость была обнаружена как раз на небезызвестной Lucent ORiNOCO Silver карточке (версия прошивки 8.72) под Линуксом (драйвер orinoco_cs 0.13b). Однако, так как та же самая проблема существует с подобными клиентскими карточками и под Windows, логично было бы предположить что её источником, как и в предыдущем случае, является ошибка производителя в установках прошивки устройства. Интересно, что последующая попытка заставить клиентскую карточку присоединиться именно к точке доступа (iwconfig eth1 mode managed) не вела к полноценному соединиению, то есть помимо "перехвата ассоциации" имеется ещё и потенциальная атака по отказу в обслуживании. Так как данную проблему никто детально не изучал, не исключено, что есть и другие типы клиентских 802.11 устройств, уязвимых к данной элементарной атаке. Мало того, учитывая общие корни происхождения 802.11 чипсетов Hermes I/II, Prism 2-2.5, Symbol и Cisco Aironet, это было бы весьма неудивительным и требует скорейшего тестирования.

Вы можете конечно сказать, что всё вышесказанное имеет отношение только к устаревшим устройствам и старым версиям их прошивки. Давайте же посмотрим на набирающее огромную популярность современное клиентское устройство, а именно - Intel Centrino. Вернее - Intel Pro Wireless 2200B/G чипсет и его прошивку. Начнем с того, что вместо выставления описанных в прошлой части статьи длинных псевдослучайных значений ESSID, Intel Centrino использует свое краткое значение по умолчанию, a именно "WXYZ" (также "Sony 802.11 Default SSID" для Sony Intel Centrino). Centrino в данном случае не одинок, к примеру Netgear WG511 выставляет ESSID "Netgear". Это безусловно облегчает задачу атакующего, но само по себе не наврядли является уязвимостью в полном смысле этого слова. А реальная уязвимость была опубликована на Bugtraq в прошлом месяце и заключается в том, что при выставленном на клиентском устройстве WEPe, кракер может заставить уязвимый хост соединиться с атакующей точкой доступа без испольсования WEP. Делается это следующим образом:
  1. Устанавливается фальшивая точка доступа без WEPа с ESSID, посылаемом в Probe Request фреймах Intel Centrino устройства.
  2. После получения Probe Response фрейма, указывающего, что WEP не используется, уязвимое устройство тем не менее продолжает процесс аутентификации.
  3. Несмотря на то, что клиентское устройство по прежнему требует использовать WEP в посылаемых фреймах запроса аутентикации и ассоциации, точка доступа атакующего "заставляет" клиента "отказаться" от использования WEP просто посылая ему фреймы ответа аутентикации и ассоциации, говорящие о том, что WEP точкой доступа не используется.
Вуаля, атакуемое устройство игнорирует прописанный на нем WEP и соединение с точкой доступа атакующего благополучно установлено. Данная уязвимость получила название "WEP-Client-Communication-Dumbdown", что можно литературно перевести как "сброс WEPа при коммуникации с клиентом". В третьей и последней части статьи мы рассмотрим утилиты для проведения описанных в статье атак а также методы защиты ваших клиентских устройств от подобных нападений. 
 

Курс Защита беспроводных сетей читается ведущими экспертами в области беспроводного нападения и защиты, и охватывает последние разработки в области безопасности стандартов 802.11a/b/g, включая новые беспроводные протоколы и стандарты безопасности, а также продвинутые методы нападения и взлома беспроводных сетей, используемые как профессиональными аудиторами по безопасности, так и хакерами. Oбьясняются нестандартные методики защиты беспроводных локальных сетей и методы физического нахождения нападающего. Курс также обеспечивает интенсивное введение в работу с 802.11 сетями и охватывает аспекты управления беспроводной защиты, такие как разработку беспроводной политики безопасности.

Тени в интернете всегда следят за вами

Станьте невидимкой – подключайтесь к нашему каналу.