Don’t miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!
0-day vulnerabilities pose a high risk because cybercriminals race to exploit them and vulnerable systems are exposed until a patch is issued & installed. These types of software vulnerabilities can be found through continuous detection but even then may not always have a patch available. It’s important for software teams to set up tools that continually look for these types of flaws, as well as defenses that let software adapt itself to an evolving threat landscape. In this episode, we will discuss the ins and outs of 0-day vulnerabilities and what the future of managing them looks like.
Larry Maccherone – DevSecOps Transformation at Contrast Security
Looking at Larry Maccherone’s career, you might think he can’t figure out what he wants to be when he grows up – Serial entrepreneur? Agile transformation coach? Open-source developer? Data scientist? Dev[Sec]Ops thought leader?
However, the underlying theme is that Larry has constantly been striving to create the highest performing (productivity, quality, security, etc.) software engineering teams.
At Comcast, Larry built and scaled the DevSecOps Transformation program over five years, and he’s now looking to apply what he learned doing that to help all Contrast customers and prospects.
Larry hails from Raleigh, NC, where his wife and four daughters make sure there is never a dull moment.
Co-founder & CTO at Cysense
Security Partner at Square
2. Retbleed, CSRB’s First Report, a Case-Sensitive Action, & Mac Malware Book – 01:00 PM-01:30 PM
Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!
This week in the AppSec News: speculative execution attack with retbleed, CSRB’s report on log4j, one-line lowercase action leads to a vuln, approaching SOC2 with secure engineering principles, free online Mac Malware book
Honda redesigning latest vehicles to address key fob vulnerabilities – 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.
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
DHS Review Board Deems Log4j an ‘Endemic’ Cyber Threat – 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
SOC2: The Screenshots Will Continue Until Security Improves – 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.”
The US military wants to understand the most important software on Earth – 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?”
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
The Art of Mac Malware – 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/.
Mobile apps are a privacy nightmare. The Roe decision put them center stage. – 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: