Broadpwn - A Remote Wifi Exploitation
In 2017, Exodus Intelligence (a security research group) dropped a blog about their newly discovered Broadpwn exploit.
Here are the basic points:
Their aim was to implement a Remote Exploit.
Must not require human interaction to trigger
Must not require complex assumptions about system state (can't probe for information)
The remote exploit must leave the system in a stable state
They wanted to find an exploit that affects the most number of devices as possible
At the time, all major device (Apple, Samsung, etc) used the same Wifi Chip - Broadcom’s BCM43xx Wifi Chip
They identified 802.11′s unencrypted chatter before establishing connection as a good attack surface
Probe Requests
Authentication Requests
Association Requests
They found that the header contains 1 byte that indicates the length of the packet, therefore, one can declare a max size of 255 bytes.
Historically, programmers made mistakes when handling lengths properly, hence, they focused their search on modules that worked with probe requests and lengths
They found that there existed a memcpy with no size checking
They then found that the buffer that was used to copy data into was only 44 bytes
Therefore, there was a buffer overflow of 211 bytes
Memory being allocated for `current_wmm_ie`:
`current_wmm_ie being used:
So, at the beginning, overflowing the buffer with random character cause the devices to crash
This proved the buffer overflow existed, but it violated one of the rules of it being a remote exploit
The buffer overflowed into memory that was static and was consistently located there, even after boots
ps was responsible for power saving
The following ps struct is below:
As one can see, there were timers being used. Timers are great because they are usually called regularly.
Within the timer function, they found a write primitive
After this, they could write anything and any where.
They then wrote to a patch table that Broadcom used
Basically, when Broadcom released a patch, they would update said table to point the program to the new chunk of code to execute
So, if they pointed to some shellcode, the program would execute it. This provided them with a ROP (Return-Oriented Programming) exploitation
Unfortunately, they only had 24 bytes available to write too (they couldn’t write into ps as that would cause the device to crash and hence, break one of the laws of remote exploitation). They could only use the SSID struct.
The solution was to write an egg hunter within the shellcode that would search the buffer that collects incoming packets (specifically beacon frames)
Packets have RWX permissions
To increase the chance of finding the shellcode, the air was flooded with said packets
This then gave them a successful remote exploit that gave them code execution on the device
