This Week in Security

250 Articles

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

February 28, 2025 by 11 Comments

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

February 21, 2025 by 7 Comments

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

February 14, 2025 by 15 Comments

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

February 7, 2025 by 12 Comments

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

January 31, 2025 by 8 Comments

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” →

This Week In Security: ClamAV, The AMD Leak, And The Unencrypted Power Grid

January 24, 2025 by 10 Comments

Cisco’s ClamAV has a heap-based buffer overflow in its OLE2 file scanning. That’s a big deal, because ClamAV is used to scan file attachments on incoming emails. All it takes to trigger the vulnerability is to send a malicious file through an email system that uses ClamAV.

The exact vulnerability is a string termination check that can fail to trigger, leading to a buffer over-read. That’s a lot better than a buffer overflow while writing to memory. That detail is why this vulnerability is strictly a Denial of Service problem. The memory read results in process termination, presumably a segfault for reading protected memory. There are Proof of Concepts (PoCs) available, but so far no reports of the vulnerability being used in the wild.
Continue reading “This Week In Security: ClamAV, The AMD Leak, And The Unencrypted Power Grid” →

This Week In Security: Rsync, SSO, And Pentesting Mushrooms

January 17, 2025 by 14 Comments

Up first, go check your machines for the rsync version, and your servers for an exposed rsync instance. While there are some security fixes for clients in release 3.4.0, the buffer overflow in the server-side rsync daemon is the definite standout. The disclosure text includes this bit of nightmare fuel: “an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.”

A naive search on Shodan shows a whopping 664,955 results for rsync servers on the Internet. Red Hat’s analysis gives us a bit more information. The checksum length is specified by the remote client, and an invalid length isn’t properly rejected by the server. The effect is that an attacker can write up to 48 bytes into the heap beyond the normal checksum buffer space. The particularly dangerous case is also the default: anonymous access for file retrieval. Red Hat has not identified a mitigation beyond blocking access.

If you run servers or forward ports, it’s time to look at ports 873 and 8873 for anything listening. And since that’s not the only problem fixed, it’s really just time to update to rsync 3.4.0 everywhere you can. While there aren’t any reports of this being exploited in the wild, it seems like attempts are inevitable. As rsync is sometimes used in embedded systems and shipped as part of appliances, this particular bug threatens to have quite the long tail. Continue reading “This Week In Security: Rsync, SSO, And Pentesting Mushrooms” →