Discord had a data breach back on September 20th, via an outsourced support contractor. It seems it was a Zendesk instance that was accessed for 58 hours through a compromised contractor user account. There have been numbers thrown around from groups claiming to be behind the breach, like 1.6 Terabytes of data downloaded, 5.5 million user affected, and 2.1 million photos of IDs.

Discord has pushed back on those numbers, stating that it’s about 70,000 IDs that were leaked, with no comments on the other claims. To their credit, Discord has steadfastly refused to pay any ransom. There’s an interesting question here: why were Discord users’ government issued IDs on record with their accounts?

The answer is fairly simple: legal compliance. Governments around the world are beginning to require age verification from users. This often takes the form of a scan of valid ID, or even taking a picture of the user while holding the ID. There are many arguments about whether this is a good or bad development for the web, but it looks like ID age verification is going to be around for a while, and it’ll make data breaches more serious.

In similar news, Salesforce has announced that they won’t be paying any ransoms to the group behind the compromise of 39 different Salesforce customers. This campaign was performed by calling companies that use the Salesforce platform, and convincing the target to install a malicious app inside their Saleforce instance.

Unity

[RyotaK] from Flatt Security found an issue in the Unity game engine, where an intent could influence the command line arguments used to launch the Unity runtime. So what’s an intent?

On Android, an Intent is an object sent between applications indicating an intention. It’s an intra-process messaging scheme. So the problem here is that when sending an intent to a Unity application on Android, a command line option can be included as an extra option. One of those command line options allows loading a local library by name. Since a malicious library load results in arbitrary code execution, this seems like a pretty big problem.

At first it seems that this doesn’t gain an attacker much. Doesn’t a malicious app already need to be running on the device to send a malicious intent? The reality is that it’s often possible to manipulate an innocent app into sending intents, and the browser is no exception. The bigger problem is that a malicious library must first be loaded into a location from which the Unity app can execute. It’s a reasonably narrow window for practical exploitation, but was still scores an 8.4 severity. Unity has released fixes for versions all the way back to 2019.1.

Code Smell: Perl?

We have two stories from WatchTwr, packed full of the sardonic wit we have to expect from these write-ups. The first is about Dell’s UnityVSA, a Virtual Storage Appliance that recently received a whole slew of security fixes for CVEs. So WatchTowr researchers took a look at the patch set from those fixes, looking for code smell, and found… Perl?

Turns out it wasn’t the presence of Perl that was considered bad code smell, though I’m sure some would argue that point. It was the $exec_cmd variable that wasn’t escaped, and Perl backticks were used to execute that string on the system. Was there a way to inject arbitrary bash commands into that string? Naturally, there is. And it’s a reasonably simple HTTP query to run a command. A security advisory and updated release was published by Dell at the end of July, fixing this issue.

Poetic Flow of Vulnerabilities

There’s an active exploitation campaign being waged against Oracle E-Business Suite instances, using a zero-day vulnerability. This exploit works over the network, without authentication, and allows Remote Code Execution (RCE). It appears that a threat group known as Graceful Spider, another great name, is behind the exploitation.

The folks at WatchTowr got their hands on a Proof of Concept, and have reverse engineered it for our edification. It turns out it’s a chain of little weaknesses that add up to something significant.

It starts with a Server-Side Request Forgery (SSRF), a weakness where a remote service can be manipulated into sending an additional HTTP request on to another URL. This is made more significant by the injection of a Carriage Return/Line Feed (CRLF) attack, that allows injecting additional HTTP headers.

Another quirk of the PoC is that it uses HTTP keep-alive to send all of the malicious traffic down a single HTTP session. And the actual authentication bypass is painfully classic. A /help path doesn’t require authentication, and there is no path traversal protection. So the SSRF connection is launched using this /help/../ pattern, bypassing authentication and landing at a vulnerable .jsp endpoint.

That endpoint assembles a URL using the Host: header from the incoming connection, and fetches and parses it as an eXtensible Stylesheet Language (XSL) document. And XSL documents are unsafe to load from untrusted sources, because they can lead directly to code execution. It’s a wild ride, and a great example of how multiple small issues can stack up to be quite significant when put together.

Bits and Bytes

Caesar Creek Software did an audit on a personal medical device and found issues, but because fixes are still being reviewed by the FDA, we don’t get many details on what exactly this is. Reading between the lines, it sounds like a wearable glucose monitor. It’s based on the nRF52 platform, and the best bit of this research may be using power line fault injection to get Single Wire Debug access to the MCU. They also found what appears to be a remote leak of uninitialized memory, and a Bluetooth Low Energy Man in the Middle attack. Interesting stuff.

And finally, [LaurieWired] has a great intro to the problem of trusting trust with a bit of bonus material on how to build and obfuscate quines while at it. How do you know your compiler binary doesn’t have malware in it? And how do you establish trust again? Enjoy!