ASW #205 – Ferruh Mavituna

Hello path traversal! There are several things I love about this example. Despite having a "high" CVSS of 7.5, it admittedly is less likely to be a high risk for most orgs, but I really appreciate the reasoning stated in the advisory: “This could be exploited in, for example, a Ruby on Rails application using tzinfo version 1.2.9, that allows file uploads and has a time zone selector that accepts arbitrary time zone identifiers. The CVSS score and severity have been set on this basis.” That first sentence is really helpful context for evaluating risk. Next, it's interesting that "versions up to and including 1.2.5 can only be made to load files from directories within the load path." There's possibly an angle here about app hardening and restricting the locations that a gem file can reach. However, that requires some deeper Ruby (or Ruby on Rails) insights. If you're a Ruby expert, drop us a note about architecture choices here. Finally, this has a good lesson in nuances of regular expressions. In one case an unnecessary escape was removed, "+" changed to "+" because of its context within a character class (between "[" and "]"). More relevant to security is the switch of anchors from "^" and "$" to "A" and "z". Anchoring is a good practice for ensuring a pattern matches the beginning and end of a subject. Using the "A" and "z" version of the anchors ensures that it always matches the entire subject -- "^" and "$" handle newline characters differently depending on whether the parser is in single-line or multi-line mode. Avoiding surprises from newlines is always a smart security choice. If you're interested in reading through the code, check out the fixes at https://github.com/tzinfo/tzinfo/commit/9905ca93abf7bf3e387bd592406e403cd18334c7.

I almost skipped over this article as the bug didn't seem to exciting and didn't seem like it'd be a pervasive one since it's not part of the default Confluence deploys. (It's in a third-party app for Confluence that creates an account with a hardcoded password.) I changed my mind when I got to the paragraph that started with, "Uninstalling the Questions for Confluence app also does not remediate the vulnerability..." Ouch. That's an unpleasant surprise. Usually I'd expect removing an app to remove the attack surface -- no app, no attack vector. But this situation feels a little too much like the William Hurt and facehugger experience from "Alien"...

Nobody puts a Patrick Swayze reference in the corner. Of course this is going to catch my attention, even though it's from earlier this month. This article walks through an attacker's mindset for picking apart OAuth mis-implementations. It's a great example of scrutinizing specifications and understanding their security implications. The article provides a brief background on OAuth principles and then explains how to take advantage of mistakes to subvert authentication or authorization workflows. It also links to good security practices for hardening OAuth 2.0 workflows. So it's worth reading whether you're building or breaking apps that depend on it.

Whether or not you use sigstore or slf4j, reading security audits is always useful for informing your own writing and threat modeling skills. These two reports show the value of the OpenSSF investments in security. It's great to see progress on these security fronts. - https://ostif.org/wp-content/uploads/2022/07/OSTIF-2022-Q1-Sigstore-Report.pdf - https://ostif.org/wp-content/uploads/2022/07/OSTIF-2022-Q2-slf4j-Report-v2.pdf The Open Source Technology Improvement fund also looked at Argo as part of this work. We covered a JWT flaw in Argo back in episode 199 (https://securityweekly.com/asw199). Check out details for this latest security review at https://ostif.org/our-audit-of-argo-is-complete-critical-and-high-severity-security-issues-found-and-fixed/.

A hardcoded password, default password, and IDOR stand out from this report by researchers looking at the software side of a fleet management app. Half of this report walks through the vulns, with the other half highlighting the potential exposure to the various industries and countries relying on these GPS tracking devices. Check out the PDF report at https://www.bitsight.com/sites/default/files/2022-07/MiCODUS-GPS-Report-Final.pdf

The most fun tabletop exercises involved dice, maps, and a few rule books like Dungeons & Dragons. In appsec, and infosec in general, tabletop exercises are less about owlbears and locked doors and more about what-if scenarios that explore compromise scenarios, test processes, and push on assumptions about an app's environment. This article briefly walks through key steps in organizing and executing a tabletop exercise. And if you're ever in need of inspiration for a tabletop scenario, most of the vulns and research we can lend themselves quite well to this kind of "premortem" evaluation of how they might affect your org. And, to come back to the role-playing game aspect, those games are collaborative exercises in communication -- storytelling. They have all the hallmarks of meetings, from having an agenda (of sorts) to the dynamics of sharing conversation time to practicing active listening. In other words, RPGs are also good practice for the business world. After all, if you can get a gaming group together on a regular basis, most other problems feel easy in comparison.

The folks at meta decided to have some fun with a bug report into the Hermes JavaScript engine. Instead of just validating the issue - which ended up being more critical than initially reported - they made an example of the vuln by showing how to leverage it to run Doom.

tl;dr a vendor who probably has a solution to speculative execution attacks has a report showing most hardware vendors (think: Dell, Lenovo) only have either partial, or no support to prevent speculative execution attacks in their latest firmwares.

While this isn't a direct security story, I think there's a security aspect to this: It's estimated that to train GPT3 costs between 20-30 million dollars worth of compute time. That means that even if the model is open-sourced, the average developer has no chance of training and doing R&D with the model. The security aspect here: With a model that large, how long would it take security researchers to test even a portion of that model?