WPA3 Dragonfly Handshake - Revision history

Tschachn: /* 802.11 candidate frames for fuzzing */

2018-11-20T16:11:11Z

802.11 candidate frames for fuzzing

← Older revision		Revision as of 16:11, 20 November 2018
Line 575:		Line 575:
	All fields of frames with variable type, length and value attributes seem to be promising regarding overflow vulnerabilities.		All fields of frames with variable type, length and value attributes seem to be promising regarding overflow vulnerabilities.
	For example the SSID takes up to 32 Bytes memory, but it might be interesting to check whether we can overflow a statically allocated memory location.		For example the SSID takes up to 32 Bytes memory, but it might be interesting to check whether we can overflow a statically allocated memory location.

			It's also possible to fuzz ''outside'' of the 802.11 specification to test whether the standard is correctly parsed and useful error handling is incorporated.

	== Resources ==		== Resources ==

2018-11-20T16:06:02Z

Fuzzing the Dragonfly/SAE handshake

@@ Line 562: / Line 562: @@
 Only fuzzing in state 1 is easy, because raw packet injection is easy. Other states require interaction with
 drivers.
 == Resources ==

2018-11-20T15:48:47Z

Use monitor or master mode for fuzzing?

← Older revision		Revision as of 15:48, 20 November 2018
Line 551:		Line 551:

	For fuzzing it's optimal to use Python3 as programming language in combination with the Scapy network package manipulation library.		For fuzzing it's optimal to use Python3 as programming language in combination with the Scapy network package manipulation library.


	https://blogs.arubanetworks.com/industries/understanding-802-11-state-machine/		https://blogs.arubanetworks.com/industries/understanding-802-11-state-machine/

2018-11-20T15:48:32Z

Use monitor or master mode for fuzzing?

← Older revision		Revision as of 15:48, 20 November 2018
Line 544:		Line 544:

	There are many other internal states in the driver, but those three are the most fundamental.		There are many other internal states in the driver, but those three are the most fundamental.
			Fuzzing State 1 is much easier than the other states, because they require successful authentication/association.
			Additionally, 802.11 frames must be acked within very short delays, which makes it very hard to achieve fuzzing in monitor mode with a wireless card.
			Another difficulty is that there no verbose information/logging from the firmware to the operating system.

			In order to increase the likelihood that beacon and probe response frames are parsed by the fuzzed AP, a fuzzer client can flood the network with those packets on various channels.

			For fuzzing it's optimal to use Python3 as programming language in combination with the Scapy network package manipulation library.


	https://blogs.arubanetworks.com/industries/understanding-802-11-state-machine/		https://blogs.arubanetworks.com/industries/understanding-802-11-state-machine/

2018-11-20T14:49:09Z

Use monitor or master mode for fuzzing?

← Older revision		Revision as of 14:49, 20 November 2018
Line 536:		Line 536:

	=== Use monitor or master mode for fuzzing? ===		=== Use monitor or master mode for fuzzing? ===

			The 802.11 finite state machine has essentially three different states:

			* State 1: initial state, not authenticated, not associated. Client probes for AP
			* State 2: authenticated, not associated. Client is authenticated to the AP
			* State 3: authenticated, associated. Client is authorized to send and receive data from the wired network through the AP.

			There are many other internal states in the driver, but those three are the most fundamental.

	https://blogs.arubanetworks.com/industries/understanding-802-11-state-machine/		https://blogs.arubanetworks.com/industries/understanding-802-11-state-machine/

2018-11-20T14:39:07Z

Fuzzing the Dragonfly/SAE handshake

← Older revision		Revision as of 14:39, 20 November 2018
Line 509:		Line 509:

	It is easy to exclude security checks in dragonfly in cryptographic primitives.		It is easy to exclude security checks in dragonfly in cryptographic primitives.

			When a fuzzer for the dragonfly handshake is built, it would be advisable to create '''a smart/protocol-aware fuzzer''' and not a generic fuzzer that just creates any kind of package randomly.

	=== Reasons that make fuzzing promising ===		=== Reasons that make fuzzing promising ===

2018-11-20T14:32:47Z

Reasons that make fuzzing promising

← Older revision		Revision as of 14:32, 20 November 2018
Line 522:		Line 522:
	Maybe the biggest reason why fuzzing Wifi drivers is promising, because		Maybe the biggest reason why fuzzing Wifi drivers is promising, because

	1. Exploits can be triggered over the air		* 1. Exploits can be triggered over the air
	2. When code execution is achieved, it usually runs with kernel privileges		* 2. When code execution is achieved, it usually runs with kernel privileges
	3. A wide array of manufactures creating device drivers heightens the possibility that bugs arise		* 3. A wide array of manufactures creating device drivers heightens the possibility that bugs arise

	=== Which parts of the Dragonfly handshake might be candidates for vulnerable implementations? ===		=== Which parts of the Dragonfly handshake might be candidates for vulnerable implementations? ===

2018-11-20T14:32:04Z

Reasons that make fuzzing promising

← Older revision		Revision as of 14:32, 20 November 2018
Line 519:		Line 519:
	This leads to a heterogeneous landscape of implementations of the new dragonfly handshake.		This leads to a heterogeneous landscape of implementations of the new dragonfly handshake.
	There will be vulnerable implementations. Fuzzers can help discover them.		There will be vulnerable implementations. Fuzzers can help discover them.

			Maybe the biggest reason why fuzzing Wifi drivers is promising, because

			1. Exploits can be triggered over the air
			2. When code execution is achieved, it usually runs with kernel privileges
			3. A wide array of manufactures creating device drivers heightens the possibility that bugs arise

	=== Which parts of the Dragonfly handshake might be candidates for vulnerable implementations? ===		=== Which parts of the Dragonfly handshake might be candidates for vulnerable implementations? ===

2018-11-12T14:29:46Z

ECDH

← Older revision		Revision as of 14:29, 12 November 2018
Line 42:		Line 42:
	Both Alice and Bob chose the following domain parameters:		Both Alice and Bob chose the following domain parameters:

	* A prime <~~code~~>p</~~code~~> and the elliptic curve <~~code~~>E: y^2 = x^3 + ax + b ~~mod~~ p</~~code~~>		* A prime <math>p</math> and the elliptic curve <math>E: y^2 = x^3 + ax + b\; \bmod p</math>
	* A primitive element (generator) <code>P = (x_P, y_P)</code>		* A primitive element (generator) <code>P = (x_P, y_P)</code>

2018-11-07T13:27:36Z

Dragonfly/SPEKE simplified

← Older revision		Revision as of 13:27, 7 November 2018
Line 140:		Line 140:

	Therefore the key <code>K</code> cannot be computed!		Therefore the key <code>K</code> cannot be computed!

			'''Even if the password guess is correct, you cannot confirm the correctness of your guess, because its very unlikely that the attacker also picked the random values correctly (those random values are in the range of at least 2^128 or more)'''

	== Dragonfly handshake (Simultaneous Authentication of Equals) ==		== Dragonfly handshake (Simultaneous Authentication of Equals) ==