Vulns in Jenkins code and Cisco devices that make us think about secure designs, MiraclePtr pulls off a relatively quick miracle, code lasts while domains expire, an "Artificial Intelligence chip" from the 90s, and more!
Security Weekly listeners: Cyber threats are evolving — is your organization keeping up? The 2023 Cybersecurity Year in Review is Here! Uncover the latest challenges and strategic responses in CRA's 2023 Cybersecurity Year in Review – sponsored by RSA Conference. From the impact of generative AI to the risks of ransomware to navigating new SEC rulings, get ahead for 2024 with your free copy. Download the report at securityweekly.com/yearinreview2023
Security Weekly listeners save $100 on their RSA Conference 2024 Full Conference Pass! RSA Conference will take place May 6 to May 9 in San Francisco and on demand. To register using our discount code, please visit securityweekly.com/rsac24 and use the code 54USECWEEKLY! We hope to see you there!
Mike Shema
- Excessive Expansion: Uncovering Critical Security Vulnerabilities in Jenkins
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?
- Introducing MavenGate: a supply chain attack method for Java and Android applications | Oversecured Blog
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.
- IOActive Labs: Owning a Bitcoin ATM
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.
- MiraclePtr: protecting users from use-after-free vulnerabilities on more platforms
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!
- Cloud Threat Landscape: A Cloud Threat Intelligence Database | Wiz
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
- Cisco Unified Communications Products Remote Code Execution Vulnerability
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
- We Must Consider Software Developers a Key Part of the Cybersecurity Workforce | CISA
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.
- FUN: These Are the Notorious NSA Furby Documents Showing Spy Agency Freaking Out About Embedded AI in Children’s Toy
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...
- FYI: Share your feedback about developing with Go
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.
John Kinsella
- Be careful with GKE – Google Cloud permissions can allow 3rd party access
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.
- More malware in Pypi
I keep ranting on this one, but nothing seems to be changing...
- One dev asks: “Was Rust worth it?”
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.
