airodump-ng не ловит handshake

[M@ZAX@KEP]

Дело было вечером, делать было много чего полезного, но у нас было 2 ноутбука, 75 wi-fi сетей в общаге, 4 бутылки пива и 2 придурка, которым захотелось взломать соседскую сетку.
Для начала решили провести атаку на собственной сети чтобы хэндшейка не ждать долго, а самим его инициировать. Роутер вещал с WPA2, один ноут был назначен на роль пользователя, второй - атакующего.
Пользователь подключен и потихоньку качает торрентик (чтобы уж наверняка пакеты по wi-fi летели).
У атакующего всё по стандартной технологии: airmon-ng start wlan0; airodump-ng mon0, словили bbsid нашей сетки, дальше airodump-ng --bssid bssid:нашей:сетки -w testcap mon0
Программа вывалила список клиентов сети (состоящий из одного пользователя) и начала отсчитывать летящие по сети пакеты. Вроде полёт нормальный, решили, что пора бы и handshake слать. Пользователь отключается от сети, подключается снова. Начинает сёрфать. Счётчик пакетов у атакующего продолжает набегать, а заветного хэндшейка нет. Попробовали несколько раз - безрезультатно. Так как оба ноута и wi-fi точка находились в одной комнате, фактор плохого сигнала исключён. Встроенный wi-fi адаптер на ноуте акатующего пропускает пакеты? Или может роутер помнит bssid клиента после первой авторизации и при последующих подключениях авторзации не запрашивает и никакого хэндшейка и не было?

[zyl]

а так пробовали?
aireplay-ng -0 10 -a (bbsid) -c (mac пользователя) mon0

[M@ZAX@KEP]

Сообщение от zyl

а так пробовали?
aireplay-ng -0 10 -a (bbsid) -c (mac пользователя) mon0

Если не ошибаюсь, чтобы выбить пользователя из сетки и заставить снова отправить handshake. А зачем, если я сам могу переподключиться? Кстати, да... оно не работает =)

[zyl]

тогда я тоже присоединяюсь к вопросу, почему при дисконнекте пользователя от AP и последующем коннекте, airodump не ловит хэндшейки? Как писали выше уровень сигнала не брать в расчет, т.к. бывает что и сигнал бывает ниже, и пакетов он меньше перехватывает(потери больше), но тем не менее хэндшейки ловит с первого раза.
И ещё я слышал в пакете aircrack не очень хорошо реализован метод поиска хэндшейков, мол можно и "неправильный" поймать, который нельзя будет расшифровать, правда ли это?

[Ravenous]

Сообщение от zyl

тогда я тоже присоединяюсь к вопросу, почему при дисконнекте пользователя от AP и последующем коннекте, airodump не ловит хэндшейки? Как писали выше уровень сигнала не брать в расчет, т.к. бывает что и сигнал бывает ниже, и пакетов он меньше перехватывает(потери больше), но тем не менее хэндшейки ловит с первого раза.
И ещё я слышал в пакете aircrack не очень хорошо реализован метод поиска хэндшейков, мол можно и "неправильный" поймать, который нельзя будет расшифровать, правда ли это?

Иногда бывает, что AP находится к тебе ближе, а клиент за AP(ещё дальше от тебя). Т.е. пакеты от клиента могут спокойно долетать до AP, а атакующему уже будет сложнее ловить пакеты от клиента до AP, но атакующий может легко ловить пакеты от AP к клиенту, тогда вы и видете в airdump-ng хороший сигнал. Но handshakes не удаётся словить из-за этого. Иногда бывает ровно наоборот - атакующий ближе к клиенту,а AP ещё дальше от клиента (за ним). В таком случае как ты и писал, что сигнал показывает плохой(есть потери) тем не менее handshakes ловятся, ввиду таких позиций. И те, и другие случаи были у меня в практике.
На счёт "неправильных" handshakes, то помоему aircrack напишет, что он "неправильный", но точно не помню.

[zyl]

Что ж, спасибо за ответ. Но на памяти моей есть несколько случаев, когда сигнал хороший и от клиента, и от АР (прямая видимость обоих). Дисконнект/коннект есть, а хэндшейка нет. Ведь случай M@ZAX@KEP как раз из этой оперы.

[M@ZAX@KEP]

Ravenous, спасибо за информацию про расположения точки, атакующего и пользователя, но вопроса это не снимает. Атакующий с пользователем находились на расстоянии буквально 20 см, а точка от них ещё в полутора метрах.

[Ravenous]

Если не видели, вот ещё с офф. сайта

It can sometimes be tricky to capture the four-way handshake. Here are some troubleshooting tips to address this:

• Your monitor card must be in the same mode as the both the client and Access Point. So, for example, if your card was in “B” mode and the client/AP were using “G” mode, then you would not capture the handshake. This is especially important for new APs and clients which may be “turbo” mode and/or other new standards. Some drivers allow you to specify the mode. Also, iwconfig has an option “modulation” that can sometimes be used. Do “man iwconfig” to see the options for “modulation”. For information, 1, 2, 5.5 and 11Mbit are 'b', 6, 9, 12, 18, 24, 36, 48, 54Mbit are 'g'.
• Sometimes you also need to set the monitor-mode card to the same speed. IE auto, 1MB, 2MB, 11MB, 54MB, etc.
• Be sure that your capture card is locked to the same channel as the AP. You can do this by specifying ”-c <channel of AP>” when you start airodump-ng.
• Be sure there are no connection managers running on your system. This can change channels and/or change mode without your knowledge.
  
• You are physically close enough to receive both access point and wireless client packets. The wireless card strength is typically less then the AP strength.
• Conversely, if you are too close then the received packets can be corrupted and discarded. So you cannot be too close.
  
• Make sure to use the drivers specified on the wiki. Depending on the driver, some old versions do not capture all packets.
• Ideally, connect and disconnect a wireless client normally to generate the handshake.
• If you use the deauth technique, send the absolute minimum of packets to cause the client to reauthenticate. Normally this is a single deauth packet. Sending an excessive number of deauth packets may cause the client to fail to reconnect and thus it will not generate the four-way handshake. As well, use directed deauths, not broadcast. To confirm the client received the deauthentication packets, use tcpdump or similar to look for ACK packets back from the client. If you did not get an ACK packet back, then the client did not “hear” the deauthentication packet.
• Try stopping the radio on the client station then restarting it.
• Make sure you are not running any other program/process that could interfere such as connection managers, Kismet, etc.
• Review your captured data using the WPA Packet Capture Explained tutorial to see if you can identify the problem. Such as missing AP packets, missing client packets, etc.

Так же, гляньте ваш дамп в Wireshark по фильтру EAPOL, когда будете эксперементировать с различными параметрами.

Дальше airodump-ng --bssid bssid:нашей:сетки -w testcap mon0

Забыл спросить про такую элементарную вещь, вы канал опцией -c зафиксировали?

[M@ZAX@KEP]

Забыл написать сразу, фиксировал =) На том канале, который отображался для отслеживаемого пользователя сетки на стадии "airodump-ng --bssid bssid:нашей:сетки -w testcap mon0". Очевидно, не помогло. За цитату с сайта благодарен, будет время - вернусь к этому вопросу чтобы разобраться, в чём именно была причина.

[shpavck-pov-a]

Всем привет, та же проблема... (решил не создавать новую тему)
Пробую все на своей точке (хотя проделовал это и с соседской).
AP и клиент в одной комнате (пробывал разносил в разные чтоб были не очень близко)
---
Обозначения:
XX:XX:XX:XX:XX:XX(CL) - mac адресс клиента
XX:XX:XX:XX:XX:XX(AP) - mac адресс AP

Мои действия:
- Перевожу карту в режим "monitor mode"
#airmon-ng start wlan0
выводит:
monitor mode enabled on mon0

- Cканируем и получаем список доступных сетей ( видно AP + подключеного клиента)
#airodump-ng mon0
выводит:
CH 1 ][ Elapsed: 1 hour 48 mins ][ 2012-12-04 00:35

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

XX:XX:XX:XX:XX:XX(AP) -35 100 63754 4221 0 1 54e. WPA2 CCMP PSK MyName

BSSID STATION PWR Rate Lost Packets Probes

XX:XX:XX:XX:XX:XX(AP) XX:XX:XX:XX:XX:XX(CL) 0 0 - 1 0 7050

- Пишем все пакеты в файл для точки на канале 1
#airodump-ng mon0 --channel 1 --bssid XX:XX:XX:XX:XX:XX(AP) -w wpa2
выводит:
(вехняя картинка)

- Деавторизуем клиента
#aireplay-ng -0 1 -a XX:XX:XX:XX:XX:XX(AP) -c XX:XX:XX:XX:XX:XX(CL) mon0
выводит:
Waiting for beacon frame (BSSID: XX:XX:XX:XX:XX:XX(AP)) on channel 1
Sending 64 directed DeAuth. STMAC: [XX:XX:XX:XX:XX:XX(CL)] [61|64 ACKs]
вижу на самом клиенте он переподключается
---

Проблема - нет handshake хоть ты тресни. Если у кого есть какие-то соображения, у кого была такая проблема и кто знает куда копать, поделитесь