The vulnerability was discovered by a researcher from the Google Project Zero team Ian Beer. He published an extensive article on December 1 , in which he described in detail both the vulnerability itself and the history of its discovery. The simple description of the vulnerability makes it little different from the others: a connection is established to the victim's device via AWDL, a series of prepared packets are sent, causing a buffer overflow and arbitrary code execution. The multi-page blog post shows that the reality is much more complicated. The researcher many times could step back and confine himself to demonstrating a DoS attack, a fall of a device based on iOS or macOS. But still he brought the matter to the end: in the video of the attack, he hacks into his own iPhone in two minutes and steals personal data from it in three more minutes.
Beer got the idea to "dig" exactly in the direction of wireless communication in 2018, after Apple accidentally released the beta version of iOS without removing the function names from the kernelcache module (which contains the kernel itself and some other modules). This mistake somewhat simplified the life of the researchers, as more meaningful textual information about the principles of the kernel's operation appeared. There Beer found references to AWDL in the input processing function. The first result was a bug report that the OS crashed after sending incorrect packets over the air - this bug was fixed in the macOS 10.15.3 and iOS 13.1.1 release. That is, back in January 2020, the problem was closed.
But Bier spent another six months investing in his own knowledge and the science of finding vulnerabilities, as well as protecting against them. He perfected his initial exploit by implementing a data theft attack without user intervention. Unlike many other attacks that involve being close to the victim, the attacker and the victim don't even need to be on the same Wi-Fi network. Apple technology involves the creation of a mesh network between devices, and it works in parallel with the main connection to the access point. The researcher needed to disassemble the communication protocol in order to figure out at least how to send packets so that they meet his requirements. Next, it was required to activate the desired communication mode, select a set of sent data so that it would cause a failure, and implement the execution of arbitrary code.The video above shows the entire attack process, which uses a Raspberry Pi computer with a Wi-Fi module.
What is remarkable about this study is that Beer found the problem alone. Yes, it took a long time. Yes, most likely, nobody exploited the vulnerability. Given the relatively fast pace of installing updates on iPhone / iPad, attackers are unlikely to be able to exploit the bug even now. But there is a possibility that others could also get to the bottom of this vulnerability and exploit it for far from peaceful purposes. The article provides links to tweets proving that at least one other information security expert was aware of the problem discovered during the research and noticed that it was closed in a recent iOS release.
What else happened
The attack on the PickPoint checkpoint network on December 4 ( news , company message , discussion on Habré) became a rare (fortunately) clear example of hacking physical infrastructure. A detailed technical report on the methods of such attacks and how to defend against them is useful for the information security community. However, it is not a fact that we will wait for such a disclosure of data - companies are not obliged to do this, and only in the IT sphere, disclosure of information is considered "good form".
The vulnerability closed on April 6 in the Google Play Core Library (it is embedded in Android applications to interact with the Google online store) is still not closedin a variety of Android apps, including the mobile version of the Microsoft Edge browser. A Google store crawl showed that 13% of apps use this library. Of these, 8% never updated it after the patch was released.
More patches for vulnerabilities in Google Chrome. Closed three major holes in the browser, one of them in the V8 engine (CVE-2020-16040). Notably, this vulnerability can be exploited to escalate privileges under Linux.