- 1. The cloud has an isolation problem: PostgreSQL vulnerabilities affect multiple cloud vendors
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.
- 2. Controlling the Source: Abusing Source Code Management Systems
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).
- 3. Xiaomi Phone Bug Allowed Payment Forgery
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.
- 4. How a Third-Party SMS Service Was Used to Take Over Signal Accounts
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
- 5. Impact to DigitalOcean customers resulting from Mailchimp security incident
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.)
- 6. Confused cyber criminals have hacked a water company in a bizarre case of mistaken identity
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
- 7. Secure Open Source Rewards program launched to help protect critical upstream software
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.