Most of the stories from this week are vulnerabilities dropped before fixes are available, many of them actively being exploited. Strap yourselves in!

Windows Kernel Crypto

The first is CVE-2020-17087, an issue in the Windows Kernel Cryptography Driver. The vulnerable system calls are accessible from unprivileged user-space, and potentially even from inside sandboxed environments. The resulting buffer overflow can result in arbitrary code executing in the kernel context, meaning this is a quick jump to root-level control over a victim system.

What exactly is the code flaw here that’s being attacked? It’s in a bit of buffer allocation logic, inside a binary-to-hex conversion routine. The function accepts an unsigned short length argument. That value is used to calculate the output buffer size, by multiplying it by six, and using an unsigned short to hold that value. See the problem? A sufficiently large value will roll over, and the output buffer size will be too small. It’s a value overflow that leads to a buffer overflow.

Because the problem is being actively exploited, the report has been made public just seven days after discovery. The flaw is still unpatched in Windows 10, as of the time of writing. It also seems to be present as far back as Windows 7, which will likely not receive a fix, being out of support. [Editor’s snarky note: Thanks, closed-source software.]

Intel Key Extraction

Microcode has been a part of CPU architecture for decades. From a certain point of view, processors have always had some sort of microcode — logic that converts instructions into discrete hardware operations. Microcode, as we think of it today, came to x86 processors with the Pentium Pro. With that processor, it was finally possible to update the microcode layer at boot, fixing bugs and problems that were found after manufacture. Intel has always distributed that microcode as an encrypted blob, keeping researchers from investigating the changes between updates. That restriction may be lifted, as a trio of researchers have managed to extract the encryption key from modern Intel CPUs.

The extraction is possible because of a vulnerability allowing access to a debug interface inside Intel chips. This technique requires physical access to the machine, and the chip resets to its factory state on a power cycle. Time will tell what other interesting tidbits will be mined from the hidden depths of Intel processors. Keep an eye on the Chip Red Pill repository for their ongoing work.

Oracle In the Wild

Two separate attacks are being actively used against Oracle products. The first is CVE-2020-14882 in Weblogic, a pre-auth RCE that just requires a single HTTP GET to trigger. This was patched in the latest set of security updates, and quickly reverse engineered. (That’s written in Vietnamese. Google translate does well enough to follow along.)

The second attack is CVE-2020-14871, a PAM vulnerability in Oracle’s Solaris. This was a true zero-day, being exploited for months before it was fixed in the same set of security updates. FireEye was the company that originally found the attack, and have been kind enough to explain it. The Pluggable Authentication Module (PAM) has a maximum response size, and uses that size to construct a buffer to hold incoming requests. The Solaris code fails to do any checks on the request, and just naively copies the string into the buffer, right past the end, if the input string is too long.

Now where do you think we could manipulate the input message for a PAM request? How about the Secure SHell Daemon? Yep, make an SSH request in keyboard-interactive mode, and use a username longer than 512 characters. In a simple test, PAM just crashes, but it’s possible to manipulate the username to compromise the machine instead.

This is a worst-case scenario. The default configuration of Solaris’ SSHD daemon was vulnerable to a simple compromise. All it takes is SSH exposed to the internet, and your machine probably got compromised. It does appear that using an SSH key, and disabling all the other SSH login methods would mitigate this vulnerability, particularly if you go so far as disabling SSH PAM altogether. This vulnerability is also present in OpenIndiana as well. 2020.10 should contain the fixes, but I can’t find any information about the previous release, 2020.04 being patched. Caveat Emptor.

Beware The BMC

I’ve always looked upon Baseboard Management Controllers (BMCs) with great skepticism. Yes, it’s incredibly useful to have a way to access a remote computer’s BIOS interface. A BMC can even be used to do a remote reinstall of the entire OS. For a machine locked away in a remote datacenter, a BMC can be a life-saver.

That BMC is also a second OS running on your hardware, that you don’t control. I’ve never been comfortable connecting that black-box OS to the internet. I have a pair of servers, and I used a secondary Ethernet port on each server to cross-connect from each server into the other’s BMC port. I can SSH in and access the interface, while keeping the BMCs completely isolated. It turns out, my paranoia is entirely justified. This article is specific to an NVIDIA SCADA system, but at least some of these vulnerabilities are present in other iterations of this BMC system. The worst offender is CVE‑2020‑11483, hardcoded credentials. This sort of bug is usually a debugging account that someone forgot to disable before shipping the firmware, it still represents a major backdoor into any system running this BMC. The old adage is still relevant: Don’t connect it to the internet!

Google’s Project Zero Details GitHub Vulnerability

Project Zero has published the details of a flaw in GitHub’s Actions system. You’ve probably interacted with Actions — when a project automatically runs a test suite on pull requests, or copies new bug reports to other repositories, it’s Actions under the hood. The vulnerability is command injection. The Project Zero bug report points out the set-env command as the most troubling, and since their PoC includes arguments being sent to the underlying Node server, I’m inclined to agree.

The political angle here is interesting too. GitHub asked for a disclosure extension at the 11th hour, 103 days after receiving the report. In their defense on October 1st, GitHub did publish an advisory disclosing essentially everything but PoC code. This just happens to be one of those security problems that happens to also be a feature for some users. If you manage a GitHub project that uses Actions, it’s probably worth taking some time to make sure you aren’t vulnerable to command injection.

Slipstreaming Through NAT

NAT, love it or hate it, has been part of our networks for years now. Regardless of whether it’s really a firewall or not, I agree with Robert Graham’s opinion:

Of all the security features out there, the #1 thing that stops the most cyberattacks/hackers every day is … NAT.

— Robᵉʳᵗ Graham😷, provocateur (@ErrataRob) May 14, 2019

To shake things up a bit, enter Slipstream, a very clever attack against NAT routers that support connection tracking. You may have seen this in iptables, in the RELATED keyword. SIP is a notable example of why connection tracking is useful. You pick up the phone on your desk, and dial a number. That phone opens a SIP control connection, and issues INVITEs to set up the conversation with your SIP provider. The INVITE information includes the details on the actual audio connection. Usually this is shuffled off to a high level UDP port. A headache-inducing problem for SIP providers is that NAT will block those audio connections. The solution is to include a conntrack module in the firewall that can read those INVITE messages and correctly forward the audio traffic.

This is the mechanism that Slipstream abuses. Your browser cannot generate a SIP INVITE packet, but it can send HTTP GET messages to 5060, the normal SIP port. Is there a way an attacker could generate HTTP traffic that would confuse the CONNTRACK module? The answer is yes, but it’s difficult.

To effectively fool the NAT router, Slipstream gathers data on the given network, and generates large packets that will fragment in transit. By padding the front of those packets, and aligning the fragmentation point at the start of the spoofed SIP data, a malicious site can indeed fool many NAT routers on the market today. The result is that by connecting to a malicious server, and running the JavaScript hosted there, the machine running the browser is exposed to the attacking server, as if it was no longer behind the NAT router at all. All-in-all it’s a very clever technique, but time will tell whether it ever gets used for attacks in the wild. For now, it’s just a reminder that defense-in-depth is the way to go.