Взламываем WEP. Сценарий 1. Выдергивание пакетов из захваченных данных
Итак, мы собираемся использовать пакет из захваченных данных. А значит, уже запущен airdump-ng, перехватывающий пакеты идущие от беспроводной точки или к ней и найдено несколько arp-пакетов, которые можно использовать для инжекции.
Можно использовать не только ARP-пакеты: я сосредоточился на них только потому, что они гарантированно приведут к успеху и их легче всего отыскать в дампе захвата. Поясню слова о гарантированном успехе: любой клиент ответит на ARP-запросы, направленные непосредственно к нему. Запомните, не любой ARP – а лишь конкретный ARP-запрос для клиента, которого вы выбрали в качестве цели.
Ну что ж, пустим захват пакетов от/к AP. Чтобы уменьшить количество мусорных пакетов, используем BSSID фильтр, настроенный на нужную точку и нужный канал. В нашем примере это выглядит так:
# airodump-ng --channel 9 --bssid 00:14:6C:7E:40:80 -w arpcapture ath0
При этом необходимо, чтобы один или больше клиентов были в данный момент активны, т.к. при низкой клиентской активности шансов захватить что-либо полезное мало. Во время захвата вы можете скопировать результирующий файл для анализа или запустить WireShark и наблюдать захваченные пакеты в реальном времени.
Итак, теперь нашей целью является нахождение пакета с ARP-запросом, идущего от какого-нибудь клиента (проводного или беспроводного) через AP к нашему клиенту. Последний всегда ответит на адресованный ему ARP-запрос – а значит, пустит широковещательный ARP-ответ через AP.
Характеристики нужного нам входящего пакета:
• BSSID: точка доступа, в нашем случае - 00:14:6C:7E:40:80;
• Dest. MAC: broadcast (FF:FF:FF:FF:FF:FF);
• Src. MAC: не имеет значения;
• Длина пакета: 68 или 86 (68 – обычно длина ARP-запроса от беспроводных клиентов, 86 – от проводных).
Характеристики нужного нам исходящего пакета:
• BSSID: точка доступа, в нашем случае - 00:14:6C:7E:40:80;
• Dest. MAC: Src.MAC входящего пакета (означает ответ на запрос);
• Src. MAC: MAC-адрес клиента;
• Длина пакета: 68 или 86 – обычно длина ARP-запроса от беспроводных клиентов, 86 – от проводных).
Проще говоря, мы ищем ARP-запрос на клиента и ответ на него. Для этого настраиваем в WireShark фильтр:
(wlan.bssid == 00:14:6c:7e:40:80 and (frame.pkt_len>=68 and frame.pkt_len le 86))
Он отобразит пакеты, идущие от/к AP и имеющие длину больше или равную 68 и меньше или равную 86 байтам. Не забудьте поменять wlan.bssid на MAC-адрес вашей AP и, возможно, придется поменять длину пакетов, в зависимости от вариаций вашей системы. За основу возьмите этот фильтр.
Как только у нас появится несколько подходящих пакетов, можно воспользоваться этим фильтром, чтобы сосредоточиться на конкретном клиенте:
(wlan.bssid == 00:14:6c:7e:40:80 and (frame.pkt_len>=68 and frame.pkt_len le 86) and (wlan.da == ff:ff:ff:ff:ff:ff or wlan.sa == 00:0f:b5:46:11:19))
Поменяйте wlan.sa на MAC-адрес вашего клиента и диапазон длины пакета, чтобы сузить район поиска в случае необходимости. В качестве примера вы можете воспользоваться файлом http://download.aircrack-ng.org/wiki-files/other/arpcapture-01.cap, проверив на нем вышеприведенные фильтры.
Итак, глядя на файл arpcapture-01.cap, мы видим следующие пакеты:
- 391: это ARP-запрос от проводной рабочей станции нашему клиенту, пущенный широковещанием через AP. Ответа на него не будет и он потеряется;
- 416: AP пускает широковещательный ARP-запрос, полученный от проводной станции. Это повторный запрос, поскольку на первый (391) не было ответа;
- 417: клиент посылает ARP-ответ проводной станции через AP. Обратите внимание на короткое время между запросом и ответом;
- 501: беспроводная рабочая станция шлет ARP-запрос клиенту через AP. Этот пакет, по сути, запрос AP на широковещательную рассылку ARP-запроса;
- 503: AP шлет широковещательный ARP-запрос всем беспроводным клиентам;
- 504: клиент шлет ARP-ответ беспроводной рабочей станции через AP. Этот пакет, по сути, запрос AP на посылку ARP-ответа беспроводной рабочей станции.
Два возможных пакета для использования: 416 и 503. Можно попробовать оба, но 503 использовать лучше, поскольку на каждый инжектированный нами пакет, он будет генерировать два пакета данных: ответ от клиента к AP и AP к беспроводной рабочей станции. По сути, скорость захвата данных вырастет в два раза. Люди часто интересуются, как ускорить процесс инжекции – вот один из приемов.
Как только мы нашли одну или больше подобных пар, пометим их внутри WireShark, а затем сохраним, например, как dsarprequests.cap. Итак, теперь у нас есть файл с ARP-запросами, идущими к конкретному клиенту. Помните, что эти пакеты не гарантированно сработают, это всего лишь наиболее вероятные кандидаты из тех, что мы наблюдали. Возможно потребуются еще несколько пакетов, чтобы завершить работу.
Перезапустим захват пакетов:
# airodump-ng --channel 9 --bssid 00:14:6C:7E:40:80 -w aprcapture ath0
Убедитесь, что не используете ключ “--ivs”, так как потом вы будете использовать PTW метод для взлома WEP-ключа (то есть “aircrack-ng –z”), а PTW требует полного дампа пакета и работает только на ARP-запросах и ответах. Теперь во второй сессии запускайте:
# aireplay-ng -2 -r dsarprequests.cap ath0
Сейчас мы шлем ARP-запросы напрямую с нашего PC на клиента, минуя AP. На каждый запрос клиент будет слать ответ и количество пакетов данных будет увеличиваться. Запускаем в третьей сессии:
# aircrack-ng –z arpcapture*.cap
Ключ взломан!

