More Car Hacks, CUPS Vulns, Microsoft’s SFI, Memory Safety, Password Complexity – Farshad Abasi – ASW #301

The term "web-enabled" for devices sounds a little archaic or quaint, and is now either just assumed or described with the boring label of "connected". But whichever term is used, most devices rely on HTTP and in turn have a web-based admin console. This applies to everything from lightbulbs to cars.

Here's more extended research on car security that mostly boils down to web security -- with the consequences "that would've allowed attackers to remotely locate, disable starters, unlock, and start" for vehicles.

Also covered in Wired.

No earth-shattering vuln here, but an important patch to apply. Probably more important to question if your default configuration for your app servers, or really any server in your cloud environment, needs to have CUPS enabled.

A lot of headlines noted a CVSS score of 9.9, but it appears the worst of the bugs has settled to a CVSSv3 of 9.0 (CVE-2024-47177). It's likely not exploitable due to many default configurations, but in any case it deserves a prioritized patch.

As many have noted in comparison, Heartbleed's CVSSv2 score was 5.0 -- although its CVSSv3 is 7.5.

Still haven't found any good examples of vulns rated on the CVSSv4 calculator.

This article makes the case that starting adoption of memory safe designs in new code may be more effective than focusing on old areas of code. But it also presumes your code base is in a state to mix C and C++ code with something like Rust. Supporting that mix can be a major effort in itself. But again, the article is proposing that kind of forward-looking effort as more impactful to security than just rewriting old code.

One point that stood out to me was the observation that "The Android team has observed that the rollback rate of Rust changes is less than half that of C++."

I think it's still possible to have well-managed memory with modern standards like C++17 and later, but if the language and compiler are improving code correctness and productivity in a way that's reducing something like a rollback rate of unanticipated bugs, that's a very good sign.

There are demonstrable improvements to security practices noted here. And, even if you don't have the scale of Microsoft or creating 5 million builds per month, a lot of the principles should apply to your environment.

We always note how basic an asset or app inventory is -- followed by the caveat that it's easy to say and hard to do. Even harder is enforcing an app lifecycle. Microsoft picked up that governance in "eliminating 730,000 unused apps" as well as "5.75 million inactive tenants." That's a lot of attack surface reduction, let alone potential cost savings in engineering and maintenance overhead.

Check out the PDF of the full report here

There's a lot of preamble to get through before diving into the details of what boils down to dependency confusion in Python and the potential insecurity (via confusion of package versions) introduced with PyPI management and the "--extra-index-url" option.

This article took me on a tangent into PEP 708, which proposed a more secure default that would avoid some types of confusion attacks. What then stood out was the journey from discussion in February 2023 to a suggested implementation example in August 2024.

This very short article has a bunch of self-reported data on the adoption of what orgs consider "must do" activities and how mature those orgs are. One stat that caught my eye was 65% of more mature orgs have secrets management in the "must do" category (and 45% of less mature orgs are doing this), but those numbers both seem surprisingly low.

The Microsoft article also mentioned attack surface. Here's another view of attack surface and evaluation of threats. It's a good type of write-up to emulate if you're reviewing other technologies or architectures. In other words, pay attention to the threat modeling and thought processes even if you're not using Nitro.

This is a little old, but the Appendix A on password strength warms my heart with this quote: "Many attacks associated with password use are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy and complex passwords as they are on simple ones."

So, maybe for cybersecurity awareness month, convince the dev team that handles your app's authentication to support passkeys or other phishing-resistant credentials and do away with the silly password strength calculators -- they're calculating a bad solution to the wrong problem.

Big fine, big number of plaintext passwords, and a big cleanup. I'll throw an optimistic angle on this in terms of the relative transparency and the internal processes in place to discover and remediate a mishandling like this. Meta isn't the only one to have done this, nor is it the only one to have reported it. Though it's probably a winner in terms of total fine.

The story goes back to 2019 and an article from KrebsOnSecurity.