This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

Continue reading “This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE”

This Week In Security: Zen Jailbreak, Telegram Exploit, And VMware Hyperjack

The fine researchers at Google have released the juicy details on EntrySign, the AMD Zen microcode issue we first covered about a month ago. And to give away the punchline: cryptography is hard. It’s hard in lots of ways, but the AMD problem here is all about keeping track of the guarantees provided by cryptographic primitives.
Continue reading “This Week In Security: Zen Jailbreak, Telegram Exploit, And VMware Hyperjack”

This Week In Security: Malicious Themes, Crypto Heists, And Wallbleed

It’s usually not a good sign when your downloaded theme contains obfuscated code. Yes, we’re talking about the very popular Material Theme for VSCode. This one has a bit of a convoluted history. One of the authors wanted to make some money from all those downloads. The original Material Theme was yanked from the VSCode store, the source code (improperly) re-licensed as closed source, and replaced with freemium versions. And this week, those freemium versions have been pulled by Microsoft for containing malware.
Continue reading “This Week In Security: Malicious Themes, Crypto Heists, And Wallbleed”

This Week In Security: OpenSSH, JumbledPath, And RANsacked

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.

The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.

Continue reading “This Week In Security: OpenSSH, JumbledPath, And RANsacked”

This Week In Security: The UK Wants Your ICloud, Libarchive Wasn’t Ready, And AWS

There’s a constant tension between governments looking for easier ways to catch criminals, companies looking to actually protect their users’ privacy, and individuals who just want their data to be truly private. The UK government has issued an order that threatens to drastically change this landscape, at least when it comes to Apple’s iCloud backups. The order was issued in secret, and instructed Apple to provide a capability for the UK officials to access iCloud backups that use the Advanced Data Protection (ADP) system. ADP is Apple’s relatively new end-to-end encryption scheme that users can opt-into to make their backups more secure. The key feature here is that with ADP turned on, Apple themselves don’t have access to decrypted user data.

If this order wasn’t onerous enough, it seems to explicitly include all ADP-protected data, regardless of the country of origin. This should ring alarm bells. The UK government is attempting to force a US company to add an encryption backdoor to give them access to US customer data. Cryptographer [Matthew Green] has thoughts on this situation. One of the slightly conspiratorial theories he entertains is that portions of the US government are quietly encouraging this new order because the UK has weaker protections against unreasonable search and seizure of data. The implication here is that those elements in the US would use this newfound UK data access capability to sidestep Fourth Amendment protections of citizens’ data. This doesn’t seem like much of a stretch.

[Matthew] does have a couple of suggestions. The first is passing laws that would make it illegal for a US company to add backdoors to their systems, specifically at the request of foreign nations. We’ve seen first-hand how such backdoors can backfire once accessed by less-friendly forces. In an ironic turn of fate, US agencies have even started recommending that users use end-to-end encrypted services to be safe against such backdoors. Technically, if this capability is added, the only recourse will be to disable iCloud backups altogether. Thankfully Apple has pushed back rather forcefully against this order, threatening to simply turn off ADP for UK users, rather than backdoor the rest of the world. Either way, it’s a scary bit of overreach.

Continue reading “This Week In Security: The UK Wants Your ICloud, Libarchive Wasn’t Ready, And AWS”

This Week In Security: Medical Backdoors, Strings, And Changes At Let’s Encrypt

There are some interesting questions afoot, with the news that the Contec CMS8000 medical monitoring system has a backdoor. And this isn’t the normal debug port accidentally left in the firmware. The CISA PDF has all the details, and it’s weird. The device firmware attempts to mount an NFS share from an IP address owned by an undisclosed university. If that mount command succeeds, binary files would be copied to the local filesystem and executed.

Additionally, the firmware sends patient and sensor data to this same hard-coded IP address. This backdoor also includes a system call to enable the eth0 network before attempting to access the hardcoded IP address, meaning that simply disabling the Ethernet connection in the device options is not sufficient to prevent the backdoor from triggering. This is a stark reminder that in the firmware world, workarounds and mitigations are often inadequate. For instance, you could set the gateway address to a bogus value, but a slightly more sophisticated firmware could trivially enable a bridge or alias approach, completely bypassing those settings. There is no fix at this time, and the guidance is pretty straightforward — unplug the affected devices.

Continue reading “This Week In Security: Medical Backdoors, Strings, And Changes At Let’s Encrypt”

This Week In Security: DeepSeek’s Oopsie, AI Tarpits, And Apple’s Leaks

DeepSeek has captured the world’s attention this week, with an unexpected release of the more-open AI model from China, for a reported mere $5 million training cost. While there’s lots of buzz about DeepSeek, here we’re interested in security. And DeepSeek has made waves there, in the form of a ClickHouse database unintentionally opened to the world, discovered by the folks from Wiz research. That database contained chat history and log streams, and API keys and other secrets by extension.

Finding this database wasn’t exactly rocket science — it reminds me of my biggest bug bounty win, which was little more than running a traceroute and a port scan. In this case it was domain and sub domain mapping, and a port scan. The trick here was knowing to try this, and then understanding what the open ports represented. And the ClickHouse database was completely accessible, leaking all sorts of sensitive data. Continue reading “This Week In Security: DeepSeek’s Oopsie, AI Tarpits, And Apple’s Leaks”