Security Week 34: extraordinary vulnerabilities in Windows

On August 13, Microsoft released the next security update (review news ) for Windows operating systems and office programs, and this time the patch turned out to be really gigantic: someone obviously was not able to go on vacation this summer. In total, 93 vulnerabilities were closed, of which 23 were classified as critical. Serious bugs were closed in Remote Desktop Services, in the DHCP client, in the .LNK file handler , two vulnerabilities in Hyper-V with a sandbox escape.



So monumental work on the bugs is very good news. Among other things, several vulnerabilities are interesting in themselves, and another has an interesting history of detection. In addition to the problems already mentioned in Remote Desktop Services, today we will take a closer look at the vulnerability in the MSCTF service. Researcher Tavis Ormandy of Google Project Zero, who discovered the latter, claims that the problem has existed for 20 years. Well, at the same time, we will evaluate the vulnerability in Bluetooth, which affects not only Windows.

WTF is CTF?

A vulnerability in the MSCTF service was discovered by Tavis Ormandi almost by accident ( news , Tavis's blog post). It all started with the study of Windows mechanisms that allow different programs to interact with each other. This interaction is limited to the User Interface Privilege Isolation system, which prevents, for example, user processes from interfering with system processes. Studying strange cases when, despite the restrictions, messages still passed, Tavis stumbled upon the MSCTF module.



This module belongs to the Text Services Framework, which in turn controls keyboard layouts and the like. All running applications are connected to it. What for? Well, for example, to facilitate the process of entering text in Chinese or Japanese.









For such languages, a separate program processes the input in the application window and changes the input to hieroglyphs. In fact, MSCTF is a separate channel of communication between applications, which, as it turned out, is not sufficiently protected. The earliest version of MSCTF that Tavis managed to find is part of the Microsoft Office XP office suite, which is compatible with Windows 98. Starting with Windows XP, MSCTF is part of the operating system. The possibilities of interacting with other applications through MSCTF are very wide, and most importantly - there is no authorization. As a result, Tavis wrote a utility for working with CTF and began searching for vulnerabilities:









Vulnerabilities, though not immediately, were found. In the “best” case, on a system with one of the languages ​​that require advanced input tools (Japanese, Chinese, Korean, and some others), you can replace text in the application, send commands to the console with administrator rights, without being a privileged user, or steal user passwords. In the worst (though the above is already bad enough) you can get system rights, that is, increase your privileges to the maximum. Such a Proof of Concept is shown in the video:





The vulnerability is of limited use, and most likely, most scenarios are available only with access to the system. Nevertheless, there are potential options when a user without privileges gets, say, domain administrator rights in an enterprise. The vulnerability is closed by the August update for all OSs starting with Windows 7.

Bluekeep or not Bluekeep

Problems in Remote Desktop Services ( news , a newsletter on Microsoft) are partly similar to the vulnerability discovered in May this year by Bluekeep . Holes in the remote access service (but not in the RDP protocol itself) theoretically allow the attack to be distributed to all computers on the network without user intervention: there is a certain risk of a repetition of the situation with the WannaCry crypto encryptor in 2017, when the problem of implementing the SMB protocol was exploited on a large scale.



However, there are differences from BlueKeep. An earlier problem did not apply to the latest OS versions, but now, on the contrary, it affects all OSs from Windows 7 to Windows 10 (but not Windows XP, Server 2003 and 2008). Bugs were identified during the internal audit of Microsoft, real attacks have not yet been noticed. Both Bluekeep and four new issues are neutralized by the inclusion of Network Level Authorization. But NLA on an unpatched system does not completely save you from a number of scripts for executing code on a remote machine. In the worst case (no NLA, August patch not installed, remote access enabled), it becomes possible to bypass authorization and gain control of the system by sending a prepared request.

Bluetooth Vulnerability

The problem, known as KNOB Attack (Key Negotiation of Bluetooth), was discovered by researchers from Singapore, Germany and the UK ( news , research site , scientific work ). Unlike other vulnerabilities in the Microsoft patch set, this applies not only to Windows, but is generally relevant almost everywhere where Bluetooth is used. A large list of updates from manufacturers of smartphones, laptops, IP phones that have responded to the problem is here .



In the Bluetooth specifications, two devices that establish a secure connection between themselves can select a key length between 1 and 16 bytes. In the case of an “eight-bit” key, it can be cracked quickly enough by simple enumeration: if such a “slightly secure” connection is established for some reason, the attacker can decrypt the data exchange. For example, between a keyboard and a desktop computer. The question is how to implement such an attack, and research work proves that there are at least two moderately realistic options.









In the first case, an attacker located near two victims can force them to use encryption with a key length of 1 byte. The fact is that during the process of establishing a connection there is no encryption or even data integrity control. In the second case, the scenario of an attack on the supply chain was investigated: replacing the device firmware provides weak encryption in all cases. The second attack was carried out on a Nexus 5 phone: we change a few bytes in the firmware, limit the key length, connect to another smartphone that has to accept the conditions for establishing a connection.



This is a serious vulnerability that exists due to the initially weak specifications of the Bluetooth standard. In addition, many devices will continue to be subject to a KNOB attack, as they simply won’t release an update. On the other hand, the implementation of such a scenario is rather complicated in practice: in the first case it is necessary to be close to the victim at the right time, in the second - to intervene in the supply chain and then, again, be near the attacked device when confidential data is transmitted through it. In all cases, the patch sets the minimum key length so that the attack becomes practically inapplicable.



Disclaimer: The opinions expressed in this digest may not always coincide with the official position of Kaspersky Lab. Dear editors generally recommend treating any opinions with healthy skepticism.