The underlying vuln here is an arbitrary code execution by taking advantage of path traversal (woohoo!) and PowerShell within the Microsoft Support Diagnostic Tool (MSDT). When the flaw was initially reported to Microsoft in 2019 they rejected it as not having traits that can be addressed -- it didn't cross a security boundary and it essentially boiled down to, "Convince a user to execute a command within the privileges of their account." Over two years later the flaw is now fixed due to more concern about threat actors abusing it and that perhaps there was a security context that the flaw weakened. Windows tags files downloaded through a browser with a "Mark of the Web", adding a flag that indicates the file should be treated with suspicion and a warning presented to users upon first access. MSDT apparently ignored this tag and didn't warn users about potentially unsafe files being executed. For me, the larger and more important discussion point is around phishing. This attack vector didn't target or trick users into divulging passwords, to which my standard response is invest in FIDO2 and WebAuthn login flows. But it did touch on the scenarios of users downloading and executing arbitrary files, which is where the discussion can turn towards (dramatic pause...) zero trust and how to isolate users' end points from sensitive systems. This post has a good details on the technical background of the vuln, https://blog.0patch.com/2022/06/free-micropatches-for-follina-microsoft.html

Add this article to the list of companies marketing their budgets for BugOps -- chasing individual vulns through a bounty program. I'll repeat my new reaction to these articles: What was the cost of fixing the vulns? It's useful to know that a vuln might cost $5,000 to identify (even though that's the risk-based award and not a measure of effort). I'm very curious how that translates to fixing the flaw as well. Is it another $5,000 or something orders of magnitude higher or lower? And, finally, given a $13M annual budget, what would you have spent it on instead?

This episode already has a major theme of Microsoft and I couldn't resist including a competition based on using Microsoft Excel -- covered on ESPN2 no less. What's the appsec angle? Aside from disabling macros for security? Find out as I pit the ASW co-hosts against Excel-based challenges like calculating a CVSSv3 environmental score, modeling an appsec budget, and creating a port scanner.

One more Microsoft-related article on this episode -- and one that leads into another theme of browser security. We briefly covered the new iOS Lockdown Mode on episode 203 (https://securityweekly.com/asw203). The Edge browser has joined the ranks of applications providing a more secure environment by disabling JIT (among other things). JavaScript's JIT compilers have been notorious sources of exploitable vulns. Some of the appsec discussions we could have here are sandboxing and isolation strategies for JIT compilers, whether refactoring them from C++ to Rust would address the major attack classes we see in them, what observable performance impacts not using JIT would have.

We'll dive more into last week's BlackHat and DEF CON presentations. This quick note about Katie Moussouris' talk about bug bounties ties in well with the other article on Microsoft's $13M spend and the one about Google's increased stakes in Linux kernel security. But those are also two companies with high security budgets and mature programs. What does a strategic approach to bug bounties look like for small companies?

This is an example of escalating the stakes in a bug bounty program to test mitigations for a class of attacks. Here, Google is focused on Linux kernel hardening. It's a healthy evolution of using bug bounty programs that avoids the anti-pattern of BugOps -- just finding and fixing bugs as they come in -- and focuses instead on creating better architectures and mitigations that make introducing flaws or exploiting them far more difficult. The Google Security Blog has more details at https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html

This is a companion to the Edge security article, but in this case it's about a company customizing a browser to inject JavaScript of their choosing. Allowing the browser to modify web pages isn't necessarily bad -- that' s what ad blockers do. However, capabilities like ad blockers are both privacy friendly and executed with active user consent. This situation highlights the tensions within browser security and privacy models between users, companies, and browser developers themselves. After all, we've seen very different approaches to user tracking in Safari and Chrome.

Since I mentioned the Microsoft "DogWalk" article about social engineering attacks, I thought this was a nice parallel. The threat scenarios are slightly different, so it's not a perfect comparison (one is about downloading and executing code, this is about protecting login flows). But this is a good reminder that if you're working on supply chain security or CI/CD hardening, one of the most effective improvements you can do is require FIDO2-based tokens for all the workflows related to committing, building, and deploying code, as well as human access to production systems (even though that should be a rare event anyway).

New research from portswigger presented at this past week's Black Hat and DEF CON. It's a long write-up with great details on the intricacies of HTTP/1 and how implementation choices lead to exploitable flaws. In other words, the HTTP/1 standard has enough ambiguity in it to have surprising side effects and mistaken assumptions in its implementations. Fortunately, the rigor put into designing HTTP/2 seems to have mitigated most of these "desync" style attacks. This research is a good example of scrutinizing familiar protocols for subtle behaviors and identifying a new attack surface for something as ancient as HTTP/1.

Interesting but disappointing situation: "The weaponization of failed patches in various vulnerabilities is absolutely being used in the wild right now"