This Week In Security: In The Wild, Through Your NAT, And Brave

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:

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.

12 thoughts on “This Week In Security: In The Wild, Through Your NAT, And Brave

  1. Anywhere I’ve seen BMC’s used, they typically have a dedicated management VLAN (using non routable ip addresses), a dedicated backup/restore VLAN (using a different block of non routable ip addresses), and dedicated firewalled intranet server VLAN(s) with NIC failover Bonding/Teaming.

  2. Like many other technology resources, BMCs have a role and are of big importance in some situations. They just need to be configured right, like many other technological things.

    Also, from the title of the article, I somehow thought it would say soomething about the Brave browser …

  3. I’m sure I’m not the first to think while reading these articles, how disappointing it is that so many vulnerabilities are based on data entry that isn’t validated for length, range, etc. I’m not a pro, but shouldn’t the developers have code writing requirements that prohibit that?

    1. You’re not wrong. The problem is how many ways that can break. Like the Windows Kernel example from this week. The code checks those lengths, but a different looked-over bug invalidates the checks.

  4. “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.]”

    It’s abandoned closed-source software as well.. About 20% of the world still use win 7 – many don’t want the bloat and phone home of win 10, not to mention the mandatory updates that regularly break the machine (my sons has been down the last 24 hours because of an update..) – yet Microsoft won’t do security updates..

    In the long term most companies that treat their customers with contempt have problems, let’s hope that happens to microsoft..

    1. Calibre 5.0 and above will only install on Windows 8, or 10, so it’s not only closed-source software that’s the problem. Any open-source on the Windows platform that requires 8, or 10 is part of the problem.

  5. Microcode is not nearly so essential. Indeed, IBM’s POWER mainframe CPUs have absolutely none, with all of their instruction decoders being hard-wired and very directly expressed logic gates. It’s actually relatively uncommon for microcode to appear in RISC-style architectures.

    Indeed, the first microcode to be used in a superscalar CISC x86 CPU (the AMD K5, predating the Pentium pro) was in fact the assembly language of another CPU architecture, the RISC AM29K from AMD. To create their first in-house CPU, AMD simply bolted an x86 instruction translator on the front and beefed up the floating point unit. It was a flop, but it built crucial design capability for the very successful K6.

    In the modern day, inefficient CISC designs like x86 are vitally dependant on having a RISC internal structure for it’s efficiency. It’s the sole reason clock speeds on x86 chips have reached as high as they have.

    It’s been this way ever since the RISC revolution started by Berkeley RISC (of which POWER and SPARC are direct descendants) killed off the old VAX iron and spawned a plethora of RISK projects. Soon it became the latest fad to have an in-house RISC architecture, which is where POWER, SPARC, Alpha, MIPS, ARM, AM29K and many more came from. Intel’s cheap 8088 chips only survived and outlasted many of those because of their low cost and huge adoption in IBM PCs.

    There’s some rule in technology about the shittiest workable solution always being the one to win out.

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.