Стандарт WiFi 802.11n использует механизм агрегации кадров для уменьшения накладных расходов при передаче данных.
Для этого несколько кадров объединяются в один. При этом маркер разделителя кадров передается вместе с данными.
Это позволяет сформировать данные, которые при прохождении через WiFi устройство будут интерпретированы им как отдельные кадры.
То есть имея контроль над потоком данных передаваемых от сервера клиенту (например при загрузке файла с сервера атакующего) или от клиента к серверу, можно генерировать произвольные пакеты на всех уровнях OSI:
- Пакет с любыми заголовками RadioTap: Beacon, Probe Request/Respone, Deauthentication
- L2 уровень: указать любой MAC адрес в заголовках пакета, можно производить ARP спуфинг
- L3/L4 уровень: скрафтить любой TCP/UDP/ICMP пакет с любыми заголовками IP
- и так далее
Уязвимости подвержены только открытые сети стандарта 802.11n.
Схема PHY кадра с инъекцией
Как видно разделитель кадра (A-MPDY delimiter) помещается прямо в payload с пользовательскими данными, поэтому при получении такого кадра принимающей стороной, будет произведена деагрегация и наша последовательность будет воспринята операционной системой как отдельный пакет.
Подробнее об уязвимости можно прочесть в докладе Injection Attacks on 802.11n MAC Frame Aggregation
Код для эксплуатирования уязвимости github.com/rpp0/aggr-inject
Скрипт, генерирующий payload — aggr-inject.py.
Для инъекции фреймов от точки доступа к клиенту предлагается сгенерировать jpg файл, который будет скачивать жертва (как на картинке в заголовке поста). В обратную сторону, от клиента к точке предлагается посылать специальный сформированный POST запрос на веб-сервер атакующего.
Тип передаваемых данных не имеет никакого значения, достаточно иметь возможность создать управляемый атакующим поток данных. В данном случае взят HTTP как самый простой пример. При этом важно, чтобы данные были переданы в неизменном виде на сам wifi чип, поэтому данные должны быть переданы по открытому каналу (HTTPS не подходит), не подвергаться обработке, сжатию.
Самый простой пример демонстрации уязвимости: посылка широковещательных beacon фреймов. Маяков, которые посылает точка доступа, сообщая о своем имени сети (SSID).
Файл, инъецирующий маяки с именем сети «injected SSID» aggr_beacon.jpg 250MB
Скорее всего, вы не увидите новую сеть в списке доступных для подключения WiFi сетей, так как большинство операционных систем используют активное сканирование, и показывают только сети, ответившие им на probe request. Поэтому чтобы увидеть инъекцию пакетов нужно использовать пассивное сканирование.
Кстати, на заметку тем, кто используется Mac OS, можно дампать WiFi трафик родной картой airport. Рекомендую для этого мою тулзу airport-sniffer. Дамп можно будет найти в /tmp/airportXXXX.cap
Мой тестовый стенд идентичен картинке в заголовке поста. Вредоносный файл скачивается планшетом, дампер запущен на ноутбуке, подключенном к той же точке доступа TL-MR3020 с прошивкой openwrt 12.09. Также инъекция успешно воспроизводится с использованием USB адаптера tl-wn821n.
Вот как выглядят пойманные ноутбуком пакеты:
13:33:11.317916 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317916 4269971522us tsft bad-fcs -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [1.0* 35.0 23.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317917 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317918 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317919 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317921 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317922 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:11.317923 4269971522us tsft -84dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:00:00:00:00:00:00 (oui Ethernet) DA:Broadcast SA:00:00:00:00:00:00 (oui Ethernet) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
13:33:12.876472 4271529509us tsft bad-fcs -85dB noise antenna 0 2462 MHz 11g ht/20 72.2 Mb/s MCS 7 20 MHz short GI greenfield BCC FEC BSSID:18:00:00:00:00:00 (oui Unknown) DA:Broadcast SA:1c:e9:87:8a:54:36 (oui Unknown) Beacon (injected SSID) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] ESS CH: 1
По таймингам видно, что инъекции происходят очень бодро.
Для того чтобы провести реальную атакую необходимо подниматься на L2 и L3 уровни, то есть нужно знать MAC адрес точки доступа, в некоторых случаях MAC адрес клиента, IP адреса клиентов за NAT. Поэтому эксплуатировать уязвимость в реальных условиях крайне сложно. Максимум — это посылать deauth пакет и отключать всех клиентов от сети.
Мне удалось успешно провести инъекции TCP пакетов и я попытался пролезть на TCP порт клиента, находящегося за NAT, пытаясь создать в nf_conntrack трансляцию, пропускающую мои пакеты клиенту. Но у меня так и не получилось. Если послать клиенту SYN от имени удаленного хоста, его ответ SYN-ACK не создает трансляцию и ответить ему из мира нельзя. Если же послать от клиента SYN в мир и ответить ему, пусть даже создав трансляцию на роутере в состоянии ESTABLISHED, новый SYN из мира посланный клиенту будет отброшен. Даже фантазии на эту тему разбились о проблему с угадыванием seqence number. Хотя, может быть, я просто лошара и у вас получится.
Подобное можно успешно провернуть с UDP. Также в примерах есть способ сканировать хосты за NAT, посылая icmp.
Комментарии (19)
tgz
04.07.2015 16:13+11А всего то надо было указать смещение, где искать разделитель, что бы не просматривать весь пакет в поисках. Трудно поверить что в 21 веке такое бывает «случайно».
zhovner Автор
04.07.2015 19:39+1Но ведь размер пакета может быть разный, и агреггироваться может разное количество фреймов. Хотя наверное можно было бы поместить информацию о разделителях в заголовок, но в таком случае при поврежденном заголовке терялся бы весь агррегированный кадр.
IRainman
04.07.2015 19:43Думается, что всё просто и дело в обратной совместимости и смещение было либо негде указать либо невозможно было обработать такий пакет на других устройствах. Не настолько я в теме стандарта, но ведь это всё тот же 802.11.
История версий 802.11 с викиПри описании стандарта в скобках указан год его принятия. Скорость указана брутто.
802.11 — изначальный 1 Мбит/с и 2 Мбит/c, 2,4 ГГц и ИК стандарт (1997)
802.11a — 54 Мбит/c, 5 ГГц стандарт (1999, выход продуктов в 2001)
802.11b — улучшения к 802.11 для поддержки 5,5 и 11 Мбит/с (1999)
802.11c — процедуры операций с мостами; включен в стандарт IEEE 802.1D (2001)
802.11d — интернациональные роуминговые расширения (2001)
802.11e — улучшения: QoS, пакетный режим (packet bursting) (2005)
802.11F — Inter-Access Point Protocol (2003)
802.11g — 54 Мбит/c, 2,4 ГГц стандарт (обратная совместимость с b) (2003)
802.11h — распределённый по спектру 802.11a (5 GHz) для совместимости в Европе (2004)
802.11i — улучшенная безопасность (2004)
802.11j — расширения для Японии (2004)
802.11k — улучшения измерения радиоресурсов
802.11l — зарезервирован
802.11m — поправки и исправления для всей группы стандартов 802.11
802.11n — увеличение скорости передачи данных (600 Мбит/c). 2,4-2,5 или 5 ГГц. Обратная совместимость с 802.11a/b/g (сентябрь 2009)
802.11o — зарезервирован
802.11p — WAVE — Wireless Access for the Vehicular Environment (беспроводной доступ для среды транспортного средства)
802.11q — зарезервирован, иногда его путают с 802.1Q
802.11r — быстрый роуминг
802.11s — ESS Wireless mesh network[en] (Extended Service Set — расширенный набор служб; Mesh Network — многосвязная сеть)
802.11T — Wireless Performance Prediction (WPP, предсказание производительности беспроводного оборудования) — методы тестов и измерений
802.11u — взаимодействие с не-802 сетями (например, сотовыми)
802.11v — управление беспроводными сетями
802.11w — Protected Management Frames (защищенные управляющие фреймы)
802.11x — зарезервирован и не будет использоваться. Не нужно путать со стандартом контроля доступа IEEE 802.1X
802.11y — дополнительный стандарт связи, работающий на частотах 3,65-3,70 ГГц. Обеспечивает скорость до 54 Мбит/с на расстоянии до 5000 м на открытом пространстве.
802.11ac — новый стандарт IEEE. Скорость передачи данных — до 6,77 Гбит/с для устройств, имеющих 8 антенн. Утвержден в январе 2014 года.
802.11ad — новый стандарт с дополнительным диапазоном 60 ГГц (частота не требует лицензирования). Скорость передачи данных — до 7 Гбит/с.
Egor3f
04.07.2015 20:43В даннос случае фишка в том, что не обязательно вообще иметь физический доступ к сети — инъекция может поступать по HTTP от удалённого сервера.
IRainman
04.07.2015 21:19Да, но тем не менее, это не отменяет факта, что уязвимости подвержены только открытые сети стандарта 802.11n, а в открытой сети и без того проблем хватает.
Видимо я плохо написал, перефразирую: передача незашифрованных данных в открытой сети это и есть полный доступ к сети, это же просто единый поток ноликов и единиц и ничего более.
Ошибки были и есть всегда. Безусловно, конкретно этот фейл очень знатный. Но, в данном случае он лишь подтверждает известное правило: открытые сети небезопасны, если есть необходимость использовать открытую сеть, то необходимо шифровать весь передаваемый трафик другими способами. Если же весь поток в открытой сети будет зашифрован, например с помощью VPN подключения, то и проблемы не будет. Ведь так?
В общем по мне это прекрасная новость и мотивация не делать открытых сетей, в т. ч. общего пользования ибо даже без этой уязвимости людей разбирающихся в вопросах безопасности или людей, которым всё настроили администраторы, очень и очень немного, а открытые беспроводные сети огромная проблема безопасности для миллионов если не сотен миллионов человек.
P.S. не зря ООН признали шифрование базовым правом человека.mayorovp
06.07.2015 11:46Шифрование трафика тут не поможет. Во-первых, если доверять шифрование самому хакеру — он вам «нашифрует». Просто пошлет сырые данные с 443 порта и все. Картинка не загрузится — но ведь ему не картинка нужна? Во-вторых, всегда может оказаться рядом сосед с нешифрованным трафиком.
zhovner Автор
06.07.2015 11:49Ну, у меня, например, фаерволлом на физическом интерфейсе закрыто все кроме ipsec трафика, и даже если от соседа что-то прилетит, оно не будет воспринято. Разве только ARP-спуфинг в теории. Так что VPN все-таки решает проблему по большей части.
mayorovp
06.07.2015 13:21Файервол вам не поможет, если «прилетит» пакет Deauthentication. Просто потому что он не сможет отличить его от «настоящего» пакета Deauthentication.
ohm
04.07.2015 16:32+2Удивительно, если качать фаш файл aggr_beacon.jpg с веб-сервера находящегося в одной локальной сети с клиентом, то вайфай падает полностью у всех.
ValdikSS
04.07.2015 17:55Хм, а я вчера тестировал и наблюдал подобное поведение, но только если качать с телефона. Лаптоп не отваливался, а телефон себя вел так, будто какие-то проблемы с MTU (загрузка зависала после определенного количества скачанного). У меня Atheros AR9344 в AP, Intel Centrino 6250 в лаптопе (никаких разрывов), и MTK на телефоне.
TimsTims
05.07.2015 10:38Но ведь получается, что можно не просто подсовывать траффик, но и заранее сгенерировать такой статический файл, в котором будут использоваться разделители, WiFi также их съест в поток и разделит. Profit
Если это так, то можно как в старые времена заражать компьютеры через размещение картинки в интернете.zhovner Автор
05.07.2015 11:11+1Не все так просто. Чтобы послать что-то кроме radiotap заголовков нужно знать IP и MAC адреса целевых хостов.
nazargulov
05.07.2015 17:17-8IT-шники так смешно рисуют анимации. Ну вот с чего вы использовали аж три значка вредоносного пейлоада? Вы думаете это прикольно что-ли? Вырви глаз это.
zhovner Автор
05.07.2015 20:32+2Ну они какбэ разного типа и разного уровня OSI внутри одной картинки.
amarao
Ничего личного, но фраза «jpg как в начале поста» заставила меня вздрогнуть и проверить, что это не jpg, а всё-таки обычный анимированный gif.
zhovner Автор
Нет там такой фразы.
amarao
Для инъекции фреймов от точки доступа к клиенту предлагается сгенерировать jpg файл, который будет скачивать жертва (как на картинке в заголовке поста).
Egor3f
jpg файл — файл с инъекцией aggr_beacon.jpg.
На картинке в заголовке поста показана схема уязвимости, а не файл с инъекцией.
Ваш кэп.