ASW #220 – Daniel Krivelevich

This past year we've covered several disclosures from the teams at Wiz.io and Orca.security picking at security boundaries and capabilities within Azure. This week it's Orca with a takeover and RCE in Azure's hosted Jupyter notebooks (their Cosmos DB Notebooks).

In general, using cloud-based virtual desktops like Jupyter is a good security choice that helps maintain a secure, consistent, and observable environment for interacting with sensitive data. It's a positive step in reducing an attack surface -- it's just important that the implementation's security meet its design intentions.

(We originally had this slated for episode 219, but ran out of time. And we still wanted to talk about it!)

I love this article for a few reasons. One, it's an usual type of testing that's very physical and very much about states and assumptions of a device. Those concepts aren't unusual and the security of a lock screen isn't unusual, but that kind of physical testing and experimentation doesn't scale well and is all about clever thinking as opposed to coding.

The second aspect I like is the engagement with the Google bounty program. The researcher benefitted from in-person discussions at a conference, but the whole experience highlights a good culture of collaboration. It also highlights a common frustration within bug bounty circles -- the dreaded duplicate. Luckily this one turned out well.

And, finally, I always like looking at the commits that fix a vuln. They're sometimes the best secure coding education out there in terms of, "Here's a problem. What would a good fix look like?" We've seen one-line changes that fix a critical vuln. In this case, it's several lines of well-considered code that reasons through other ways this scenario might come up again and then implements controls against those scenarios.

I care less about programming language wars than I do about Vim vs. Emacs.

I do care about engineering decisions and attack classes and the security ecosystem around tech stacks -- from the compiler to the IDE to analysis tools to software architectures. So, I do like this recommendation to switch to any number of memory safe languages.

Of course, my most common refrain after embracing memory safety is that there's a wealth of other vulns and attack classes that manifest within such languages. The appsec work isn't done; it's just shifting attention to a different type of flaw. After all, the major exploits we've seen in the crypto world have been predominantly race conditions, bad assumptions, and poorly implemented workflows -- all within memory safe languages. And the OWASP Top 10 barely touches on memory safety as a major threat.

So, please do shift away from C and C++ as considerations for new software. But keep in mind that population of applications that still need to be secured -- whether web, APIs, or others -- are already on memory safe languages and already struggling with other types of flaws.

Check out the "Software Memory Safety" (PDF) from the NSA.

Path traversal. Of course I'm going to mention this one!

While the article doesn't go into point-by-point details of their research and setup, it provides enough to replicate this kind of work. A fun dimension of this article is the hardware and firmware aspect. Industrial and operational technologies (aka industrial internet of things or IIOT) are often written in C (check out the other article this week about NSA's opinion on this) and often require physical access to devices in order to evaluate their security. This article showed how the researchers used a Raspberry Pi and some clear binary patching to emulate the firmware. And now have some CVEs to show for it.

Additional resources

• Wireshark is the go-to tool for capturing and analyzing network traffic.
• Ghidra is a great modern tool for reverse engineering binaries (not sure what this team used).
• Raspberry Pi is a great way to play with hardware in an accessible and inexpensive way.

We repeat this a lot on the show: Migrate to FIDO2 security keys wherever possible.

But another important point is that in a lot of cases it's not possible to do that migration because the app or service doesn't support FIDO2. So, this is a reminder for appsec and dev teams that their product should support SSO (e.g. SAML and OIDC), support FIDO2, and support more secure protocols like WebAuthn.

Every week we have articles about vulns. It's not hard to find examples of flaws in software. But we're also always on the lookout for articles on secure designs and architectures. Egress filtering for production environments is one of those recommendations that's easy to say, but isn't always easy to implement. Here's an example from Lyft that shows how that made this possible while requiring as little disruption to or actions from all the other engineering teams whose services would be affected.

Readable code is more maintainable code, which in turn is more secure code (at least in the long run). Here's a reference from the land of Go that discusses common topics and preferences when performing code reviews.

We'd love to collect more examples like this across other languages or for general engineering practices -- send us your favorites!

I'm highlighting a story here about malicious actors using IPFS - a web3 related distributed filesystem - to distribute some of their payloads. The point is even as developers, while we might not be using every technology out there, it's good to at least be familiar with what's going on so we can understand and recognize how others are mis-using things we've implemented.

We haven't mentioned SQL-I much in 2022, so as we near the end of the year I jumped at the chance to mention it for a moment

Thought this was a nice alternative view to looking at MFA. We can never think of everything, but try to consider how users will use the security tools you select to support.