Debugging & Dev Tools, Isolating PostgreSQL, Abusing the DevOps Pipeline, Xiaomi Flaw – ASW #209

Wiz has now revealed more technical details behind their ExtraReplica attack from last April. We covered that in Episode 195 (https://securityweekly.com/asw195). At the time, Wiz held back details because the underlying flaws affected more than just Azure. That's why this research is so enlightening to read -- they looked at an attack surface that could affect any cloud service provider (CSP). There's a line from this article that sums up the problem and the motivation for research quite well: “How are CSPs adapting legacy open-source software to fit the needs of the cloud?" They then dive into technical details and present an attacker's mindset that worked exceedingly well against PostgreSQL. Give it a read and use it for inspiration about other projects whose design never considered the needs of multi-tenancy.

This article plus the one from Wiz about PostgreSQL in the cloud share themes of threat modeling and attack surfaces. Where the Wiz article highlights implementation flaws of layering modern, granular authorization controls to existing software, this one is about organizing many of the known attack patterns against the systems that manage and build code. There's more than one lesson to take from this article, but one important one is to have MFA deployed for all your developers and admins. Preferably one based on FIDO2 security keys. Read more about threat scenarios to consider in their whitepaper at https://www.ibm.com/downloads/cas/OG6KNX1E (PDF).

We've got one article about attack software version control systems. Now we have this article about a flaw due to an absence of version control within software. It touches on Trusted Execution Environments and how implementation errors can break the boundaries between the so-called security world vs. the normal world.

I grabbed this article to talk about the security design process. Signal made several deliberate decisions on their data model and features that were intended to limit the impact of certain attack scenarios. Read Signal's response at https://support.signal.org/hc/en-us/articles/4850133017242

Another theme of this episode is breaches through third-party service providers. In addition to Twilio + Signal, this is about Mailchimp + DigitalOcean. Both of them have lessons learned that can inform any appsec program. In this case, it's about improving observability and resiliency with third-party providers. (Plus, yet another example of where MFA protected users.)

After two articles about breaches that attackers used for targeted attacks, this article provides a counterpoint with a mistakenly(!?) targeted attack. It's a chance to discuss whether the infosec cliche of, "I don't have to outrun the bear, I just have to outrun you" informs any useful strategy, or whether it's a phrase that needs to be relegated to the appsec abyss of spurious statements. With this article (and perhaps some others) in mind, re-read these two posts from Phil Venables - https://www.philvenables.com/post/are-security-analogies-counterproductive - https://www.philvenables.com/post/cybersecurity-the-winner-s-game-and-the-loser-s-game

We cover bug bounty programs and reports at least every month. I always bring up the question about what it costs to fix these flaws since the award levels from bug bounties show the value of finding them. (Notably, the awards don't equate to the time required to find them, just their impact.) The https://sos.dev program now offers awards to the fixing side of the equation. It's still focused on the value of the hardening or security improvement as opposed to the effort involved, but it's a great step towards creating incentives to build better software.

Most of this conversation has nothing to do with the IDE of Mr. Carmack, of Doom and iD fame. Interesting chat about how he sees many as resistant to modern dev tools like debuggers and IDEs