Атака повторной установки ключа: как она работает без предустановленного ключа?

Автор атаки повторной установки ключа опубликовал скрипты на Github для тестирования точки доступа (AP) и клиентов.
Чтобы протестировать клиентов, нужно подключиться к фальшивой точке доступа, но при этом необходимо знать предварительно обShared ключ (PSK). Конечно, вы знаете пароль, потому что вы создали фальшивую точку доступа. Но если вы проводите настоящую атаку и создали фальшивую точку доступа с тем же essid, что и у настоящей точки доступа, клиенты, пытаясь подключиться к фальшивой точке доступа (которая действует как MITM), не смогут этого сделать, так как предварительно обShared ключ отличается. Поэтому, поскольку предварительно обShared ключ не совпадает, вы никогда не сможете переустановить PTK или GTK, потому что не получите все необходимые кадры для их воспроизведения. Я прав?

То же самое касается скрипта для тестирования настоящей точки доступа.
Если вы знаете предварительно обShared ключ настоящей точки доступа, предположим, что она поддерживает FT, тогда вы можете подключиться к ней для проведения необходимых тестов по повторному использованию номеров пакетов. Но если вы не знаете предварительно обShared ключ, и если точка доступа уязвима, как вы получите все кадры рукопожатия?

Я думаю, что с несовпадением предварительно обShared ключа вы получите только сообщения 1 и 2 рукопожатия.

Основной вопрос: Это не так, для выполнения MITM на основе канала вам необходимо иметь PSK, как вы сказали, чтобы иметь возможность получить 3-е сообщение из 4-стороннего рукопожатия.

Что касается вашего первого и последнего предположения: Да, вы правы!

Как отвечает на этот вопрос в разделе Вопросы и ответы

Если атакующий может провести атаку “человек посередине”, почему он не может просто расшифровать все данные?

Как было упомянуто в демонстрации, атакующий сначала получает позицию “человек посередине” (MitM) между жертвой и настоящей Wi-Fi сетью (называемой позицией MitM на основе канала). Однако эта позиция MitM не позволяет атакующему расшифровать пакеты

Также в статье (PDF) в разделе 3.2 Атака повторной установки ключа

Второе незначительное препятствие состоит в том, что мы должны получить позицию MitM между клиентом и AP.

Поэтому, поскольку предварительно обShared ключ не совпадает, вы никогда не сможете переустановить PTK или GTK, потому что не получите все необходимые кадры для их воспроизведения. Я прав?

Вы не правы. Почему?

Чтобы протестировать клиентов, нужно подключиться к фальшивой точке доступа, но необходимо знать предварительно обShared ключ. Конечно, вы знаете пароль, потому что вы создали фальшивую точку доступа. Но если вы проводите настоящую атаку и создали фальшивую точку доступа с тем же essid, что и у настоящей точки доступа, клиенты, пытаясь подключиться к фальшивой точке доступа (которая действует как MITM), не смогут этого сделать, так как предварительно обShared ключ отличается.

Это неправильное понимание. Ложная точка доступа не работает как полноценная инфраструктура, передающая свой собственный SSID, а выполняет функцию прозрачного L2 моста к оригинальной AP. Таким образом, на ложной точке доступа, проводящей атаку MitM, не установлено PSK.

Точно так же и со скриптом для тестирования настоящей точки доступа. Если вы знаете предварительно обShared ключ настоящей точки доступа, предположим, что она поддерживает FT, тогда вы можете подключиться к ней для проведения необходимых тестов по повторному использованию номеров пакетов. Но если вы не знаете предварительно обShared ключ, если точка доступа уязвима, как вы получите все кадры рукопожатия?

PSK не требуется. Любой может захватывать кадры рукопожатия. Это происходит постоянно. Без PSK они просто не очень полезны. Но именно так многие атаки против PSK и проводятся, так как, когда у вас есть рукопожатие, вы можете затем выполнять любое вычислительное задание, сколько угодно времени, оставаясь “в оффлайне” (например, производить грубую силу для PSK).

В этом случае, когда ложная точка доступа получает трафик от клиента, она передает трафик настоящей точке доступа и наоборот. Она вмешивается только путем переписывания кадров для части обмена WPA/WPA2 в попытке использовать уязвимость в обмене. Это делает PTK более простым для расчета (или, в “наилучшем случае” с точки зрения эксплойта, полностью предсказуемым).

KRACK никогда не предоставляет PSK при успешной атаке. Он только дает PTK, позволяя вам расшифровывать трафик “сессии”. Атака должна проводиться для каждого клиента, который подключается, и каждый раз, когда клиент переподключается, так как каждый раз производимый PTK должен быть различным (если только это не так из-за “наилучшего случая” для эксплойта).

Я думаю, что с несовпадением предварительно обShared ключа вы получите только сообщения 1 и 2 рукопожатия.

Если бы вы пытались создать ложную точку доступа с собственным PSK, вы были бы правы. Поскольку это не то, что происходит с KRACK, вы не правы.

Заключительный комментарий: Я хочу отметить, что KRACK, хотя и является отличной находкой, никогда не представлял реальной угрозы. Я до сих пор не слышал о единственном успешном использовании эксплойта в природе, и обновления снизили эксплойт до исторической заметки на данный момент. Не стесняйтесь прочитать мои мысли в другом ответе о том, почему это было так почти три года назад.