OWASP Top 10 for K8s, Firefox Process Isolation, Secure Software Factory, CFAA Policy – ASW #198

Here's a well-written walkthrough of various RCE and deserialization attacks against Ruby on Rails. One of the things that stood out to me was the inclusion of references to prior work on various attack techniques, which provides the opportunity to dive deeper into any of these items as well as showing how the security community works best when it acknowledges and builds upon techniques.

Mozilla released Firefox 100 earlier this month. An appsec aspect worth highlighting is the process isolation they improved for Windows in this release. We talk a lot about choice of programming languages and refactoring memory unsafe code (which is the nice way to refer to C and C++). Here's a good example of adjusting an app architecture in order to improve security. As with any refactor, tests can bring surprises -- in this case, crashes when encounter line endings. Check out more details on the Mozilla blog at https://hacks.mozilla.org/2022/05/improved-process-isolation-in-firefox-100/

CNCF's Technical Advisory Group - Security (STAG) has released their guidance on how to design and implement security for a build pipeline. It comes out of the larger supply chain work that CNCF, and just about everyone in infosec this past year, has been investing in. Having a reference architecture with security guidance is an important evolution from the more generic recommendations of "have a secure pipeline". Grab the PDF of the paper at https://github.com/cncf/tag-security/blob/main/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf As a point of comparison, Solarwinds described their approach to building a hardened software factory (aka CI/CD pipeline) in a whitepaper at https://www.solarwinds.com/resources/whitepaper/setting-the-new-standard-in-secure-software-development-the-solarwinds-next-generation-build-system/delivery. Their approach is understandably informed by the type of attack they suffered -- ephemeral systems to inhibit attacker dwell time, parallel builds to reach consensus on provenance and trustworthiness. It's interesting to see how organizations respond to attacks and how the changes they make take into account different scenarios.

Cloud native is an easy term to capture the idea of building, deploying, and running apps within the cloud. And it's one of those easy terms to use that hides a lot of complexity and effort needed to ensure a secure environment. CNCF first released this whitepaper back in 2020 and now they've updated content for sections like Security Assurances, Security Principles and Compliance. They've also included commentary and processes on the feedback process, which is an important way to engage the community -- check it out and share ways you think it could be further improved. For those of you following NIST's SP 800-218 Secure Software Development Framework (SSDF) -- we know it's an exciting topic -- the whitepaper now includes a mapping to SSDF practices. Grab the PDF of the paper at https://github.com/cncf/tag-security/tree/main/security-whitepaper

Welcome news for security researchers, pentesters, bug bounty researchers, and others "who root out vulnerabilities for the common good". It's not a change in law behind the CFAA, but it does clarify DOJ's policy on enforcing it.

More fuzzing! We don't need to go into detail on this one -- it's likely for a narrow audience who are already running fuzzers. But we'll leave you with the insights and links to other resources from a Twitter thread by Caroline Lemieux at https://twitter.com/cestlemieux/status/1524438583184138240

It sounds good at first glance, but I have to wonder - is having separate top ten lists for various parts of your stack a good thing? I thought there was at least one other besides the main top 10, but I'm only seeing the 2 mentioned on the website at the moment. (OK I see an "interpretation" for serverless...maybe that's what I thought of)

One thing I like about this article is that it's out in the "real world," not another post on a security blog...

While the mention of golang here feels like a distraction, it's still interesting to consider the various tools and code that an attacker will use. Anyways, core point here not too exciting - typo squatting on an rust crate, which then has a multi-stage attack looking for a gitlab CI server and installing a go-based executable