Vulnerability in Microsoft CTF protocol goes back to Windows XP

[steven36]

Insecure CTF protocol allows hackers to hijack any Windows app, escape sandboxes, get admin rights.

 

 

 

CTF, a little-known Microsoft protocol used by all Windows operating system versions since Windows XP, is insecure and can be exploited with ease.

 

According to Tavis Ormandy, a security researcher with Google's Project Zero elite security team and the one who discovered the buggy protocol, hackers or malware that already have a foothold on a user's computer can use the protocol to take over any app, high-privileged applications, or the entire OS, as a whole.

What is CTF?

What CTF stands is currently unknown. Even Ormandy, a well-known security researchers wasn't able to find what it means in all of Microsoft documentation.

 

What Ormandy found out was that CTF is part of of the Windows Text Services Framework (TSF), the system that manages the text shown inside Windows and Windows applications.

 

When users start an app, Windows also starts a CTF client for that app. The CTF client receives instructions from a CTF server about the OS system language and the keyboard input methods.

 

If the OS input method changes from one language to another, then the CTF server notifies all CTF clients, who then change the language in each Windows app accordingly, and in real-time.

CTF, the gateway to... everything

What Ormandy discovered is that the communications between CTF clients and the CTF servers aren't properly authenticated or secured.

 

 

"There is no access control in CTF," Ormandy said.

 

"Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie.

 

"So you could connect to another user's active session and take over any application, or wait for an Administrator to login and compromise their session."

 

An attacker that hijacks another app's CTF session can then send commands to that app, posing as the server -- normally expected to be the Windows OS.

 

Attackers can use this loophole to either steal data from other apps, or they can use it to issue commands in the name of those apps.

 

If the apps run with high-privileges, then those actions can even allow the attacker to take full control over a victim's computer.

 

And according to Ormandy, any app or Windows process is up for grabs. Because of CTF's role -- to show text inside ANY app or service -- there's a CTF session for literally everything and every user interface element on a Windows OS.

 

To prove this point, Ormandy recorded a demo in which he hijacked the CTF session of the Windows login screen, showing that everything is hackable in Windows because of CTF.

 

 

 

CTF hacking tool available online

Furthermore, earlier today, Ormandy also published a blog post explaining the CTF security issue in more depth, but also released a tool on GitHub that helps other researchers in testing the protocol for other issues.

 

It is unclear how Microsoft will patch the CTF problem. And this is a very big problem. The vulnerability may not allow hackers to break into computers, but it allows them one very easy way of getting admin rights on infected Windows systems.

 

For its part, Microsoft told ZDNet they patched the bug Ormandy reported this month. The CTF protocol vulnerability and fixes are tracked as CVE-2019-1162.

 

But as the vulnerability are deeply ingrained in the protocol and its design, it will remain to be seen if patches Microsoft released today as part of the August 2019 Patch Tuesday are enough.

 

"It will be interesting to see how Microsoft decides to modernize the protocol," Ormandy wondered.

 

Article updated on August 13, at 4:05pm, with information on patches.

 

Source

[Karlston]

A look at the Windows 10 exploit Google Zero disclosed this week

This privilege escalation vulnerability has lurked within Windows for 20 years.

 

On Tuesday, Tavis Ormandy of Google's Project Zero released an exploit kit called ctftool, which uses and abuses Microsoft's Text Services Framework in ways that can effectively get anyone root—er, system that is—on any unpatched Windows 10 system they're able to log in to. The patches for this vulnerability—along with several other serious issues—went out in this week's Patch Tuesday update.

 

We independently verified Ormandy's proof-of-concept, and it's precisely what it says on the tin: follow the directions and you get an nt authority\system privileged command prompt a few seconds later. We also independently verified that applying KB4512508 closed the vulnerability. After applying the August security updates, the exploit no longer works.

 

The full writeup of Ormandy's findings is fascinating and incredibly technically detailed. The TL;DR version is that Microsoft's Text Services Framework, which is used to provide multilingual support and has been in place since Windows XP, includes a library called MSCTF.DLL. (There's no clear documentation demonstrating what Microsoft intended CTF to stand for, but with the release of this tool, it might as well stand for Capture The Flag.)

 

 

The Text Services Framework needs to monitor—and alter—user input to application windows in order to provide language services such as Simplified Chinese (Pinyin). If you install language support for Pinyin, you can see this in action. With language set to Pinyin, you can type in any window and suggestions for Chinese characters that can match either your phonetic typing (or entire words you've typed in English) will appear in a sub-menu.

 

The characters in this sub-menu can be rapidly selected with keyboard shortcuts, which will then replace what you typed with the Chinese characters you selected.

 

Ormandy didn't start out looking for problems in the Text Services Framework—all he was really looking for was confirmation that he couldn't send inter-process messages from an unprivileged process to a privileged process. But when he wrote a test case to send all possible messages to a Notepad.exe instance running as Administrator, he discovered that wasn't the case: some of his inter-process messages unexpectedly went through.

If I send every possible message to a privileged window from an unprivileged process, the list should match the whitelist in win32k!IsMessageAlwaysAllowedAcrossIL and I can move onto something else.

 

Ah, I was so naive.

Tavis Ormandy, Google Project Zero

Once Ormandy identified the culprit as MSCTF.DLL, the next step was figuring out what could be done with it. As he discovered, the answer was "pretty much anything you'd like." The CTF protocol is a legacy system dating back to 2001's Office XP, which even included support for Windows 98; it was available with the base system beginning with Windows XP itself. There was no access control at all implemented in the protocol—even sandboxed processes could connect to a CTF session outside their sandbox. Clients report their thread ID, process ID, and window handle—but there was no verification and nothing stopping such a client from lying through its teeth to get what it wants.

 

Making things worse, the CTF protocol allowed a client to call any function pointer in the program it's referencing... and the CTF protocol catches exceptions. So a client could effectively just keep attacking a target it didn't know much about without causing it to crash. You might think that Address Space Layout Randomization—a modern security technique that makes predicting where vulnerable parts of an application reside in memory more challenging—would make things more difficult. Unfortunately, you'd be wrong, because as it turns out the CTF marshaling protocol informed you where the monitor's stack is located.

 

This would get you into the monitor but wouldn't yet get you into the client app you actually wanted to own. That process does require repeated trial and error, but that trial and error can be automated in a script. This is exactly what Ormandy's proof-of-concept script did. When you run ctf-consent-system.ctf in the tool, it spawns a UAC dialog by using the runAs verb with a ShellExecute() command. Once the UAC dialog is present, ctftool uses the CTF framework to connect to it, probe it, and map its stack, which takes a few seconds. Once that's done, it calls the internal function in consent.exe. This indicates that a local user has successfully entered the requested credentials—and Bob's your uncle; you've got an instance of cmd.exe running as nt authority\system.

We stepped through Tavis Ormandy's demonstration use of ctftool. Yep, system privileges in seconds; no fuss, no muss. We did not have any extra languages installed or any non-default settings; this was a brand-new Windows 10 build 1903 VM. (We did need to install the Microsoft Visual C x86 runtime, but that will already be present on nearly any real-world system.)

 

This vulnerability lurked unacknowledged in the Windows stack for 20 years, and the consequences were even farther reaching than the proof-of-concept exploit—CTF can even be used on unpatched systems to bypass AppContainer Isolation used in the newest and supposedly most securely designed applications, such as Microsoft Edge.

 

Listing image by Rich Graessle/Icon Sportswire/Corbis via Getty Images

 

 

 

Source: A look at the Windows 10 exploit Google Zero disclosed this week (Ars Technica)

 

(To view the article's image galleries, please visit the above link)