Принятие стандарта безопасности 802.11i и постепенное распространение сетей на основе WPA-сертифицированных устройств придало многим уверенность в высокой степени защищенности их беспроводной инфраструктуры. И действительно, при продуманной и тщательной настройке безопасности WPA-защищенной сети, её взлом "в лоб" практически невозможен, если не считать взломом атаки по отказу в обслуживании (DoS) на первом и втором уровнях OSI модели. Тем не менее, расслабляться не следует. Даже если ИТ инфраструктура регулярно проверяется на предмет установки несанкционированных устройств, ключ к закрытой с помощью WPA-PSK 802.11 сети невозможно подобрать атакой по словарю, либо же применена конфигурация WPA-802.1х (WPA-Industry) с использовнием безопасных типов EAP (например, EAP-TLS или EAP-FAST) и частой сменой ключей, всё равно остается возможность успешных "латеральных" беспроводных атак. И наиболее угрожающим типом подобных "атак в обход" являются атаки против неассоциированных клиентских хостов.
Общая идея данного подхода очень проста и заключается в следующем:
1. Находим неассоциированное клиентское устройство, либо используем затопление сети фреймами деассоциации или деаутентификации для его получения.
2. Эмулируем точку доступа специфически для подсоединения этого хоста.
3. Выдаем ему IP адрес, а также IP адреса фальшивых шлюза и DNS сервера через DHCP.
4. Атакуем устройство (возможные вектора атак описаны далее во второй части статьи).
5. Если это необходимо, и удаленный доступ к устройству был успешно получен, "отпускаем" хост обратно на "родную" беспроводную сеть, предварительно запустив на нем трояна.
В 2007-ом году все выпускаемые лаптопы и ноутбуки будут иметь встроенную поддержку Wi-Fi. Та же судьба вскоре ждет большинство, если не все наладонники и смартфоны. Да и сейчас очень многие клиентские устройства (вспомним Интел Центрино) имеют такую поддержку включенной и постоянно ищущей сеть для ассоциации, часто - без ведома их владельцев. Данный факт игнорируем большинством системных администраторов организаций и компаний, и даже профессионалы в сфере ИТ безопасности подчастую ищут исключительно несанкционированные точки доступа и ад-хок сети, не уделяя достаточное внимание этим "скучным" Probe Request фреймам от "потерянных" клиентов. Казалось бы, "отлов" таких клиентских хостов атакующими до невероятности прост. Но есть ряд практических ньюансов, которые необходимо знать кракеру или пентестеру для успешного осуществления подобного рода атак. Именно рассмотрению этих ньюансов и посвящена данная статья.
Для начала нам необходимо знать, согласно какому алгоритму клиентские устройства автоматически ищут сети для подсоединения. Будут ли они ассоциироваться с любой обнаруженной 802.11 сетью с достаточно мощным сигналом ? А если таких сетей несколько ? На чем будет основан их выбор ? Kaк насчет сетей с "закрытым" ESSID и сетей, защищенных с помощью WEP или WPA ? Ответы на эти вопросы зависят как от операционной системы клиентского хоста, так и от испольуемой им беспроводной аппаратной части, её драйверов и пользовательских настроек. Здесь мы рассмотрим две самые распространенные операционные системы под которыми работает большинство подобных устройств - Майкрософт Windows и MacOS X.
"Алгоритм беспроводной самонастройки" (АБС, Wireless Auto Configuration Algorithm) в Windows XP и Windows Server 2003.
Данный алгоритм оперирует с двумя списками 802.11 сетей - Списком Доступных Сетей (СДС) и Списком Предпочитаемых Сетей (СПС). СДС представляет из себя список сетей, ответивших на широковещательные Probe Request фреймы при последнем активном скане. СПС есть список сетей, к которым было установлено полноценное соединение в прошлом. Последние сети, с которыми было ассоциировано устройство, идут в данном списке первыми. Описание сети в обоих списках содержит её ESSID, канал и метод шифрования - "открытый текст", WEP или WPA. Итак, как же используются эти списки в процессе работы АБС ?
1. Клиентское устройство составляет СДС путем посылки широковещательных Probe Request фреймов с пустым полем ESSID по одному на каждый из используемых 802.11 каналов и параллельной обработки ответов на эти фреймы.
2. Если обнаруживаются сети, находящиеся в СПС, то происходит ассоциация с такими сетями в порядке их расположения в этом списке. То есть клиентское устройство ассоциируется с самой верхней сетью СПС, которая присутствует в СДС.
3. Если таких сетей не обнаруживается, или же успешной ассоциации с ними не произошло по причине различия в 802.11 стандартах или проблем аутентификации, АБС "заходит на второй круг", посылая Probe Request фреймы специфически для поиска сетей, перечисленных в СПС. На практике это означает, что данные фреймы посылаются на каналы СПС сетей и содержат их ESSID. При этом, отсылка этих фреймов от содержания СДС абсолютно не зависит. Смысл наличия "второго круга" АБС заключается в поиске сетей с "закрытым" ESSID.
4. Предположим, что подходящих Infrastructure сетей всё равно не найдено. Следующим этапом поиска является нахождение ад-хок сетей. Для этого проводится сопоставление ад-хок сетей СДС и СПС.
5. Если в СПС имеется хотя бы одна ад-хок сеть, но в СДС она не найдена, АБС устанавливает клиентское устройство в режим ад-хок и присваивает беспроводному интерфейсу IP адрес, принадлежащий к 169.254.0.0/16 диапазону (RFC 3330). Таким образом, хост становится первым узлом потенциальной новой ад-хок сети и алгоритм заканчивает свою работу.
6. Если же ад-хок сетей в СПС нет, то АБС проверяет флаг "Подсоединиться к Непредпочитаемым Сетям" ("Connect To Nonpreferred Networks"). Если этот флаг равен единице, то клиентское устройство будет пытаться ассоциироваться с каждой сетью СДС в порядке их очередности в списке. К сожалению для атакующих, по умолчанию данный флаг равен нулю.
7. Если вышеупомянутый флаг не включен пользователем, то беспроводная карточка "запарковывается" как клиент с установленным псевдослучайным 32-хзначным ESSID. В таком состоянии она функционирует 60 секунд, после чего алгоритм поиска сетей перезапускается. Те из читателей, кто занимался вардрайвингом, не раз встречали и без труда узнают такие "странные и длинные" Probe Request ESSID значения, время от времени обнаруживаемые Кисметом или другим пассивным 802.11 сканнером.
Таким образом, установка атакующим программной точки доступа с произвольным ESSID имеет мало шансов на успех даже при большой мощности её сигнала. "Мы пойдем другим путем."(С)
Атаки против АБС в Windows XP и Windows Server 2003.
В первую очередь рассмотрим очевидные слабости данного алгоритма. В первую очередь, во время "второго раунда" АБС (пункт 3 выше), клиентское устройство фактически раскрывает содержание СПС. Представим себе ситуацию, когда такой хост находится вне досягаемости его "родной" сети. Например, корпоративный лаптоп взят сотрудником на дом или в коммандировку (и используется в аэропорту, самолете, гостинице и так далее). Для обнаружившего такой лаптоп атакующего не составит особого труда определить первую сеть в СПС по ESSID посылаемых устройством Probe Request фреймов, и установить именно это значение ESSID на своей точке доступа. То же самое относится и к поиску ад-хок сетей СПС. Если первая сеть СПС защищена и требует WEP или WPA ключ для подключения, идем далее по списку и ищем в нем открытую сеть, включая ад-хок WLANы. Вероятность нахождения такой сети достаточно велика. К примеру, большинство Wi-Fi хотспотов используют методы защиты беспроводной передачи данных на более высоких уровнях OSI модели, обычно на седьмом (можно также вспомнить и NoCat шлюз, иногда используемый в сообществах любителей Wi-Fi). Подключение к таким сетям оставит описание "незащищенной" (на 2-ом уровне) сети в СПС, которым без проблем может воспользоваться атакующий. Или, ещё один пример. Два пользователя устанавливают ад-хок соединение на несколько минут для передачи единственного файла. Вероятность того, что они будут защищать подобное соединение используя WEP или WPA-PSK достаточно низка. И действительно, кто обнаружит и успеет атаковать это соединение в течении двух - трех минут, особенно если передаваемый файл не имеет никакой конфиденциальности? Однако, в СПС обоих устройств останется описание незащищенной ад-хок сети!
Подобное описание ведет ко второй слабости. При отсутствии такой ад-хок сети поблизости (крайне вероятный сценарий, учитывая то, что ад-хок соединения обычно ставятся на короткие промежутки времени и часто - с новым ESSID каждый раз), Windows клиент установится в постоянном режиме работы как ад-хок узел, ожидающий других клиентов (пункт 5 выше). Так почему бы не стать таким клиентом, взяв себе один из RFC 3330 адресов, и не провести широковещательный пинг или послать ARP запросы (или же просто "посниффать" эфир на предмет NetBIOS пакетов) для обнаружения IP адреса жертвы и проведения дальнейших атак ? Причём, для подобного подключения не требуется никакого взаимодействия со стороны пользователя. Оно является полностью автоматическим.
Наконец, при отсутствии незащищенных и ад-хок сетей в СПС, и включенного флага "Подсоединиться к Непредпочитаемым Сетям", наш алгоритм достигнет установки клиентской карточки в "режим ожидания" с посылкой Probe Request фреймов с длинным псевдослучайным ESSID (пункт 7 выше). Проблема в том, что эти "загадочные" ESSID значения являются вполне "рабочими". То есть, достаточно установить по соседству точку доступа с таким ESSID, и клиент благополучно на нее "клюнет", чтобы получить IP адрес через DHCP и подвергнуться дальнейшим атакам. Следует сказать, что данная проблема уже устранена в Longhorn, но до тотального перехода на эту операционную систему ещё далеко. А теперь самое интересное: так как сеть с длинным псевдослучайным ESSID отсутствует в СПС, подсоединение к такой сети не только не требует никакого взаимодействия со стороны атакуемого пользователя, но даже и не будет показано как существующее индикатором беспроводной связи Windows XP. Данный индикатор будет говорить, что устройство не ассоциировано с какой-либо Wi-Fi сетью, и только контрольная панель установки сетевых опций Windows покажет наличие соединения и присвоенного IP адреса. Чтобы охладить пыл беспроводных кракеров, следует упомянуть, что последние версии драйверов 802.11a/b/g карточек с Atheros чипсетом хоть и отсылают Probe Request фреймы с псевдослучайными ESSID, но не поддерживают автоматическое соединение с точками доступа, настроенными с такими ESSID значениями.
Что же делать атакующему если, как было сейчас упомянуто, автоматическая ассоциация используя псевдослучайные ESSID невозможна, а СПС не содержит незащищенных на втором уровне сетей ? Если сети, к которым подсоединялось атакуемое устройство, защищены с помощью неподбираемого по словарю WPA-PSK либо WPA-802.1х с использованием EAP-TLS, то на данный момент перспектив успешного взлома не видно. Если по крайней мере одна такая сеть была защищена с помощью WPA-802.1х с использованием EAP-TТLS или EAP-PEAP, то существует возможность проведения атак на данные протоколы согласно алгоритмам, описанным в презентации небезызвестной хак-группы Shmoo "Тhe Radical Realm of Radius, 802.1x, and You" (вы можете загрузить эту замечательную презентацию с http://www.layerone.info/2005/presentation...f%20RADIUS.pdf). В то время как в задачу данной статьи не входит описание атак против EAP-TТLS и EAP-PEAP, предложенных в данной презентации, следует отметить, что рассматриваемый нами случай охоты (а вернее "рыбалки") на клиентские устройства идеален для проведения таких Shmoo атак, как PAP-PULL и PAP-PEEK. Почему? В первую очередь из-за того, что атакующему не мешает легитимная точка доступа и нет никакой нужды в проведении постоянных затоплений фреймами деассоциации или деаутентификации, поскольку атакуемое клиентское устройство по определению ни с чем не ассоциированно! Последний момент значительно облегчает проведение этих атак с Windows платформ. Впридачу, подобного рода атаки весьма "шумные", а в нашем случае атакуемые клиентские устройства находятся вне пределов досягаемости корпоративной системы обнаружения несанкционированного беспроводного доступа (wIDS). А везучий кракер может напороться и на клиентский хост, содержащий в СПС сеть, защищенную устаревшим EAP-MD5. Для успешного присоединения такого устройства достаточно поднять hostapd демон, приходящий с HostAP драйвером Jouni Malinen'a для карточек с Prism 2 - 3 чипсетом, при этом включив его ограниченную RADIUS-функциональность с автоматической аутентификацией суппликантов вне зависимости от присылаемых ими пакетов квитирования. Эта классическая атака против EAP-MD5 была детально описана нами в "Wi-Фу".
Говоря об устаревших механизмах защиты 802.11 сетей, невозможно не упомянуть избитый всеми WEP. И атаки на него могут быть применены и против отдельных клиентских устройств, сети в СПС которых "защищены" с помощью WEPа. Если все ад-хок сети в СПС имеют WEP в своих установках, то и произвольная ад-хок конфигурация с RFC 3330 адресом, как описано в пункте 5 выше, будет использовать WEP. Проблема в том, что такой ад-хок узел не будет "соблюдать тишину" - достаточно вспомнить хотя бы отсылку NetBIOS HELLO пакетов каждые 2 секунды. Соответственно, подобного рода трафик может быть успешно утилизирован для взлома WEP ключа различными методами, от простого перебора по словарю с помощью WepAttack до акселерации взлома путем иньекции пакетов используя Christopher Devine's aireplay (модифицированная атака ложной аутентификации либо интерактивная реиньекция пакетов, с помощью которых можно заставить одиночный ад-хок клиент послать зашифрованный ARP пакет для последующей ARP реиньекции).
Ещё более интересный пример - клиенты с псевдослучайным ESSID (пункт 7) и WEPом, которые "возникают" в тех случаях, когда все сети, перечисленные в СПС, являются защищенными. Сам факт того, что при наличии в этом списке и WPA-защищенных сетей, всё равно используется WEP - это уже уязвимость. Но, более того, так как установки подобной сети нигде не определены и "самоконфигурируются" без участия пользователя, атакующая точка доступа способна навязать таким клиентам небезопасный метод 802.11 аутентификации с использованием распределенного WEP ключа. Навязывая этот метод, кракер может послать клиентскому устройству challenge строку с известным текстом и получить обратно её же, заXORенную с частью RC4 потока. Таким образом, заXORив полученное с первоначальным текстом, атакующий узнает 144 байта RC4 потока для заданного вектора инициализации (IV). У этой атаки много возможных применений. В частности:
* можно посылать всё новые и новые challenge запросы, пока не откроется поток RC4 шифра для всех векторов инициализации 24-битного WEP IV пространства. Это громоздко и может занять значительное количество времени
* можно атаковать полученный ответ перебором по словарю испольуя WepAttack и сходные утилиты
* можно использовать известные 144 байта потока для реиньекции пакетов к клиентскому устройству с помощью старого доброго WepWedgie Антона Рэйджера. Удачная реиньекция заставит атакуемый хост послать зашифрованный ARP пакет, который легко перехватить и использовать с aireplay.
В любом из вышеперечисленных случаев, одиночное клиентское устройство требующее соединение, защищенное WEPом, трудно назвать неуязвимым.
В следующей части статьи мы обсудим атаки на клиентские Wi-Fi устройства, работающие под МacOS Х, а также имеющиеся Linux - имплементации, дальнейшие возможности и методы защиты от подобных атак.
Пришло время поставить точку над "i" и рассмотреть оставшиеся аспекты атак на клиентские 802.11 устройства. Но сначала - два небольших лирических отступления. Первое: в оригинале действительно "нормальные герои", Акелла промахнулся, но название статьи менять уже поздно smile.gif И второе: в промежутке между статьями работал я в другом городе, и попался мне под руку клиентский 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/reliawa...-g-cardbus.html http://www.demarctech.com/products/reliawa...cmcia-card.html http://www.demarctech.com/products/reliawa...i-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.11 устройства, их особенности, преимущества и недостатки. В первую очередь, хотелось бы принести извинения читателям за задержку с выходом третьей части статьи, связанную с деловыми разъездами. С другой стороны, была возможность дополнительно оттестировать описываемые программы в полевых условиях. В процессе тестирования был отловлен мелкий, но назойливый баг в Karma tools, который, соответственно, будет упомянут ниже.
Итак, начнем с требований к утилитам для атак на 802.11 клиенты. Знание этих требований полезно не только для правильного выбора и понимания работы подобных программ, но и для их совершенствования и переделки заинтересованными энтузиастами. В первую очередь, утилиты для таких атак должны проводить детальную диссекцию и сортировку Probe Request фреймов для того, чтобы узнать к каким сетям хотят подсоединиться обнаруженные клиентские устройства. Под сортировкой фреймов прежде всего подразумевается отражение утилитой последовательности расположения желаемых сетей в СПС клиента. Ответом на полученные Probe Requests должна служить генерация произвольных Probe Response фреймов, содержащих в себе значения ESSID, востребованные атакуемыми клиентами. Фактически, речь идет о преднамеренной эмуляции поведения "дефективных" точек доступа с Marvell Libertas и ADMtek ADM8638 чипсетами, упомянутыx в предыдущей части статьи при обсуждении атак перехвата соединения. Однако, Probe Request фреймы не предоставляют атакующему информацию о мерах защиты, используемых сетями в СПС. Следовательно, наша утилита также должна анализировать фреймы запроса аутентификации, отправляемые клиентскими устройствами после получения ими Probe Response фреймов от точки доступа (в нашем случае - эмулируемой атакующим для присоединения к себе клиента).
Что если клиент, посылающий Probe Request фреймы, уже ассоциирован к беспроводной сети ? Подобного рода поведение не противоречит 802.11 стандарту и может быть легко воспроизведено пользователем посредством запуска поиска доступных сетей в конфигурации беспроводного устройства под Windows или команды iwlist [interface] scanning под Линуксом будучи уже подсоединенным к сети. Мало того, некоторые клиентские устройства продолжают автоматически посылать регулярные Probe Requests и после ассоциации. Такое поведение типично для PCMCIA Cisco Aironet карточек, отправляющих Probe Requests не только в ассоциированном состоянии, но и сразу же после распознания карточки системой без предварительного поднятия беспроводного интерфейса с помощью таких команд, как ip или ifconfig. Интересно отметить, что в старых версиях Линукс ядра до 2.4.14, клиентские устройства Cisco Aironet посылали регулярные Probe Request фреймы даже в режиме мониторинга (RFMON), предоставляя тем самым уникальную возможность обнаружения атакующих, пассивно прослушивающих 802.11 сети. Помимо Cisco Aironet, отправление Probe Requests в ассоциированном состоянии было замечено за клиентскими устройствами на базе чипов Центрино, работающими под Windows, но не под Линуксом. Таким образом, наша утилита для беспроводных атак против клиентов должна быть способна к распознанию существующих ассоциаций клиент <=> 802.11 сеть. Тогда, при обнаружении ассоциации, атакующий сможет ее оборвать посредством атаки по отказу в обслуживании для последующего "перетаскивания" клиента на себя. Классическими примерами подобных DoS атак являются посылка фреймов деаутентификации, деассоциации или некорректных фреймов аутентификации а ля fata_jack.
Предположим, вы просканировали эфир на предмет ищущих ассоциации устройств и обнаружили сразу несколько подобных клиентов, "желающих" различные ESSID для присоединения. Учитывая особенности работы алгоритма поиска беспроводных сетей, это наиболее часто встречающаяся на практике ситуация. Разные клиентские устройства присоединялись к различным сетям в прошлом, какие-то из устройств образовали ад-хок узлы и какие-то - запарковались с длинным псевдослучайным значением ESSID. Можно ли "подцепить" множество подобных клиентов одновременно ? Безусловно, если создать такое же множество виртуальных точек доступа по ходу обнаружения ESSID, требуемых этими клиентами. А для тех клиентов, которые отправляют Probe Request фреймы с широковещательным ESSID (ANY), должна быть виртуальная точка доступа, предоставляющая им свой ESSID. Таким образом, атакующий может установить единовременное соединение с большим количеством уязвимых клиентов для проведения массовых сканов на порты и уязвимости, а также массового фишинга паролей.
Говоря о последнем, эффективная утилита для атак на клиентские устройства должна предоставлять разнообразные фальшивые сервисы для "пойманных" клиентов. В первую очередь, речь идет о фальшивых DHCP и DNS серверах для выдачи IP адреса жертве и перенаправления её трафика через хост хакера. Идеальным будет являться "подсаживание" всех клиентов на один диапазон IP адресов. Не лишними также будут являться такие сервисы, как веб (с фальшивой страничкой для входа, например, на mail.ru, или же размещенным на такой страничке зловредным скриптом для атаки на уязвимые браузеры), SMTP, POP3, IMAP, FTP... здесь возможности атакующего ограничены только его воображением. Разумеется, атакующая утилита должна предоставлять возможность наблюдения за пакетами, посылаемыми жертвами, и записи обнаруженных в этих пакетах паролей и другой полезной информации. Теперь же, вооружившись вышеперечисленным как базой для дальнейших экспериментов, посмотрим на то, что имеется на практике для общественного пользования.
Безусловно, все описанные в цикле статей атаки на клиентские устройства можно осуществлять и вручную, путем поимки посылаемых Probe Request фреймов и настраивания программной точки доступа с подходящим ESSID для подсоединения клиента. Для рассмотрения характеристик присутствующих в зоне приема клиентов достаточно использовать Kismet, Aircrack airodump либо же просто Ethereal/tcpdump. Если клиент успешно не ассоциируется, смотрим на фреймы запроса аутентификации в Ethereal/tcpdump и определяем, какой метод аутентификации необходим данному клиенту. Далее переходим на следующую в СПС сеть не требующую аутентификации вне открытого метода (по ESSID) либо, за неимением таковой, ломаем запрашиваемый клиентом способ аутентификации (если возможно). Потом поднимаем заранее подготовленные фальшивые DHCP, DNS и прочие сервисы и, при необходимости, включаем IP forwarding на атакующем хосте. Однако, такой подход громоздок, и явно требует автоматизации. Кроме того, он ограничен возможностью единовременной атаки только на одно клиентское устройство.
Исторически, первой утилитой, предоставляющей возможность автоконфигурации програмной точки доступа для присоединения обнаруженных клиентских устройств был Hotspotter от Макса Мозера, известного также как автора 802.11 сниффера Wellenreiter, до сих пор популярного у владельцев КПК с установленным Линуксом из-за прекрасного графического интерфейса. Принцип работы Hotspotterа очень прост - он сравнивает желаемые клиентами ESSID со списком под названием HOTSPOTLIST, в котором находятся ESSID распространенных хотспотов. Разумеется, вы можете дополнить этот список своими значениями распространенных ESSID. Если ESSID клиента найден в списке, то беспроводной интерфейс конфигурируется как точка доступа с этим ESSID значением. Hotspotter имеет флаги -е и -r для запуска команд перед и после входа интерфейса в режим точки доступа, и работает с карточками чипсетов Prism 2-2.5 (драйвер HostAP) и Connexant (драйвер Prism54g). В связи с наличием более продвинутых утилит для атак на клиентские устройства, в настоящее время Hotspotter представляет главным образом исторический интерес. Кроме того, он пока является единственной утилитой подобного рода, входящей в популярный, собранный уже упомянутым Максом Мозером, Security Auditor Линукс дистрибутив на живом CD для не имеющих под рукой эту операционную систему и не желающих её инсталлировать.
Затем группа Shmoo (спасибо им за Airsnort и RFMON заплату для Orinoco драйверов!) выпустила небезызвестный Airsnarf (http://airsnarf.shmoo.com/). Airsnarf - это всего лишь шеллскрипт, конфигурируемый посредством файла ./cfg/airsnarf.cfg и автоматизирующий запуск фальшивых сервисов для пиратской точки доступа под HostAP на Prism 2-2.5 карточках. Для его работы необходимо иметь проинсталлированные Apache, iptables, DHCP сервер, sendmail и Net::DNS Perl модуль. Соответственно, отконфигурированный и запущенный Airsnarf будет выставлять атакующую станцию как шлюз для отловленных клиентских устройств с sendmail в качестве прокси для сбора отправляемой почты и веб прокси со страничкой для фишинга паролей. Разумеется, атакующему прийдется поработать над своим HTML кодом для того, чтобы сделать эту страничку приемлемой для условий конкретной атаки. Также как и Hotspotter, Airsnarf входит в Security Auditor и, в совокупности, они уже предоставляют из себя определенную угрозу для незащищенных клиентских устройств (не забудьте про -е флаг!). Тем не менее, подобного рода комбинации не способны "отлавливать" клиенты с длинными псевдослучайными ESSID (в особенности при наличии непечатных символов в их значениях), равно как и клиенты в ад-хок режиме. Кроме того, хакер, вооруженный комбинацией Hotspotter/Airsnarf не может создавать виртуальных точек доступа для одномоментного подсоединения клиентов, требующих различные ESSID значения.
По сравнению с Hotspotter, ProbeMapper от ThinkSECURE представляет значительный шаг вперед. ProbeMapper проводит детальный анализ статуса обнаруживаемых клиентов, включая диссекцию фреймов запроса аутентификации:
Как видим, данный клиент неассоциирован и в прошлом подключался к двум сетям, одна из которых (t-mobile) - сеть распространенных коммерческих хотспотов, которая на нижних уровнях OSI ничем не защищена. Для переманивания к себе этого конкретного клиента запусакем probemapper -i eth1 -t . Probemapper спрашивает "Would you like to act as an AP for ssid t-mobile [y|N]:". Это именно то, что нам нужно, поэтому отвечаем "y". Вуаля, клиент подсоединен. Если же нам не подходит первый по списку ESSID, отвечаем N и движемся далее, покуда не найдем подходящий. К сожалению, Probemapper не запускает каких-либо фальшивых сервисов, посему атакующий должен использовать -е флаг для запуска заранее отконфигурированного аirsnarf после выхода в режим точки доступа для достижения максимального эффекта от подсоединения клиентского устройства.
В то время как Probemapper очень прост и удобен в использовании, у него есть два недостатка. Во первых, он не создает множества виртуальных точек доступа для подсоединения клиентов с разными ESSID. Во вторых, в настоящий момент Probemapper работает только под карточками с Connexant (Prism54g) чипсетом, и число таких PCMCIA устройств достаточно ограничено. Из распространенных Connexant PCMCIA карточек, мы можем назвать разве что 32-bit Cardbus Senao NL-3054CB, Netgear WG511, Zyxel G-100 и G-110, Zcom XG-300/302 и Sitecom WL-100. Гораздо более Connexant чипсет распространен среди клиентских 802.11b/g USB устройств, но у нас не было физической возможности протестировать совместимость таких клиентов с Probemapper. А вышеуказанный пример был получен используя PCMCIA карточку Senao NL-3054CB.
Но не стоит переживать! Karma tools не только работают под наиболее распространенным и весьма удобным для атакующего Atheros чипсетом, но и наиболее близки к удовлетворению перечисленных в начале статьи критериев для утилит, предназначенных для атак на 802.11 клиенты. В настоящий момент Karma tools работают под madwifi, но не более новыми madwifi-ng драйверами. Для создания виртуальных точек доступа на каждый обнаруженный "бесхозный" клиент, драйвера надо пропатчить, для чего лучше использовать использованную создателями программы версию madwifi:
arhontus# svn checkout -r '{20060124}' http://svn.madwifi.org/branches/madwifi-old madwifi
arhontus# patch -p0 < madwifi-KARMA-20060124.diff
arhontus# cd madwifi && make && make install
Базовая конфигурация Karma tools осуществляется при помощи файла еtc/karma.xml, по умолчанию содержащего следующее:
Атакующий скорее всего изменит ESSID с кarma на нечто менее подозрительное. По перечисленным модулям видно, какие фальшивые сервисы автоматически запускает Karma tools. EXAMPLE-WEB-EXPLOIT - это всего лишь пустая веб-страничка, которая может быть заменена страничкой с логином для фишинга или страничкой со зловредным скриптом для атаки на клиентские браузеры. Безусловно, вы всегда можете захашить ненужный модуль, или же использовать заплату для Samba сервера (samba.patch) чтобы создать фальшивый совместно используемый ресурс на своем хосте, на который будут автоматически направляться жертвы. Сгенерируем же немного негативной кармы:
1. ставим интерфейс в RFMON: bin/monitor-mode.sh ath0
2. запускаем бинарник в src для нахождения клиентских устройств: src/karma ath0 (честно говоря, в этом плане нам гораздо больше нравится airodump ath0 дающий более четкое описание найденных клиентов, равно как и сетей)
3. убедившись, что место рыбное, запускаем и саму атакующую утилиту из bin: bin/karma etc/karma.xml. В идеале должно произойти примерно следующее:
Starting KARMA...
Loading config file etc/karma.xml
ACCESS-POINT is running
DNS-SERVER is running
DHCP-SERVER is running
AccessPoint: 00:04:e2:80:8c:ca associated with SSID arhont-test
POP3-SERVER is running
FTP-SERVER is running
[2006-03-29 21:25:37] INFO WEBrick 1.3.1
[2006-03-29 21:25:37] INFO ruby 1.8.4 (2005-12-24) [i686-linux]
[2006-03-29 21:25:37] INFO WEBrick::HTTPServer#start: pid=26149 port=80
HTTP-SERVER is running
CONTROLLER-SERVLET is running
EXAMPLE-WEB-EXPLOIT is running
Delivering judicious KARMA, hit Control-C to quit.
DNS: 169.254.0.254.32776: 9720 IN::A www.google.com
DNS: 169.254.0.254.32776: 64608 IN::PTR 7.133.254.169.in-addr.arpa
DNS: 169.254.0.254.32776: 3513 IN::AAAA www.arhont.com
DNS: 169.254.0.254.32776: 6277 IN::AAAA www.arhont.com.dmz.arhont.com
DNS: 169.254.0.254.32776: 58987 IN::AAAA www.arhont.com.arhont.com
DNS: 169.254.0.254.32776: 48417 IN::A www.arhont.com
169.254.0.254 - - [29/Mar/2006:21:27:07 BST] "GET /example HTTP/1.0"
301 48 - -> /example
DNS: 169.254.0.254.32776: 18218 IN::AAAA www.arhont.com
DNS: 169.254.0.254.32776: 26478 IN::AAAA www.arhont.com.dmz.arhont.com
DNS: 169.254.0.254.32776: 27220 IN::AAAA www.arhont.com.arhont.com
DNS: 169.254.0.254.32776: 14906 IN::A www.arhont.com
169.254.0.254 - - [29/Mar/2006:21:28:01 BST] "GET / HTTP/1.0" 301 30
FTP: 169.254.0.254 test/password
AccessPoint: 00:04:e2:80:9а:23 associated with SSID t-mobile
AccessPoint: 00:04:e2:74:22:c5 associated with SSID аll your base
В консоли, в которой была запущена утилита, мы видим MAC адреса пойманных клиентов (e.g. "AccessPoint: 00:04:e2:74:22:c5 associated with SSID аll your base"), их запросы на Google и наш вебсайт (не удивляйтесь - это не популярность, а тестовая лаборатория :-) перенаправляемые на вебсервер атакующего, а также зафиксированный логин на FTP (test/password). Kaк видите, клиенты с запущенным dhcpcd автоматически получают IP адреса из RFC 3033 диапазона, и атакующий интерфейс (по умолчанию IP 169.254.133.7) в качестве шлюза.
Однако на практике всё может быть не так гладко. Karma tools пока ещё достаточно "сырые", и не удивляйтесь, если при запуске утилиты вы получите ошибки типа "Broken pipe" или "undefined method" - просто перезапустите кarma несколько раз, пока всё не заработает без подобного рода ошибок. Но есть упомянутый в самом начале статьи баг, от которого не избавиться перезапуском. Дело в том, что Karma tools писались и тестировались на b/g, а не a/b/g карточках, в то время как многие из вас безусловно обладают клиентскими устройствами, поддерживающими все 3 стандарта. Так вот, на подобных устройствах при запуске Karma tools выдается следующая ошибка:
ACCESS-POINT is running
Error for wireless request "Set Frequency" (8B04) :
SET failed on device ath0 ; Invalid argument.
Она свидетельствует о том, что ваша точка доступа встала на 802.11а частоту (при этом все фальшивые сервисы могу быть вполне благополучно запущены и утилита ожидает жертв). И действительно,
Стандартные команды iwconfig freq и iwconfig channel здесь не помогут, взамен используйте iwpriv mode 2. Убедитесь в том, что точка доступа вернулась на 802.11b/g частоту:
Затем установите максимальные мощность и чувствительность с помощью iwconfig txpower ХХХmW и iwconfig sens Х/Х (обычно 3/3) и перезапускайте bin/karma etc/karma.xml пока утилита не запустится без ошибок. Убедитесь, что все нужные фальшивые сервисы запущены:
Следует сказать, что Karma tools можно использовать и под HostAP драйверами на карточках с Prism 2-2.5 чипсетом (не забудьте сменить ath0 на wlan0 в karma.xml). Но тогда функциональность утилиты будет неполной в связи с невозможностью создавать виртуальные точки доступа на таких карточках и подключать клиенты с разными ESSID одновременно. Дело в том, что более старые 16-ти битные клиентские устройства обрабатывают Probe Request фреймы в прошивке устройства, а не на уровне его драйверов. И мы не можем заставить их параллельно использовать множественные значения ESSID из получаемых Probe Request фреймов так, как мы делаем это на более современных Atheros чипсет карточках при помощи madwifi.patch. Таким образом, использование Prism 2-2.5 устройств и HostAP для запуска Karma tools не рекоммендуется.
И ещё несколько наблюдений. Скидывать клиентские устройства с сети, к которой они подсоединены, на хост с запущенными Karma tools вполне возможно. Для этого, так как мы проводим тестирование на Atheros карточке, легко использовать затопление канала, на котором сидит подключенный клиент, фреймами деаутентификации с помощью запущенного в соседней консоли aireplay из Aircrack (aireplay -a -c -0 <количество фреймов деаутентификации> ath0). Также, с помощью Karma tools нам без проблем удалось "сбить" WEP с Интел Центрино клиента (см. предыдущую часть статьи по поводу атаки "сброс WEPа при коммуникации с клиентом"). К сожалению, Karma tools не поддерживают "отлов" клиентов в режиме ад-хок, но это не беда. Включение iwconfig ath0 mode ad-hoc параллельно с aireplay -0 по атакуемому Orinoco чипсет клиенту из соседней консоли сделали свое темное дело, сбросив клиента с легитимной сети и присоединив его к атакующему хосту. Таким образом, все описываемые в предыдущих частях статьи атаки вполне осуществимы на практике.
В заключении, несколько комментариев и рекоммендаций по защите беспроводных клиентов от атак подобного рода. Технически клиент вне опасности, если с помощью утилиты конфигурации беспроводного устройства удалены все незащищенные профили СПС и оставлены только сети, подсоединение к которым идет под защитой WPA, желательно WPA Industry с использованием 802.1х и двусторонней аутентификации (EAP-TLS), причем клиентский сертификат должен быть защищен сильным паролем. Также нелишними являются установка персональных брандмауэров на клиентские устройства и приличного беспроводного IDS в зоне покрытия корпоративной / организационной сети для обнаружения ад-хок соединений и несанкционированных точек доступа, сманивающих на себя клиентов и скидывающих их с легитимной сети с помощью DoS атак. А ещё не забудьте по возможности использовать последние модели клиентских устройств (32-bit Cardbus, чипсеты с программной, а не прошивочной имплементацией MAC уровня) и последние версии драйверов для этих устройств. Увы, все подобные меры противодействия упираются в значительные проблемы административно-организационного плана, по крайней мере если речь идет об обычных пользователях и достаточно крупной компании / организации. Для системного администратора достаточно сложно проследить, чтобы СПС всех клиентских хостов под его опекой не содержали незащищенных сетей. Особенно, если эти хосты используются сотрудниками вне его домэйна ответственности - дома, в кафе, гостиницах, аэропортах... Таким образом, во многих случаях, несмотря на старания системного администратора, всё равно остается лазейка для беспроводной крысы, предпочитающей клиентские устройства на завтрак.
