"Отважные герои всегда идут в обход": атакуем клиентские устройства на Wi-Fi сетях. Часть 3.
В заключительной части данной статьи мы рассмотрим имеющиеся утилиты для атак на клиентские 802.11 устройства, их особенности, преимущества и недостатки
Андрей Владимиров (andrew arhont.com), соавтор книг Wi-фу: "боевые" приемы взлома и защиты беспроводных сетей и Hacking Exposed Cisco Networks (Hacking Exposed)
В заключительной части данной статьи мы рассмотрим имеющиеся утилиты для атак на клиентские 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 проводит детальный анализ статуса обнаруживаемых клиентов, включая диссекцию фреймов запроса аутентификации:
arhontus # probemapper -i eth1 -sКак видим, данный клиент неассоциирован и в прошлом подключался к двум сетям, одна из которых (t-mobile) - сеть распространенных коммерческих хотспотов, которая на нижних уровнях OSI ничем не защищена. Для переманивания к себе этого конкретного клиента запусакем probemapper -i eth1 -t
------------------------------------------------------------------------------
ProbeMapper at your service ./probemapper v0.5
(c) 2005 Christopher Low / c.low[-at-]securitystartshere.net
-------------------------------------------------------------------------------
Client MAC Associated ESSID Enc Auth Pkts Rate(pkts/min)
00:04:e2:80:8c:ca N t-mobile unknown unknown 45 38.97
wireless WEP unknown 58 35.24
В то время как 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, по умолчанию содержащего следующее:
<!-- Configure modules -->Атакующий скорее всего изменит ESSID с кarma на нечто менее подозрительное. По перечисленным модулям видно, какие фальшивые сервисы автоматически запускает Karma tools. EXAMPLE-WEB-EXPLOIT - это всего лишь пустая веб-страничка, которая может быть заменена страничкой с логином для фишинга или страничкой со зловредным скриптом для атаки на клиентские браузеры. Безусловно, вы всегда можете захашить ненужный модуль, или же использовать заплату для Samba сервера (samba.patch) чтобы создать фальшивый совместно используемый ресурс на своем хосте, на который будут автоматически направляться жертвы. Сгенерируем же немного негативной кармы:
<option module="ACCESS-POINT" name="ssid" value="karma"/>
<option module="ACCESS-POINT" name="interface" value="ath0"/>
<!-- Run modules -->
<run module="ACCESS-POINT"/>
<run module="DHCP-SERVER"/>
<run module="POP3-SERVER"/>
<run module="FTP-SERVER"/>
<run module="CONTROLLER-SERVLET"/>
<run module="EXAMPLE-WEB-EXPLOIT"/>
- ставим интерфейс в RFMON: bin/monitor-mode.sh ath0
- запускаем бинарник в src для нахождения клиентских устройств: src/karma ath0 (честно говоря, в этом плане нам гораздо больше нравится airodump ath0 дающий более четкое описание найденных клиентов, равно как и сетей)
- убедившись, что место рыбное, запускаем и саму атакующую утилиту из 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а частоту (при этом все фальшивые сервисы могу быть вполне благополучно запущены и утилита ожидает жертв). И действительно,
arhontus# iwconfig ath0
ath0 IEEE 802.11a ESSID:"karma" Nickname:""
Mode:Master Frequency:5.18 GHz Access Point: 00:07:CD:64:E7:AE
Bit Rate:0 kb/s Tx-Power:18 dBm Sensitivity=0/3
Стандартные команды iwconfig
arhontus# iwconfig ath0
ath0 IEEE 802.11b ESSID:"karma" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:07:CD:64:E7:AE
Затем установите максимальные мощность и чувствительность с помощью iwconfig
arhontus# netstat -plan | grep ruby
tcp 0 0 169.254.133.7:110 0.0.0.0:* LISTEN 20640/ruby
tcp 0 0 169.254.133.7:80 0.0.0.0:* LISTEN 20640/ruby
tcp 0 0 169.254.133.7:21 0.0.0.0:* LISTEN 20640/ruby
udp 0 0 169.254.133.7:53 0.0.0.0:* 20640/ruby
Удачной рыбалки!
Следует сказать, что 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
В заключении, несколько комментариев и рекоммендаций по защите беспроводных
клиентов от атак подобного рода. Технически клиент вне опасности, если с помощью
утилиты конфигурации беспроводного устройства удалены все незащищенные профили
СПС и оставлены только сети, подсоединение к которым идет под защитой WPA,
желательно WPA Industry с использованием 802.1х и двусторонней аутентификации (EAP-TLS),
причем клиентский сертификат должен быть защищен сильным паролем. Также
нелишними являются установка персональных брандмауэров на клиентские устройства
и приличного беспроводного IDS в зоне покрытия корпоративной / организационной
сети для обнаружения ад-хок соединений и несанкционированных точек доступа,
сманивающих на себя клиентов и скидывающих их с легитимной сети с помощью DoS
атак. А ещё не забудьте по возможности использовать последние модели клиентских
устройств (32-bit Cardbus, чипсеты с программной, а не прошивочной
имплементацией MAC уровня) и последние версии драйверов для этих устройств. Увы,
все подобные меры противодействия упираются в значительные проблемы
административно-организационного плана, по крайней мере если речь идет об
обычных пользователях и достаточно крупной компании / организации. Для
системного администратора достаточно сложно проследить, чтобы СПС всех
клиентских хостов под его опекой не содержали незащищенных сетей. Особенно, если
эти хосты используются сотрудниками вне его домэйна ответственности - дома, в
кафе, гостиницах, аэропортах... Таким образом, во многих случаях, несмотря на
старания системного администратора, всё равно остается лазейка для беспроводной
крысы, предпочитающей клиентские устройства на завтрак.
Курс Защита беспроводных сетей читается ведущими экспертами в области беспроводного нападения и защиты, и охватывает последние разработки в области безопасности стандартов 802.11a/b/g, включая новые беспроводные протоколы и стандарты безопасности, а также продвинутые методы нападения и взлома беспроводных сетей, используемые как профессиональными аудиторами по безопасности, так и хакерами. Oбьясняются нестандартные методики защиты беспроводных локальных сетей и методы физического нахождения нападающего. Курс также обеспечивает интенсивное введение в работу с 802.11 сетями и охватывает аспекты управления беспроводной защиты, такие как разработку беспроводной политики безопасности.
Ищем уязвимости в системе и новых подписчиков!
Первое — находим постоянно, второе — ждем вас