Wireshark WPA 4-стороннее рукопожатие


13

С этой вики-страницы :

WPA и WPA2 используют ключи, полученные из рукопожатия EAPOL, для шифрования трафика. Если для сеанса, который вы пытаетесь расшифровать, присутствуют все четыре пакета подтверждения связи, Wireshark не сможет расшифровать трафик. Вы можете использовать фильтр отображения EAPOL, чтобы найти пакеты EAPOL в вашем захвате.

Я заметил, что расшифровка работает также с (1, 2, 4), но не с (1, 2, 3). Насколько я знаю, первых двух пакетов достаточно, по крайней мере для того, что касается одноадресного трафика. Может кто-нибудь объяснить, как именно Wireshark справляется с этим, другими словами, почему работает только предыдущая последовательность, учитывая, что четвертый пакет является просто подтверждением? Кроме того, гарантируется ли, что (1, 2, 4) всегда будет работать, когда (1, 2, 3, 4) работает?

Прецедент

Это рукопожатие (1, 2, 4) и зашифрованный ARPпакет (SSID:, SSIDпароль :) passwordв base64кодировке:

H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj / n4GhHkhfXNHr37KQgWEqAwQzMAgx
6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4 + СПЦ + H0MngwLUZMarj4Rn
S8vInf5yfO7mgrMyr9g / Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn
ITk1gBnJkeX / GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz + VGLl + snrF7j2EnHQy3JjDKPb9
3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ
9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT + 0 / J3LP
gie59HFL + 5RDIdmZ8rGMEldN5s668eb / tp8vQ + 7OrT9jPj / B7425QIGJI3Pft72dLxav8BefvcGU
7 + kfABxJX + SjAgAA

Расшифровать с помощью:

$ base64 -d | gunzip > handshake.cap

Запустите, tsharkчтобы увидеть, правильно ли он расшифровывает ARPпакет:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

Следует напечатать:

  1 0,000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Ключ EAPOL
  2 0.006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Ключ EAPOL
  3 0.038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Ключ EAPOL
  4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 в 00: a0: c5: 68: 3a: e4

Это не может .. это должно быть дешифрование, потому что у него есть все четыре, или вы подключены к сети Wi-Fi, и это расшифровывает пакеты
Пол

Я (очевидно) говорю о пакетах, захваченных в режиме RFMON.
cYrus

@Paul: я редактировал вопрос; ты можешь ответить?
cyrus

Я бы хотел. Если вы следуете последовательности EAPOL, у клиента будет PTK только после первого пакета (передается анонс). AP знает PTK после второго пакета (snonce). Если вы наблюдаете эти два и знаете MAC, которые вы, конечно, делаете, и ssid + psk, то это должно быть все, что вам нужно. Третий пакет - это просто GTK для широковещательной и многоадресной передачи, а четвертый - просто ACK. Если вы расшифровываете одноадресную рассылку (что является ответом arp), то первых двух пакетов должно быть достаточно. Я не могу помочь, но думаю, что я что-то упустил, так как все говорят, что вам нужно все четыре.
Пол

Вы продвинулись дальше с этим?
Пол

Ответы:


1

Обмены EAPOL также используются для обновления временных ключей. Новые ключи устанавливаются на соискателя после его отправки 4/4 и устанавливаются на аутентификаторе, когда он получает 4/4 [1]. Если Wireshark должен правильно обрабатывать повторный ввод, он должен использовать ключи только после чтения пакета 4/4 в кадре, потому что пакеты могут все еще передаваться во время повторного ввода (даже в случае, когда они не должны, из-за буферизации)

Для первых 4WHS возможно не ждать 4/4, но вполне понятно, что им просто лень это реализовывать. 3/4 по-прежнему необходим, поскольку он содержит групповые ключи (даже если вы не заинтересованы в них, но знаете, что вы не увидите ARP-запросы от точки доступа или клиента, для которых у вас нет части его 4WHS) и ключи управления. Вы также можете пропустить 3/4, но тогда у вас нет подтверждения, что обмен был успешным, потому что 3/4 используется для проверки того, что Аутентификатор знает PMK.

[1] Обратите внимание, что при текущей схеме, если сообщение 4/4 потеряно, соискатель начал использовать новый ключ, а аутентификатор все еще использует старый ключ, и повторная отправка 3/4, зашифрованная старым ключом, не поможет , Эта проблема, среди многих других с WPA2, решена в последнем стандарте 802.11 2012 года, когда параллельно удерживаются два ключа.


1

Вся информация, необходимая для создания PTK, обменивается на шагах 1 и 2. Этого должно быть достаточно для расшифровки одноадресного трафика.

Без шага 3 у вас не будет GTK, поэтому расшифровка многоадресной / широковещательной передачи невозможна.

Шаг 4 не является действительно необходимым для расшифровки перехваченного трафика, но если нет шага 4, клиент / точка доступа не начнет использовать шифрование. Wireshark может отключить это до того, как попытается расшифровать данные.


0

Ну, очевидно, документация WireShark неверна. :-)

Сойдя с документации здесь :

  • После EAPOL 1 и 2 обе стороны знают временный ключ, который будет использоваться для расшифровки трафика.
  • Третье сообщение является доказательством того, что обе стороны знают временный ключ и указывает, что Аутентификатор (базовая станция) готов начать использовать временный ключ.
  • Четвертое сообщение запускает переключение с PMK, установленного перед EAPOL, на временный ключ, полученный в EAPOL.

Таким образом, это имеет смысл. WireShark не нужно сообщение 3 ни для чего. Он знает ключи после сообщений 1 и 2, но ожидает начала их использования для расшифровки трафика, пока не получит сообщение 4.

Нет никаких гарантий на что-либо в жизни, особенно на поведение свободного программного обеспечения, но разумно поспорить, что не будет необходимости для сообщения 3, чтобы WireShark расшифровывал сеанс.


Мне кажется, что пакет 4 тоже не нужен - он просто предназначен для его ожидания.
Пол

@Paul, это все равно что сказать «резюме» не нужно после «паузы».
Старый Pro

@OldPro, я не уверен, что ожидание 4 ° - это хорошая идея, когда захваченные пакеты теряются, особенно когда они путешествуют по воздуху.
cYrus

@cYrus, ожидание 4 важно, так как ключи шифрования должны быть изменены одновременно с обеих сторон. Если клиент не получает 4, он не знает, что база получила 3. Если клиент не получает 4, он отправляет 3 снова (что вызывает повторную отправку 4), пока не получит 4 или не прекратит попытки создать соединение.
Old Pro

@OldPro: я не говорю о протоколе. Обе стороны могут получить все пакеты, но они могут быть отброшены или не перехвачены объектом, который пассивно перехватывает трафик.
cYrus

0

Это не объясняет почему, но в любом случае цитирование из документации airdecap-ng ,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets. 
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.