There’s a new malware strain targeting MacOS, Silver Sparrow, and it’s unusual for a couple reasons. First, it’s one of the few pieces of malware that targets the new M1 ARM64 processors. Just a reminder, that is Apple’s new in-house silicon design. It’s unusual for a second reason — it’s not doing anything. More precisely, while researchers have been watching, the command and control infrastructure didn’t provide a payload. Silver Sparrow has been positively found on nearly 30,000 machines.

The malware also has an intentional kill switch, where the presence of a particular file triggers a complete removal of the malware package. Researchers at Red Canary point out that this package behaves very much like a legitimate program, difficult to pick out as malware. Ars Technica got an off-the-record statement from Apple, indicating that they are tracking the situation, and have revoked the developer’s certificate used to sign the malware. It’s not entirely clear whether this prevents the malware running on already compromised machines, or just stops new infections.

So who’s behind Silver Sparrow? The observed stealth mode and other complexities suggest that this is more than a simple adware or ransomware campaign. Since it was discovered before the payload was delivered, we may never know what the purpose is. It may have been a government created campaign, targeting something specific.

VMware RCE

The details of a VMware vulnerability were published this week, and the attack struck me as rather elegant. CVE-2021-21972 is a combination of two problems. The first is that the VMware web interface exposes an HTTP endpoint that doesn’t enforce user authentication. One of the functions of this endpoint is to allow the upload of an archive file, and extract this in the /tmp directory. The second problem is that the extraction function didn’t properly sanitize the names of the extracted files. Hence, it was possible to create an archive with a path transversal attack.

Here we have two very simple flaws, and when put together, allow a completely unauthenticated actor to easily get arbitrary code execution on the machine running VMware. The attack works on Linux and Windows servers, with expected implementation variations.

Inside a Wireless Security System

Ever wonder just how secure a residential security system is? [Nick Miles] and [Chris Lyne], a pair of researchers from Tenable, wondered the same thing, and decided to tear apart a SimpliSafe system, wringing out all of its secrets. They started with logic analyzers, and went as far as paying for functional decapping of the chips, to recover the firmware.

The step-by-step process is worth reading, but the conclusion is that the system is relatively well put together. Each device has an immutable AES key, and that represents an attack surface that wouldn’t be present with a more robust key exchange.

For the curious, [Nick] did a detailed analysis of a Ring system just a few months back.

Proper Exploit Attribution, The Story of Jian

I’ve been known to be a bit skeptical when an attack or exploit is attributed to a foreign nation, but no real evidence is presented. A story caught my eye this week, because it’s a wonderful example of what proper attribution looks like, not to mention a great example of unraveling a malware mystery. Check Point Research looked deep into an exploit used by APT31, believed to be a part of the Chinese government.

There are way too many details to dive into here, go read the post for the particulars, but we’ll cover the high points. Remember the Shadow Brokers leak, back in 2017? That was a collection of impressive 0-days that is universally recognized as produced by the Equation Group, part of the NSA. One of the tools exposed in that lead was “EpMe”, which leveraged CVE-2017-0005. Jian, an exploit produced by APT31 also targeted this CVE, and was probably created in 2014.

The kicker here is that Checkpoint makes a very convincing case that it was no accident that both exploits targeted the same CVE, but that the Chinese exploit was based on a captured sample of the NSA-produced tool. Essentially, they reverse-engineered the exploit and used it in their own operations, even before the tool was exposed by the Shadow Brokers.

Firefox State Partitioning

Mozilla has released a new privacy feature, State Partitioning, a way to authoritatively stop cookie-based tracking online. The concept is deceptively simple. Every domain you visit has its own “cookie jar”. Many websites have Facebook iframes or embedded images. State partitioning would isolate the cookies created by each of those iframes, meaning your browser is anonymous to Facebook on each of those sites.

Hand-in-hand is a new API that allows a website to request cross-site cookie access. This is important for the handful of uses where access is needed for legitimate uses, like Single Sign-On services. For now, partitioning is off by default, and can be turned on via the Enhanced Tracking Protection strict setting.

JSON Undefined Behavior

[Jake Miller] of Bishop Fox Labs wrote a great intro to a subject I’ve never considered: odd JSON constructions, and how different implementations handle them. An example will help.

obj = {"test": 1, "test": 2}

So what’s the value of obj["test"]? It’s complicated. Some JSON parsers will choose the first definition of a key, while others choose the last. Still others will throw an error in response. What makes this a particularly serious problem is that the same data may be parsed by different implementations in a single transaction. The example given in the post is of an online store, where the payment processing is handled by a third party.

The attack works by manipulating the JSON object sent by the browser, injecting a second value definition for the quantity of items purchased. The store itself sees the higher value, which determines the actual items shipped. The payment backend uses a different JSON parser, which sees the smaller value. The backend actually handles payment processing, so the amount charged is that of the smaller quantity.

The article goes on to describe issues with invalid unicode embedded in JSON and valid keypairs that have been /*commented out*/, and what happens when you re-serialize this quirky data. Another interesting edge case is the handling of very large numbers, where some parsers return 0, others return a null, and some an approximation in scientific notation.

All told, JSON deserialization is a mess. There’s sure to be many hard-to-spot bugs in web applications that use multiple parsers. The author makes a few recommendations at the end of the post. The most important is that parsers should produce a fatal error on particular quirky JSON input, rather than returning a guess at what data was intended.