ASW #204 – Larry Maccherone

Brief followup from the Rolling PWN (https://rollingpwn.github.io/rolling-pwn/) issue we covered last episode. Honda says they're working on updates for current and future models, although it's not clear how far back "current" is in this case. The quotes from Honda also point to a threat modeling exercise for this in terms of attacker proximity, time, and tools. I wouldn't use that to downplay the attack, though. I'm curious to find more technical details, such as how it can rely on software-defined radio (like https://www.gnuradio.org) and low-cost (say <$100) hardware. The researchers say they're looking at more cars, so expect to hear more and even see it at a conference like DEF CON or hardwear.io.

Another named vuln for speculative attacks against CPUs. This work shows that a mitigation previously thought to be effective is (or never was) an adequate mitigation. Speculative attacks are interesting and likely a higher priority in threat models for orgs running their own multi-tenant systems. They're fun attacks to read about if you like learning about the inner workings of CPUs and their design tradeoffs, or low-level Linux kernel programming (since the open source code makes it easier to read about mitigations and design choices). But for most appsec and DevOps teams, it's probably more important to focus on the basics of asset inventory and applying threat models to an application's business workflows. Check out the researcher's website at https://comsec.ethz.ch/research/microarch/retbleed/ and PDF at https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf

The CSRB has released their first report. Regardless of whether you've heard enough about log4j by now, the executive summary is worth reading for how well it puts the timeline together and because it highlights how log4j is a symptom of under-investment in well-known practices. “Generally, the Cyber Safety Review Board (CSRB, or the Board) found that organizations that responded most effectively to the Log4j event understood their use of Log4j and had technical resources and mature processes to manage assets, assess risk, and mobilize their organization and key partners to action. Most modern security frameworks call out these capabilities as best practices.” Helpfully, it also calls attention to the under-investment in open source projects, which has been a theme of the OpenSSF (https://openssf.org) stories we've covered over the past few months. Read the PDF report at https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf

This article describes meaningful engineering work to make an environment more secure. It does so against the backdrop of SOC2 since that's one of the most common compliance frameworks (ISO 27001 would be another). Importantly, it describes SOC2 as a (weak, in their view) maturity model and that getting certification doesn't have to be a purely cynical exercise. I also really like this quote: "Careful, now. “Getting SOC2-certified” isn't the same as “doing the engineering work to get SOC2-certified”. Do the engineering now. As early as you can. The work, and particularly its up-front costs, scale with the size of your team."

A lot of the stories we've covered this year so far have been about maturing security practices within open source projects, from keeping dependencies up to date, generating SBOMs to make that updating process more machine-friendly, even refactoring some critical projects. They've also mentioned the push for making MFA more pervasive among contributors and project owners in order to prevent malicious activity from a compromised account. This article looks at contributors from a slightly different angle -- who are they, how might they introduce subtle flaws, and how could subtly malicious commits be identified. It should also help identify brittle projects that are critical to many other projects, but that have very few contributors. A quote from the article describes the common "bus factor" -- "Does this whole project fall apart if just one person gets hit by a bus?" (I'd love to do some archaeological digging to find the origination of the term.) I'm always suspicious of metaphors in infosec when they diverge from or obfuscate principles behind an issue rather than just provide an illuminating or humorous reference. The "bus factor" is pretty tame, commonly understood, and fits well with the article. But why make public transportation the menace here? Why can't we be more creative with something like, "Brain eaten by a mind flayer?"

Here's another example of the kind of vuln research we like to highlight. The blog post (see link below) introduces the problem, gives background on EKS and IAM in order to set context for why it matters, presents the vuln detail (a single line of code...) and how it could be exploited, then finishes with a description of the fix along with the potential window of exposure. For those of you doing code reviews, it's also a reminder of how simple actions -- lowercasing a word -- can lead to broken assumptions and validation within security checks. As always, normalize data *and then* apply security decisions to it. Which, of course, is easy to say as part of a checklist and harder to identify in practice. After all, this bug last for almost five years. Check out the original research at https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator

Patrick Wardle has created a lot of resources about macOS security, from blog posts to tools to advisories. He's offering this book online for free. While the focus might be malware, the chapters have a lot of general use for anyone working with security on Mac systems. The chapter on injection vectors might help you appreciate the nuances of macOS features (and its Unix pedigree), while chapters on binary analysis, disassembly, and tools will help anyone interested in picking apart binaries -- whether or not they're malware. This came across my radar via http://tldrsec.com/.

This article touches on some of the concerns about privacy and data collection in the wake of the recent Roe vs. Wade decision. How apps collect and process data has all sorts of appsec checklists, from encryption to hashing to authorization models to compliance obligations and more. But those checklists are informed by threat scenarios for technical flaws (XSS, SSRF, IDOR) or broad threat actors (unauthorized access) and rarely touch on why the app collects data in the first place and how the business might use that data. Appsec obviously has an important role in protecting data. But that's not the same as protecting privacy. Their practices overlap, especially those for confidentiality and integrity. However, privacy introduces user-centric practices like consent and transparency around data handling. And that overlaps with the idea of Trust & Safety -- how an app's features, or lack thereof, adversely impact different populations of users. The consequences of the Roe decision aren't something that can be solved by technical means. It requires social and political change. But technical solutions can still serve risk reduction depending on users' personal threat models. Here are a few resources to start with: - https://digitaldefensefund.org/ddf-guides/abortion-privacy - https://www.eff.org/deeplinks/2022/06/security-and-privacy-tips-people-seeking-abortion - https://www.wired.com/story/how-to-support-local-people-funds-abortion/

...and then never user it for anything of consequence. Fun article - At first the headline scared me. But even just giving this a quick scan gives you a sense for what goes on behind the scenes in a modern cryptographic algorithm.