This Week In Security: Robinhood, Apple Mail, ASLR, And More Windows 7

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.

Linux ASLR

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.

Data Collection

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.

10 thoughts on “This Week In Security: Robinhood, Apple Mail, ASLR, And More Windows 7

  1. So Microsoft fixes a black screen bug in Windows 7, but isn’t addressing a black screen bug *they created* with Windows 10 on many older laptops?

    It is in part apparently due to how they have (mis)handled driver security by essentially blacklisting all drivers not signed with the latest (and now only approved) method for Windows 8.x and 10 – unless those drivers were installed in Windows 10 build 1607 or previous and the install has been *upgraded* to a newer build.

    What that can get you is a laptop that works 100% perfectly until you upgrade to a build after 1607. It still works except MS has broken something with power management. Let the screen turn off *for any reason with any power settings* and when you wake it back up it has covered the entire screen in black, except the mouse pointer is visible.

    All you can do is mash the power button until it triggers shutting down and just before it initiates shutdown it whips the black away so for a fraction of a second the desktop is revealed. Then when you reboot you go to the power settings and disable, sleep, hibernate, and anything else that will turn the display off. From there you obsessively check Windows Update for any mention of including your laptop model series in fixes of this Microsoft introduced problem. They *have* addressed it for some models – but apparently have failed to figure WTF they Fed up on to issue a fix for all.

    It does seem to heavily afflict laptops with older discrete ATi GPUs that with build 1607 worked absolutely fine with Windows 7 or Vista video drivers.

    Fortunately when I encountered this it was on a laptop that wasn’t mine. I just had to explain in layman’s terms how Microsoft broke a thing while fixing another thing that really wasn’t broken. I did a restorable image backup with the 100% functional 1607 build then did an upgrade to 1903.

    As this article mentions, someone finally got around to suborning an old *network* driver. Seems far less likely anyone would bother (or could) to hack a *video* driver to sneak stuff in via a network connection.

    1. Many android apps in the play store have “AppsFlyer” integrated, which does the same thing. Logcat revealed to me that it was logging and then sending all app opening and “sent to background” times. I had multiple apps on my phone using it.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.