First off this week, a ransomware named Robinhood has a novel trick up its sleeve. The trick? Loading an old known-vulnerable signed driver, and then using a vulnerability in that driver to get a malicious kernel driver loaded.
A Gigabyte driver unintentionally exposed an interface that allows unfettered kernel level read and write access. Because it’s properly signed, Windows will happily load the driver. The ransomware code uses that interface to turn off the bit that enforces the loading of signed drivers only. From there, loading a malicious driver is trivial. Robinhood uses it’s kernel-level access to disable anti-virus applications before launching the data encryption.
This is a striking example of the weakness of binary signing without a mechanism to revoke those signatures. In an ideal world, once the vulnerability was found and an update released, the older, vulnerable driver would have its signature revoked.
The last Windows 7 Update For Real This Time, Maybe
More news in the ongoing saga of Windows 7/Server 2008 reaching end-of-life. KB4539602 was released this patch Tuesday, fixing the black background problem introduced in the last “final” round of updates. Surely that’s the last we’ll hear of this saga, right?
Not so fast. Apparently that patch has led to multiple Windows Server 2008 machines failing to boot after install. According to Microsoft, the problem is a missing previous patch that updates SHA-2 support.
Apple Mail Exposed Encrypted Emails
Back in November, [Bob Gendler] discovered something disconcerting about how Apple Mail handles encrypted emails. On MacOS, the suggestd service gathers snippets of emails and files, in an effort to more intelligently handle searches and Siri requests. The resulting dataset contains the plaintext of emails, even those that encrypted using GPG. He gave a set of workarounds, and notified Apple of the issue.
Just recently, Apple pushed 10.15.3, and buried in the change log is a note stating that encrypted emails will no longer appear in spotlight searches. [Bob] Did some further testing, and confirmed that the suggestd service now identifies encrypted messages, and deletes snippets taken from those messages immediately.
Gitlab’s GCP DeepDive
Curious about Google’s Cloud Platform, and how security considerations there differ from a more traditional environment? Gitlab did some research into GCP, and it turned into a step-by-step guide to exploring and compromising a GCP project.
There’s a bunch of basic information about GCP, as well as common mis-configurations that make for vulnerable instances. One of my favorites from the write-up: Follow the scripts. If you find a backup script, you not only have some credentials to work with, you also get a copy of the whole filesystem. The guide includes tips on moving to other VMs, as well as a possible path to compromising the whole Google Suite account.
Address Space Layout Randomization (ASLR) is a security enhancement that was added to the Linux kernel in 2005. It randomizes the memory layout of userspace programs, in an effort to make actual compromise harder to achieve. If you have a buffer overflow, for example, how do you write an exploit when the memory layout is different every time a program is run?
The guys over at Wildfire Labs took a look at Linux ASLR, and concluded that it’s still lacking. The main problem is the information available in “/proc/[pid]/*”, and the way security checks are done on those virtual files. The most straightforward example is “/proc/[pid]/maps”, which contains the randomized memory layout. As disclosed in mid-2019, this virtual file would do a permissions check when another application attempted to read its contents, but not when attempting to simply open the file. In practice, this means a non-root application can obtain a file descriptor pointing at the “maps” virtual file, and pass that descriptor to another application. If passed to a setuid root application, the protected information can be freely read, and potentially leaked back to the unprivileged application.
“Setuid root” is worth an aside to explain. Ping is the perfect example: It’s reasonable to allow a non-root user to use the ping command to test network connectivity. Sending an ICMP packet requires a raw socket, which in turn requires root privileges. How do we securely allow a non-root user to access this function? Setuid is a special file permission for executables, that allows the executable to run as root, regardless of the user that launches it. As you can imagine, it takes a lot of care to avoid local exploits in setuid binaries.
While the permissions bypass in the maps virtual file was fixed, the fix wasn’t applied to the rest of the nodes in the /proc structure. The novelty of the Wildfire work is that they found other nodes that can be similarly abused, to retrieve the mapping information. There seems to be some disagreement with kernel devs about whether current mitigations are sufficient, but with a proof of concept published, it’s sure to get sorted soon.
Last up this week is news about way too much data being collected by a Wacom tablet driver. Look forward to a dedicated article from our own Kristina Panos, taking a closer look at this story, and the techniques used to figure out exactly what was going on.