ASW #203 – Farshad Abasi

OpenSSL fixed a high risk bug in how it handles RSA 2048 bit private keys. It leads to a heap overflow, but is only triggered on Intel CPUs that support a specific instruction set. It's also only in the 3.0 branch. So, overall it's not all that interesting of a bug. However, the advisory has a wonderfully aspirational sentence that, perhaps unwittingly, sums up the state of appsec: "Note that on a vulnerable machine, proper testing of OpenSSL would fail and should be noticed before deployment."

A small story that touches on a bigger picture. The Python Package Index has started requiring 2FA for all critical packages (i.e. most downloads). One package owner didn't want to bother and pulled their package -- thereby causing apps depending on it to fail to build. They righted the situation by putting the most recent version back, but announced they'd no longer be maintaining the project. For me, this is less about 2FA and more about managing dependency graphs. Yes, all devs should have FIDO keys for their workflows related to managing and building code. But there's a quote in the package owner's last update to the repo that stands out -- “Python 3 has os.replace and os.rename, and those should probably work for most usecases this package was designed for.” That quote speaks to the idea that maybe we have an over-reliance on packages. And that there may be many basic functions that should have first-party language support or just be implemented in a few lines of code rather than pulling in a package. Here's one article that summarizes what happened, https://www.bleepingcomputer.com/news/security/pypi-mandates-2fa-for-critical-projects-developer-pushes-back/

I usually avoid any headline that's formulated as a question since they're either vapid clickbait with an obvious answer or cynical clickbait with an obvious answer. But this question about an open source cloud vuln registry is a good one. The principle of cataloging and tracking vulns in cloud service providers makes sense. What will be interesting to watch is what audiences find it useful -- tool developers looking to market "cloudvulndb compliant" scans (to be clear, such a thing would be purely made up), DevOps teams, or AppSec teams. There's clearly a need to know about vulns. What will be important to watch is what concrete actions those various audiences will be able to take from these. Check out the project at https://www.cloudvulndb.org

The paper starts off with plenty of familiar attacks that are just given an ML flavor, like serialization, credentials in code, and package dependencies. That's fine and not surprising since all code has potential for these flaws and ML is no different. But then the paper gets into more context-specific attacks against ML. This is where the paper shines and is worth reading if you work with any data science or ML teams. While the risk associated with each attack varies since their attack scenarios require varying degrees of access and knowledge, including these attacks in your threat models will help you better reason through the security and privacy implications of products that rely on the "magic" of ML.

Apple has been putting lots of engineering effort into security improvements like sandboxing components withing iMessage and Safari. This takes that a step further by purposefully disabling or changing features in order to reduce the attack surface of their devices. While Lockdown Mode won't be needed by the majority of Apple users, it will be immensely valuable to those targeted by attacks like those developed by NSO Group. Giving users the ability to enable this mode is a good step in security design.

Most organizations have far higher appsec priorities than worrying about shifting to "quantum-safe" crypto algorithms. The Cloud Security Alliance has set an aspirational goal of April 2030 for orgs to support these algorithms throughout their infrastructure, which feels like a similar timeline for the migration from SHA-1 to SHA-2. Of course, the most interesting aspects right now are the algorithm names -- in particular the CRYSTALS-Kyber (a Star Wars reference) for public-key encryption and CRYSTALS-Dilithium (a Star Trek reference) for digital signatures. No love for the blue crystals of Metebelis III apparently. Check out NIST's announcement at https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4

Yes, we're dipping into a crypto-as-in-not-the-useful-kind article, but this article combines some hardware hacking and software analysis to demonstrate a serious flaw. Researchers managed to recover access to a hardware device needed to sign transactions -- a fundamental capability necessary to this crypto.

We'll welcome anything that accelerates the demise of CAPTCHAs. Apple recently announced Private Attestation Tokens, which aims to decouple device integrity assertions from persistent identifiers. Check out the proposed standard at https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-01.html

We talk plenty on ASW about corporations creating bug bounty programs and their benefits. Looks like the ransomware crowd see value in this idea, as well...

The folks at Honda designed their keyfob systems to prevent replay attacks by using rolling codes and only accepting a sliding window of codes related to the most recent keypress. The issue, though, is a special sequence of lock/unlock commands, the pointer to the rolling code sliding window can be reset, so the codes can then be replayed. It sounds like this has only been tested on 2012 Honda Civics so far, but as they all seem to use the same keyfob system, this probably affects other models. Honda's announced they won't be fixing this issue, so keep an eye on your wheels... (h/t hackaday)