Verizon DBIR, CVSS 4.0, Security at Scale, Big IAM Challenge – ASW #244

We need secure apps. We have top 10 lists, CVSS scores, CVEs, and other acronyms to remind us to create secure software.

But we also have to be reminded by something like the Verizon DBIR that "Attackers used the Exploit vulnerability technique in 5% of breaches."

Instead of worrying about package dependencies because they're easy to scan for, maybe appsec should be pushing for more impactful investments in in strong authentication, strict authorization, good isolation, and designs that reduce the impact of compromises.

Attackers apparently identified a flaw two years ago that they've been exploiting en masse lately. A security review identifies more flaws. SQL injection seems like a flaw that should be non-existent these days or trivially identifiable by tooling.

These kinds of stories -- long-standing flaws, apparently simple flaws -- always make me wonder about what the company's appsec program looks like and what lessons we could learn from it. Was it just scanning for known vulns? Did it have any scanning? What kind of security discussions did the developers have?

More articles:

• https://www.wiz.io/blog/cve-2023-34362
• Cl0P Gang Sat on Exploit for MOVEit Flaw for Nearly 2 Years

CVSS isn't the only vuln scoring game in town, but it's the most recognizable one. Infosec news stories like to talk about the "perfect" 10s and usually mention it when talking about the latest vuln being exploited.

With this new version, CVSS is trying to reinforce the distinction between "technical severity" (essentially what CVSS started as) and the "risk" that it's too often conflated with.

Check out the presentation for more insights on what changed and why.

Public comments are open until July 31, so review and respond if you think more revisions are in order.

How many orgs still run security appliances? How many orgs still run their own email servers?

Sure, it's nice to see a vendor response whose approach to patching a vuln is nuke it from orbit, but I'm still stuck on the first two questions to bother going too deep into the rest of this topic.

Pure web app hacking that stems from a dead simple mis-implementation of a password reset feature. It's a nice write-up that's helpful for attacker-minded thinking and has a very careful approach to testing, which is equally nice to see.

And, thinking back to the Verizon DBIR, this was in fact an exploit that lead to the more typical impact of a credential-based compromise. But it also highlights design flaws like lack of authorization controls and data isolation.

Security workflows have notoriously had horrible UX -- look as far back as "Why Johnny Can't Encrypt".

This article has good, simple advice. It also made me wonder if the cloud security providers are starting to learn about the benefits of good UX and guiding developers to secure defaults.

A CTF from Wiz.io covering IAM concepts in AWS. Read more about it on their blog.

As Sophos says, this is more a "teachable moment" than anything else, but I like teachable moments! Basically, an attacker could attempt to setup a clickjacking attack moments before the browser displays a dialog about an expired or invalid TLS certificate

So what's the fix?

OK - technically a "specification language," TLA+ was created by the same person who created LaTEX.

One sentence catches my eye from the 90s-themed TLA+ website: "TLA+ is based on mathematics and does not resemble a programming language. Most engineers are familiar with programming languages, but not with precise mathematical notation."

This is from earlier this year, but interesting - one of the downsides that people mention in relation to golang is the overhead of garbage collection. Go 1.20 added "memory arenas," where instead of garbage collecting each allocation (per variable, map, etc), a "arena" of memory is allocated and then freed at once when the program finishes with it.

In Google interview speak, this results in a optimization of O(1) vs O(n) in GC performance.

This post talks about how AWS built Cedar with automated reasoning and differential testing, but as with the TLA+ story, this style of engineering is something Amazon has been using for a while now to bring more "science" to computer science.

Cedar's first being used with AWS' "zero trust" vpn solution, but there's hints that they intend to use it elsewhere, as well.

This is a long one. The fine folks at Checkpoint Research go through how to analyze a Rust binary. Why is this a thing? Because this is what security researchers and incident responders do frequently to try and figure out how their system is being attacked or misused.

It seems rustc is a little different in how things are packaged up, leaving the authors to start this blog with "You attempt to analyze a binary file compiled in the Rust programming language. You open the file in your favorite disassembler. Twenty minutes later you wish you had never been born."