Getting Your First Conference Presentation – Sarah Harvey – ASW #271

I haven't seen a real-world WebSockets vuln in ages. Here's a decent, but not very exciting, example. (An exciting vuln would be abusing the custom messages the app was using WebSockets for.) It boils down to a lack of origin verification on the endpoint.

Here's a brief resource from Port Swigger about WebSockets security and some documentation from Zed Attack Proxy on how to use the tool to test WebSockets traffic.

The other vuln is a data leak related to an "expandAtFile" capability in the third-party args4j library that parses command-line options. Args4j has special handling for the "@" symbol, "is used to reference another file that contains command line options separated by line breaks."

Jenkins fixed the flaw by disabling that "expandAtFile" feature.

So, who needs that feature in the first place? Should it have been disabled by default by the library? Should Jenkins have better isolated the process to prevent reading from the filesystem, whether it knew about that args4j feature or not?

Oof there's a long marketing preamble before getting to the gist of the article...

This highlights a security challenge of aging projects that rely on DNS entries for provenance or identity. Code can long outlive a domain name, especially since there's a cost disparity in hosting code (effectively free) and hosting a domain name (annual registrar fees).

There are two other sentences that stood out for me: “Most applications do not check the digital signature of dependencies, and many libraries do not even publish it.” and “The current system with PGP signing is probably outdated…”

Maybe this is an area where the ubiquity of SBOMs will drive expected default behavior to always only use dependencies that have been verified. Let's not conflate threat scenarios -- verified packages can still be insecure packages, but at least verification cuts down on a class of attacks that insert malicious code.

I love how the researchers cleverly used QR codes to deliver their exploit rather than demonstrate the more prosaic technique of connecting a keyboard due to their physical access.

And just because this mentions QR codes, I still think QR codes are a fine technology that doesn't have any more risk than text-based URLs. If we're going to predicate controls based on visual inspection of "bad" links, then appsec is a lot cause.

This is a pretty cool programming success story -- especially for the C++ world. In one year Google Chrome team went from using MiraclePtr "for the browser process on Windows and Android" to enabling it for "ChromeOS, macOS, and Linux."

And the end result is that it "mitigated 57% of these use-after-free vulnerabilities in privileged processes."

From what I can tell, MiraclePtr took about 1-2 years of development and benefited from a lot of prior art and research. Even a four-year timeline to mitigating more than half of use-after-free vulns is a great impact!

Wiz has another database for cloud security folks. This one is useful for devs interested in building out threat models and for incident responders to build out observability.

Check it out at https://www.wiz.io/cloud-threat-landscape

Rather than focus on the specific app (especially since I have no idea if it's even all that prevalent or well-known), I wanted to use this as a topical example in a discussion about secure design.

You have a service that listens for messages from arbitrary users, it has to parse those messages, it has different privilege levels for handling communications (e.g. VoIP, video calls, chat) and administration. What choices do you make?

Use Rust? -- you don't have to rewrite the entire app, just the parser. Maybe the network stack. Isolate processes? -- move the parser into a sandboxed area, use IPC to communicate with the rest of the system

I'll quibble with the framing, but strongly agree with the sentiment -- we might also consider cybersecurity as a key part of the developer workforce...

But the points raised are important. What are the best ways to educate developers about secure code and secure designs? Do we move Top Ten lists from electives to required courses? (I'm pained just positing that question.)

If you have ideas, you're in luck. There's a link to an RFI at the end of the article.

I remember when this was in the news and how infosec was jumping onboard this idea as a threat scenario.

What I really wanted to highlight was this phrase from the article, quoting some of the docs on how the NSA "discussed the toy’s ability to “learn” using an “artificial intelligent chip onboard” on an internal listserv."

I love how we had AI chips back in the 90s -- for a very belabored definition of AI, but still...

It's cool to see projects seeking feedback. Appsec could use more of this. And, for anyone who bothers to read these show notes, here's a final pun: Go respond.

GKE provides k8s clusters with IAM authentication enabled by default, in a manner that may make it possible for any Google Cloud customer to access a new GKE cluster (eg - another customer's cluster).

The TL;DR here is you really need to understand the permissions model both of your cloud provider - and of the software you consume from that provider. This, unfortunately, isn't easy..but the alternative is not a pretty sight.

I keep ranting on this one, but nothing seems to be changing...

We're fans of Rust here on the ASW, as are many in the software development world. But talk is cheap - what's it like to use this beast in the Real World, on a large-scale projects?

The author of this post as built a Rust-based application framework, along with "~100 packages" on crates.io. With that experience, he talks about some of the issues he's run into - refactoring can be difficult, figuring out the best way to structure large projects is great in some ways, unpleasant in others.

One point I like on the positive side - he feels that he can now code better in other languages.