Probe Request, beacon frames
В беспроводной среде есть огромное количество процессов, которые протекают незаметно для пользователя. Есть три типа пакетов (Data, Control, Management) и как минимум 39 типов фреймов, и есть всего один фрейм (и один режим работы беспроводного клиента), который позволяет решить поставленную задачу.
Это режим активного сканирования (active scanning), когда Клиент активно (посылая пакеты Probe Request) сканирует все доступные каналы на предмет наличия подходящей беспроводной сети. Probe Request, как фрейм управления (management frame), посылается на максимальной мощности и на самой низкой скорости передачи. Именно этот режим позволяет точкам доступа, работающим на других каналах, получить Замер с Клиента и сформировать Сэмпл.
Есть как минимум два режима работы, когда используется сканирование:
1. При выборе клиентом подходящей точки доступа, для подключения к беспроводной сети
2. При выборе клиентом подходящей точки доступа во время перехода с точки на точку (во время роуминга)
Клиенту доступно два механизма сканирования радиосреды:
— пассивное сканирование (passive scanning)
— активное сканирование (active scanning)
В первом случае беспроводной клиент слушает beacon пакеты (посылаемые каждые 102,4мс. по умолчанию), во втором – посылает probe request и дожидается probe response.
Очевидно, что это вопрос выбора между скоростью сканирования и затрачиваемой на это энергией (самый затратный режим работы беспроводного клиента – это передача).
Телефон с включённым WiFi может периодически отправляет в эфир запросы, т.н. probe requests, содержащие MAC самого устройства и имя известной WiFi сети, с которой он соединялся ранее в надежде, что эта сеть ему ответит. Этот механизм, активный поиск, является альтернативным пассивному, когда устройство, желая соединиться с сетью, слушает эфир, ожидая маячковые сообщения (beacon frames) от точки доступа [Passive WiFi Tracking].
Если устройство подключено к сети, то ему не нужно оповещать другие сети о себе. Однако, отключив устройство от точки доступа (например послав фрейм деаутентификации с помощью aireplay-ng: aireplay-ng -0 5 -a -c ) можно рассчитывать на то, что устройство будет зондировать эфир рассылая запросы.
Их личного опыта могу сказать, что телефон может отправлять probe request при включении или при выходе из режима «в самолёте» даже если wifi выключен в настройках.
Посмотреть пристальнее на эти пакеты можно в Wireshark используя фильтр wlan.fc.type_subtype == 4
Таким образом можно привязать конкретное устройство к wifi сети (с поправкой на то, что сетей с данным именем может быть несколько) и далее попытаться определить географическое положение этой сети. Последнее возможно при помощи геоинформационных сервисов в Интернете, например WiGLE (поиск по сетям доступен после регистрации). Если в Сети данных нет, то можно обойтись собственноручно собранной информацией о местоположении WiFi сетей, например с помощью мобильных приложений (Google Play: Wigle Wifi Wardriving).
Приём probe request
Для того, чтобы принимать probe requests в режиме реального времени, включим на WiFi карте режим монитора:
а затем запустим версию wireshark с текстовым интерфейсом:
tshark -i wlan0 subtype probereq
При желании вывод программы можно настроить:
tshark -i wlan0mon -Y ‘wlan.fc.type_subtype == 4’ -T fields -e frame.time -e wlan.sa_resolved -e wlan_mgt.ssid
-i wlan0mon интерфейс — wifi карта в режиме монитора;
-Y ‘wlan.fc.type_subtype == 4’ фильтр для печати пакетов на экран;
-T fields — определим, какие конкретно данные каждого пакета выводить на экран, приведя отдельные поля после ключа -e:
wlan.sa_resolved — MAC адрес источника пакета, где половина адреса заменена на название его производителя (vendor). Если необходимости в последнем нет, то печатаем просто MAC: wlan.sa.
wlan_mgt.ssid — самое интересное, SSID сети.
Созерцание вывода программы можно соединить с одновременной записью в файл:
tshark -i wlan0mon -Y ‘wlan.fc.type_subtype == 4’ -T fields -e frame.time -e wlan.sa_resolved -e wlan.sa -e wlan_mgt.ssid | tee -a probes.dump
tee — для одновременного вывода и записи в файл. tshark при печати на экран использует буфер, а ключ -l заставляет утилиту очищать буфер при выводе каждого пакета, таким образом печать будет происходить одновременно с обработкой пакета.
Отфильтруем probe request с пустым SSID (широковещательные?) добавив к фильтру выражение wlan_mgt.ssid != 0
tshark -i wlan0mon -Y ‘wlan.fc.type_subtype == 4’ -T fields -e frame.time -e wlan.sa_resolved -e wlan.sa -e wlan_mgt.ssid | tee -a probes.dump
Наконец можно направив вывод через grep показывать только определённые устройства или же избавить себя от их упоминания (ключ -v):
tshark . | grep -v -e «11:11:11:11:11:11» -e «11:11:11:11:11:22»
Сделать задачу мониторинга немного проще призван скрипт shee.sh
Кроме того, утилита может работать в нескольких режимах. Например ждать появления определённого MAC адреса в эфире и при обнаружении подавать звуковой сигнал:
sudo shee.sh -i wlan0mon -M 1 -m 11:22:33:44:55:66 -s
-M 1 — следить за конкретным MAC адресом
-m тот самый mac адрес
-s — при обнаружении подавать звуковой сигнал
Наблюдать устройства посылающие probe requests можно и в airodump-ng. Утилита показывает активные устройства (мак, время появления, время последнего пакета, ESSID и т.д.). в реальном времени. Если включена запись в файл, то данные об эфире также будут сохранены в CSV файл.
Scapy
Создавать, отправлять и принимать этот тип wifi кадров, можно с помощью мощного пакета Scapy. Он включает утилиту командной строки, в которой можно выполнять операции в интерактивном режиме, и пакет для Python.
WiFi Probe Requests Explained
If you ever used our ESP8266 Deauther, you might have wondered what the probe attack is for. We get questions like this a lot. So let’s have a look at probe requests and what they are used for. 🕵️♀️
Active and Passive Scanning
If you open the WiFi settings menu on your phone, you’ll see a list of available networks. But how does the phone know about them?
There are two ways to discover WiFi networks: either by passively waiting and listening for announcements (beacon frames) from access points or by actively asking every WiFi device around if they are a network using probe requests.
When an access point receives a probe request frame, it will reply with a probe response frame.
The Problem with Meta Data
Probe requests are a type of WiFi management frame. They are not encrypted, since they contain no user data. They are used simply for network discovery.
But it’s common that a device will actively ask for a specific network name. Meaning the probe request will contain the SSID of a known network in cleartext. In other words, your phone might be leaking the name of your home network constantly. And not just that, it’s probably broadcasting the names of every network you ever connected to!
This data can be used to identify you because your phone is likely to have a unique list of known networks. In addition, services like WiGLE can be used to pinpoint an SSID to a specific location.
So by simply listening for probe requests, you can track how many WiFi clients are nearby and where they have been. Plus the metadata provided by the MAC address of said clients like the name of the manufacturer (i.e. Apple).
Because WiFi clients tend to send probe requests regularly, it’s possible to use mesh networks to track their movement. Systems like this could be used in locations like shopping malls to track the routes of customers.
Rogue APs
But it gets worse! Someone could collect the SSID from a received probe request, open a new WiFi network and give it the exact same name, then send a probe response. The client who sent the request will then automatically connect to that network, thinking it knows it. But really, it could be a malicious network that’s sniffing all your traffic. Worst of all, the user might not even notice it because their device switched networks in the background without informing them.
This is actually a feature at what the WiFi pineapple from Hak5 excels at! So really this isn’t some abstract theory, everyone with the right tools can pull this attack off.
Now that being said, there are limits to this attack. For example, if the rogue access point is using a different kind of encryption than the original network (i.e. network is open instead of using WPA2), it won’t work. The WiFi client will also refuse to switch networks if it’s already connected to one with a stronger signal. So it’s not guaranteed to work with every WiFi client all the time, but it is a very effective attack.
Probe Attacks
To answer the question of what the probe attack in the ESP8266 Deauther is for; it broadcasts a lot of probe requests with random SSIDs. This can be used to confuse probe request sniffers, like the mentioned WiFi Pineapple. Learn more about it in the video Testing WiFi Pineapple with ESP8266 Deauther.
Another form of abusing probe frames for attacking is to flood a specific access point with requests. If the access point doesn’t recognise the attack and tries to respond to each request, it will actively participate in the attack. This is because these packets take up a lot of air time and spamming them will basically clog the wifi channel and you will no longer be able to use the network effectively.
Probe Request Sniffing
Now you know all about the dangers, but how can you check if your WiFi devices are sending probe requests?
Luckily for you, we make a tool that’s capable of that. Our Deauther V3 can find WiFi devices and see the probe requests they’re sending. You can flash any ESP8266 development board with the firmware or buy our Andromeda board at spacehuhn.store.
Alternatively, you can use airodump-ng (part of the aircrack-ng suite), Wireshark, or a script like probeSniffer. But you will need a USB WiFi adapter that is capable of monitor mode.
MAC Randomization
One thing to look out for when scanning for probe requests is MAC randomization. Nowadays a lot of WiFi clients use randomized MAC addresses for sending probe requests. This makes it a lot harder to fingerprint and track a device. You can easily get the impression that there are more devices around than there actually are.
If you want to learn more about MAC randomization and its limits, have a look at: Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms