CNCF Supply Chain, Frag Attacks, Securing Webhooks, & Complexity vs. Security – ASW #151

This article makes a case that bad design -- whether in interfaces, software architectures, or processes -- can be a better way to frame security challenges than merely attributing complexity as a trade-off with security. What's particularly nice about this article is that it doesn't just swap out terms, it presents examples and guidance on how to achieve good design. Plus, these design goals have direct ties to application security, from building apps with opinionated defaults and declarative configurations to using the "5 Whys" and blame-free postmortems.

Cool research that digs into the attack surface of WiFi standards and demonstrates how design flaws have far-reaching consequences across implementations and, in this case, across decades. We've seen fragmentation-style attacks before, most recently as part of the SAD DNS flaw back in November 2020. This research is also a great example of good documentation and well-described threat scenarios. As the researcher notes, aspects of this problem were known as far back as 2007. What makes this interesting is the journey from a known-but-difficult-to-exploit flaw to addressing the flaw across multiple implementations. It touches on familiar aspects of prioritizing development efforts, dealing with backwards compatibility, and revisiting flaws when new information comes to light. Check out the research at https://www.fragattacks.com

Webhooks have become a common design pattern for handling events between web applications. This article shares insights on mistakes to avoid in implementing them, from exposing cloud resources to SSRF to ensuring they have some form of authentication. For another example of request signing, check out the documentation on "Signing AWS API requests" at https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html. Also check out the [tl;dr sec] newsletter that had this and other articles at https://tldrsec.com/blog/tldr-sec-083/

This isn't about bounties for bugs, it's essentially bounties for credentialed access to a third-party app. Not only does this access pattern create a grey area in the meaning of "authorized access" and set an expectation for sharing credentials that runs counter to all security recommendations, it expands the types of risks app developers need to be aware of. This type of access pattern isn't unheard of -- it's exactly the sort of problem that OAuth was intended to address. App developers have long deal with account takeovers and inauthentic behavior (like bots). So, what happens with apparently authentic behavior in an account shared with another app that's been implicitly approved by a user? Here's a related article about Plaid conducting a similar effort, https://www.vice.com/en_us/article/bvzzqa/plaid-paid-500-dollars-workplace-logins

We talked about the "why" of adopting a language like Rust in a project back in episode 147 -- defeat a class of vulns like unsafe memory handling and parsing malicious media files. This article gives a good insight on the "how". In other words, the dev toolchain and integration with build processes have to be just as robust for a new language. You can't just say, "Write more secure code" in a different language without providing the means to make that language a viable choice. It's the same principle as offering up security tools to a DevOps team; make the tools work natively in their environment and the adoption will be far more successful.

Most people think of "terraform plan" as a way to check their terraform configuration before executing it, or to generate a full plan with variables interperted (used for IAC scanners, gitops, or other tools). Turns out there's some scenarios where the plan command may execute code...

CNCF's Security TAG just published their whitepaper on supply chain security. I like how it provides guidance for different assurance and risk levels. The whitepaper's a meaty 45 pages, but a link off the announcement blog has a framework "cliff notes" version.