Eyes Open – ASW #174

Giving this a quick mention since the details are sparse and using it to highlight the case (once again!) for deploying FIDO keys for strong authentication to all your employees. Yes, part of your appsec threat models should include the customer support workflows that can view or modify user accounts. Yes, the cryptographic underpinning of FIDO2 and the WebAuthn standard make harvesting and reusing credentials like this infeasible. Yes, there can be hurdles to deploying these and ensuring you have strong account recovery mechanisms for employees. But it's 2021 and your appsec team should be working on getting to yes for this kind of authentication. We covered a growing market for OTP 2FA bots and some authentication threat models in 173. Check it out at https://securityweekly.com/asw173 For some related news on Twitter's journey from a similar hack to rolling out security keys, check out these articles: - https://www.wired.com/story/inside-twitter-hack-election-plan/ - https://blog.twitter.com/engineering/en_us/topics/insights/2021/how-we-rolled-out-security-keys-at-twitter

Here's a confluence of vulns, exploits, disclosure, patching, and timelines that's attracted attention within infosec. A vendor that conducts red team exercises, Randori, identified a buffer overflow in PAN-OS (used in many VPN devices from Palo Alto Networks) in November 2020, but didn't disclose the vulnerability to the vendor until September 2021. As a first comment, the visualization the vendor used to display the timeline did some chart subterfuge by placing key dates of discovery and disclosure on a horizontal axis, but didn't make that axis to the scale of the timeline involved. This obscured the relatively long 10 month delay in disclosure. It's a good lesson in the importance of creating accurate visualizations and the importance of reading them with a critical eye. Ok, effective communication is important, but there are also bigger discussions around the expectations for coordinated disclosure as well as distinctions between red team and pentesting exercises. In this case, the red team vendor apparently held on to the vuln for its sole use in client engagements, which doesn't seem as worthwhile a trade-off as disclosing it early to the vendor to fix. As the term is commonly used, red team exercises differ from pentests by being more goal-oriented in testing and org's ability to prevent, detect, respond, and recover from targeted attacks. For orgs whose security practices are mature enough to start these kinds of exercises, they don't start with the idea that you can't patch a 0-day, they start with the idea that they want to be able to contain and detect the activity that comes post-exploitation of a 0-day. However, this doesn't mean you need a 0-day for these exercises, you can also simulate this kind of initial foothold. But there's one more thing -- the vuln didn't affect PAN-OS 8.1.17, which was a recommended patch in October 2020. That version apparently fixed the vuln without realizing it was there in the first place. That's not surprising since code can change quite a bit and bugs can get fixed without understanding their security impacts. So a lot of orgs running the vulnerable versions (8.1.16 and lower) in 2021 were already behind the patching curve. Plus, the 8.1 version is slated for end-of-life in March 2022. So it's also likely that Randori didn't seem much of a future in holding onto their vuln. You can check out the blog post from Randori at https://www.randori.com/blog/cve-2021-3064/

We covered the ChaosDB vuln back at the end of August when the researchers first posted about it. However, they didn't go into technical details at the time, so we had to do a little shift in focus to talk about the good architecture choices of using Jupyter notebooks and how that good design decision was undercut by Azure's failure to secure the multi-tenancy aspects of its CosmosDB. Well, now we technical details in a great followup article from the researchers. It has lots of lessons for the shared responsibility model with cloud service providers. And it likely has some lessons that should have been learned and executed upon well before ChaosDB dropped onto the appsec syllabus. Check out episode 164 at https://securityweekly.com/asw164

BusyBox is probably more familiar to appsec and DevOps teams in the IoT space. But the obscurity vs. popularity of a (quite useful and indeed popular) software tool isn't the point, what stands out in this article is the use of fuzzing to successfully find lots of vulns. Fuzzing takes time and effort to set up, run, and analyze. Hence it's not at the top of the list for teams who are building out their appsec practices. Yet it is a good goal to strive for and, not only is it a good indicator of a mature SDLC, it can be an efficient alternative to other types of security testing. Not all bugs that fuzzers find will be vulns, but they'll all be bugs that impact software quality. Check out their fuzzing harness at https://github.com/claroty/busybox-fuzzing

Another article this week that'll likely get more attention in the show notes than in the show. This is a good companion to the BusyBox article in terms of building up a fuzzing capability. Fuzzing isn't a security practice to start with when building up an appsec program, but once you have good foundations in place for software composition analysis, patching, linting, and threat modeling, it's a worthwhile capability. Keep in mind that it's more effective in finding memory safety issues. So, if you're weighing the trade-offs of putting DevOps time into deploying fuzzers, make sure you're also considering refactoring code into languages like Go or Rust. While those will still be worth fuzzing, you may eliminate whole classes of vulns with that choice. Check out the project at https://google.github.io/clusterfuzzlite/

In at least every other episode we talk about memory safety issues. Last week we even noted the 25th anniversary of a seminal article on the topic, "Smashing the Stack for Fun and Profit" (see episode 173 at https://securityweekly.com/asw173). And we make the aspirational comments about seeing apps be rewritten from C and C++ into Go or Rust. The Prossimo project looks like a promising future to turn many ubiquitous apps from their C implementations into Rust. That doesn't mean they'll all become magically secure, there are many other types of flaws beyond memory safety issues. But it does mean that the majority of those memory issues and, critically, the amount of high-risk CVEs they've generated will dwindle to zero over time. And that's something that we'll gladly welcome. Check out the project at https://www.memorysafety.org/about/

Here's another article on the IoT and OT theme. Some researchers found a bunch of vulns in the TCP/IP stack of the Nucleus RTOS. What's possibly most surprising here is the presence of FTP -- who uses unencrypted channels these days? Well, other than the kinds of devices where crypto is expensive, error prone, and certs are harder to deal with. But then we have to ask why there are so many stack overflows on the list along with an apparent lack of ASLR? We know that ASLR isn't a panacea, but it seems like one of those hardening mechanisms that's trivial to enable and at least slightly-less-than-trivial to bypass. Check out the research at https://www.forescout.com/blog/new-critical-vulnerabilities-found-on-nucleus-tcp-ip-stack/

On the heels of HTTP smuggling, we know have a name for clever use of JavaScript Blobs and HTML5 markup: HTML Smuggling. Next up, researchers competing with each other to find the next smuggling route like some sort of appsec Kessel Run.

Here's a resource on game hacking, although a significant amount of the topics and techniques apply to just about any appsec situation. We talked about some gaming security in episodes 170 (https://securityweekly.com/asw170) and 171 (https://securityweekly.com/asw171). They also have an updated ebook of the content. Check out the PDF at https://gamehacking.academy/GameHackingAcademy.pdf

Here's a quick followup on a story we covered back in episode 170 (https://securityweekly.com/asw170). Like this week's article on the PAN-OS vuln, it's another saga of disclosure gone awry.