It’s a bit of bitter irony, when a security product gets used maliciously, to pull off the exact attack it was designed to prevent. Enter Proofpoint, and the EchoSpoofing attack. Proofpoint offers an email security product, filtering spam and malicious incoming emails, and also handling SPF, DKIM, and DMARC headers on outgoing email. How does an external service provide those email authentication headers?

One of the cardinal sins of running an email server is to allow open relaying. That’s when anyone can forward email though an SMTP server without authentication. What we have here is two nearly open relays, that wound up with spoofed emails getting authenticated just like the real thing. The first offender is Microsoft’s Office365, which seems to completely skip checking for email spoofing when using SMTP relaying from an allowed IP address. This means a valid Office365 account allows sending emails as any address. The other half relies on the way Proofpoint works normally, accepting SMTP traffic from certain IP addresses, and adding the authentication headers to those emails. There’s an option in Proofpoint to add the Microsoft Office 365 servers to that list, and apparently quite a few companies simply select that option.

The end result is that a clever spammer can send millions of completely legitimate looking emails every day, that look very convincing even to sophisticated users. At six months of activity, averaging three millions emails a day, this campaign managed just over half a billion malicious emails from multiple high-profile domains.

The good news here is that Proofpoint and Guardio discovered the scheme, and worked with Microsoft to develop the X-OriginatorOrg header that is now applied to every email sent from or through the Office365 servers. This header marks the account tenant the email belongs to, giving vendors like Proofpoint a simple way to determine email validity.

Ransomware Gets Bigger

It’s not just spam emails that posted eye-watering numbers this year. We’ve broken the record for the biggest ransomware payment, too. Zscaler is reporting a $75 million ransom payment from a “Fortune 50” company. Reading the tea leaves indicates Cencora as a likely candidate, as this pharmaceutical giant was hit by an attack in February, and none of the usual suspects ever claimed responsibility. This leads one to suspect that it was the Dark Angels ransomware operation.

The Linux CNA, with a Grain of Salt

One of the interesting recent security developments is the proliferation of CNAs, CVE Numbering Authorities, particularly among Open Source projects. Part of the reason is the growing prevalence of CVE issued on bogus bugs, or with completely overblown CVSS scores. One of these new CNAs is the Linux Kernel itself, which has taken an odd approach to handing CVEs: Every bug gets one. On one hand, the kernel developers make a valid point that in kernel land, basically any bug can be a vulnerability. And it’s certainly one way to put the pressure on vendors to use more up-to-date kernel releases. On the other hand, Linux is now the most prolific CNA measured in CVEs generated each year.

The situation does not sit well with everyone. Grsecurity has published a case study on CVE-2021-4440, that highlights some issues. The emphasis here seems to be that the kernel team uses a lot of automation tools to manage CVEs, and these tools aren’t always great at accuracy or clarity. Now one thing to keep in mind, grsecurity in particular has had a rocky relationship with the upstream kernel, so a grain of salt might be taken with this one. Regardless, it seems like the kernel is experiencing some growing pains, as it comes into its new role as CNA.

Github Adds Attestation

Github has added a new attestation feature, presumably spurred by the XZ attack. Github Attestations are a cryptographic proof that a tarball or binary was built from the source code publicly available, and hasn’t been tampered with. This has been out for about a month now, and this week is joined by a quick starter guide to publishing attestations with everything a project releases. There’s also a Kubernetes project that only allows running images that have valid attestations in place, which is handy!

ZDI on Windows

ZDI has some interesting coverage of some recently discovered vulnerabilities in antivirus products, all around the idea of link following. Put simply, what if an antivirus detects a malicious file, but before it can delete that file, an attacker switches the file out with a filesystem link to a different file? In many cases, the antivirus follows the link and deletes something it shouldn’t. Part two is some more advanced ways to pull off this trick, like using NTFS Alternate Data Streams to trick the antivirus into action.

While we’re talking ZDI disclosures, there’s a Deep Sea Electronics communication module that had some problems, like a configuration backup endpoint that has no authentication check. There are a couple of other endpoints missing authentication, as well as trivial Denial of Service situations. Unfortunately this is a case where the vendor dropped the ball, and these vulnerabilities are assumed to be unpatched for this device.

Bits and Bytes

The unfortunate state of mobile applications is that just because it’s published on an official app store, there is no guarantee that an app is safe. Mandrake was first seen in 2016, with several waves of malicious activity, to disappear for a couple years. It’s back, and has eluded notice til very recently. I was intrigued by the idea that it excluded 90 countries from being targeted, and found this in the source document: “It avoids running in low income states, African nations, former Soviet Union countries or predominantly Arabic-speaking nations.”

Once again, in IoT the S stands for security. A wifi security camera with a generic brand name shipped with a hard-coded root password. On this one, the journey is most of the fun. But really, WiFi cameras have bigger problems, and it’s apparently becoming common for thieves to use wifi jammers to cover their tracks. Hardwire your cameras, and keep them away from the Internet.

While it didn’t rise to the Crowdstrike level, Microsoft had an Azure outage this week, that caused some headache. It turns out it was a DDoS attack, and Microsoft’s own Denial of Service mitigation tooling amplified the attack instead of mitigating it. Decidedly non-ideal.