Drink Our Own Champagne – ASW #157

Password managers are an overwhelmingly good choice of tool to assist users in managing their credentials. One reason is that it discourages password reuse across sites and can create better passwords that humans don't need to memorize. Unfortunately, this security benefit breaks down when the password manager tries to be too clever about generating random passwords and ends up generating apparently random passwords in a decidedly predictable manner.

Getting rid of a vuln class can be the most effective appsec investment, but doing so often has a steep initial barrier that can seem impossible to overcome. Hence, appsec teams may opt for scanning, WAFs, or other approaches that manage the risk of vulns present in code. This write up from Google demonstrates how well they eliminated DOM-based XSS from their codebases by adopting Trusted Types. Of course, it also helps to have the time and software development budgets to take on such as significant refactoring task. Even so, the results are not only encouraging, but elevate the codebase to be more consistently secure as it continues to grow. Read more about trusted types in their spec at https://github.com/w3c/webappsec-trusted-types

Following MITRE's punctuation-adorned ATT&CK framework comes its counterpart for defenders with the numerically named D3FEND. It's not a prescriptive set of application protections -- it's a way to build a shared vocabulary of different strategies for protecting apps, their users, and their data. (And it's also a chance for the appsec community to get ahead of any "D3FEND-compliant" marketing in the way that "OWASP Top 10 compliant" became a designation empty of meaning.) Check out the ATT&CK framework at https://attack.mitre.org. Plus, John and Adrian talked more about it in last week's episode 156 -- so check that out, too! And as an important addendum for any font geeks out there who might be giving the current D3FEND logo a side-eye, check out the "Typeset in the Future" blog for a fun and informative history of sci-fi typography and design. You can find it at https://typesetinthefuture.com

This is the type of approach that demonstrates when and how to use a bug bounty for your applications. If you don't have an appsec program or your appsec program is just starting, your bounty program is likely going to subsidize lots of researchers who are running the same simple tools you could be running yourself. In this case, the team addressed this class of vulns by building a well-designed mechanism to scan for insecure patterns and notify devs so they could fix misconfigurations quickly. It's a great step towards hardening the org's processes for provisioning DNS entries and instances so that takeovers don't even become possible.

As we're talking about appsec vocabulary this episode (see the other article on the D3FEND framwork), we'll first point out that not every security event that affects a vendor is a supply chain issue. Or, at least, it's not a software composition issue. But the more important appsec lesson from this most recent ransomware episode is the cost of legacy code -- the initial attack vectors were apparently dead-simple SQL injection exploits against ASP code. The entire vuln class could have been avoided by using parameterized queries, but that also forces us to ask at what point should ancient ASP code have been refactored into a newer language with better security frameworks. There are few ways the code could have been worse (ahem, Perl) and many ways it could have been better (any modern language that has native support for parameterized queries, not to mention CSRF countermeasures, better linting, and security scanners).

This latest big bug for Windows hit a few interesting appsec angles. Researchers accidentally disclosed the vuln after mistakenly thinking a prior patch had addressed it -- turns out there was more than one bug in this particular codebase. Another angle is looking at how much risk a printer spooler posed to Windows systems and AD servers. It looks like another case where Microsoft is trying to navigate backwards compatibility and support for older system architectures at the expense of better sandboxing and isolation for services. Check out Microsoft's latest updates at https://msrc-blog.microsoft.com/2021/07/06/out-of-band-oob-security-update-available-for-cve-2021-34527/

Here's an article that's more focused on the hardware side of appsec. It covers various methods for putting hardware and firmware into error states, especially states that might bypass security controls. Even if you're not working in hardware, the series of articles are easy to understand and several of the concepts can be generalized (or have parallels) to software applications. Reading about the threat modeling and countermeasures from one domain is a great way to bring a creative and thoughtful approach to threat models in other domains. Check out the followup articles - https://research.nccgroup.com/2021/07/08/software-based-fault-injection-countermeasures-part-2-3/ - https://research.nccgroup.com/2021/07/09/alternative-approaches-for-fault-injection-countermeasures-part-3-3/

Twenty years ago the Code Red worm ran havoc throughout IIS systems across the internet. At the time, infecting almost 360,000 systems in half a day was quite an accomplishment -- landing it on the radar of the FBI and White House. It occupied news cycles for a month leading up to an anticipated Code Red 2 outbreak that...turned out to be a fizzle. On the heels of Code Red (and the double decode vuln that preceded it), Microsoft significantly hardened IIS to the point where these remote vulns became exceedingly rare. Yet Microsoft still deals with significant flaws elsewhere in its codebase. We also still see significant appsec attacks in 2020 and 2021 that are once again "wake up calls" about the security of software and supply chains. It can be helpful to reflect on old attacks and find the appsec lessons that lead to their extinction, not their repetition. A few more articles: - https://docs.microsoft.com/en-us/security-updates/securitybulletins/2001/ms01-044 - https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2001/ms01-033 - https://www.scientificamerican.com/article/code-red-worm-assault-on/ - https://www.theguardian.com/world/2001/aug/01/qanda.janeperrone

Some security is better than no security, but as we've seen before, complex security results often in just "some" security. The RPM code wasn't checking revocation lists or cert expiration. Looking at the issue on github, they're agreeing that proper use of OpenPGP includes "complexity of a full implementation" and are considering alternatives like signify.

Google released version 2 of their security scorecard project. Basically it scans a software project (and git repo configuration, if you're a project admin) and checks for code review processes, if fuzzers/SAST are used, build system security, bad dependencies.