CNCF releases a whitepaper on supply chain security, Frag attacks against WiFi devices, security webhooks, trusting terraform plans, shared credentials and app access, complexity vs. security vs. design.
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!
Don't forget to check out our library of on-demand webcasts & technical trainings at securityweekly.com/ondemand.
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.
We cover appsec news on a weekly basis, but sometimes that news is merely about the start of a new project, sometimes it's yet another example of a vuln class, and sometimes it's a topic we hope doesn't become a trend.
So, what themes have we seen and where do we see them going? Here are a few headline topics that have alternately generated yays a...
Repetition extracts data from ChatGPT, more vulns in the software that surrounds AI, guidelines for secure AI, LogoFAIL trips a boot, BLUFFS attack on Bluetooth, CISA's first secure by design alert, Okta's updated breach disclosure, and more!
This year we've talked about vulns, clouds, breaches, presentations, and all the variations of Dev, Sec, and Ops. As we end the year, let's talk about starting things -- like starting an appsec program or an appsec career. But is there still a need for an appsec team? Or has it turned into specializations for areas like cloud security and bug bount...