Okta Breach, SolarWinds RCEs, CISOs and Boards, Crypto Business Logic, Secure Design – ASW #260

There's a lot of appsec packed into this brief article from BeyondTrust about how malicious activity in their Okta instance pointed to a breach of Okta's Customer Support team.

From an appsec perspective, there was a sensitive cooke in an HAR file and an API access that didn't rely on a FIDO2 authentication or device authentication. I like these subtle reminders of how even strong authentication (I love to talk about FIDO2 and WebAuthn) can have a complex threat model based on the full workflows it supports.

Okta released a statement.

Similar to BeyondTrust, Cloudflare also noticed the breach via an attack against the systems. Their writeup adds a few more authentication and hardening recommendations -- along with a bit of shade in having to counter a breach for the second time.

I almost skipped this article -- we don't need to repeat log4j and SolarWinds until the end of time. But I grabbed it for a few reasons. First, one of the vulns disclosed was a directory traversal to RCE. Another reason is to use this as an example of the comprehensiveness that's needed from a security program. SolarWinds famously hardened their CI/CD and, surely, invested in more security after their last breach. These flaws highlight that code still needs to be scrutinized and that the idea of hardening the design of a CI/CD environment could also apply to hardening a codebase -- directory traversal and deserialization aren't particularly new or complex flaws.

Query "solarwinds access rights manager" in the ZDI advisories for a few more details of each vuln.

I try to keep the registration-wall PDFs down to about once per quarter. This one from Splunk is a CISO Report from which I wanted to grab just a handful of sentences from.

The report tracks the difference in priority between CISOs and Boards for various security factors. Four items stood out for me. The report ranks them in order of disparity (although the difference in these is at most 4%):

• “Percentage of systems with up-to-date patches”
• “Mean time to respond or remediate (MTTR)”
• “Average time it takes to patch a vulnerability”
• “Number of vulnerabilities identified”

There's also one more sentence that caught my eye, “A significant percentage of CISOs in technology (42%) cite vulnerable systems that were unknown, unmanaged or misconfigured.”

I've been repeating lately how appsec is too preoccupied with vulns, especially the volume of known vulns (i.e. CVEs) in dependencies. I won't try to build an entire case out of that single sentence, but I do think it speaks to the importance of asset management and the opportunity cost of appsec taking up the time of developers to patch low-risk vulns at the expense of more strategic work like asset inventories.

It's been a while since we pulled in a crypto (as in not cryptography) vuln. Our recent discussion about "business logic" in episode 255 reminded me that many crypto hacks are excellent examples of attacks against an app's workflows and features. They're excellent case studies in threat modeling an app's features and identifying potential abuse that isn't about some generic input validation, XSS, or top 10 item.

There's an abundance of these kinds of flaws. Check out https://web3isgoinggreat.com for the latest in bugs, bounties, scams, and security failures in this space.

Exim fixed some bugs, patch your software, and don't run your own MTA unless you have specific and deliberate reasons for doing so.

This was a quick article where the project's deprecation plan caught my eye, “All versions of Exim previous to version 4.96.2 are now obsolete. The last 3.x release was 3.36. It is twenty years obsolete and should not be used.”

There's plenty of apps out there relying on software that's barely two years obsolete. I don't really have any more in-depth commentary on this one other than I wish there was a shift in appsec to encourage more time spent on maintaining pace with recent semver versions as opposed to throwing tons of CVEs (and CWEs and CVSS and EPSS and SSVC and other acronyms) at developers.

Ok, I actually do have more of a question than a comment:

• When do you have the luxury of deprecating all prior versions?
• When do you have the obligation to provide security support for prior versions?

The announcement takes you to the guidance's home, which elaborates on some of the changes -- "It expands on the three principles which are: Take Ownership of Customer Security Outcomes, Embrace Radical Transparency and Accountability, and Lead From the Top."

I've got some reading to do before the show (give a listen to find out how far I get), but the update looks like it's bringing in a security culture beyond just software design.

It's been far too long since I highlighted a tool, so here's one to restart that habit.

"Hackvertor is a tag-based conversion tool that supports various escapes and encodings including HTML5 entities, hex, octal, unicode, url encoding etc."

Interesting post on the oss-security mailing list: Apparently it's possible for any script (think: JavaScript) to write to the "primary selection" - eg what's usually highlighted text that a user (usually) selects to copy into their copy/paste buffer. Theory here is a malicious user could leverage this to copy an attack payload in there and get a user to execute it.

This is only when ff is running on X11. Firefox isn't considering this to be a vulnerability at this point.

I think I've covered similar stories before, but I find it always worth thinking about: We always talk about how does one write software that is easy to troubleshoot, test, and deploy, but...

What considerations does one make for remote software - at the datacenter, or your home when you're on vacation and a friend is house-sitting?

How about when your software is 20,000,000,000km away?

The Rowhammer folks are back with another bitflipping attack, this time by holding a DRAM row open for reads long enough to cause consternation in nearby rows. This bypasses RowHammer protection (which looks for patterns of multiple open/closes on cells)

Of note, RowPress... 1) affects chips from all three major DRAM manufacturers, 2) gets worse as DRAM technology scales down to smaller node sizes, and 3) affects a different set of DRAM cells from RowHammer and behaves differently from RowHammer as temperature and access pattern changes.

Mike and I were on a panel with Jay Jacobs from Cyntia last week, and one item came up (off-air) that I thought would be fun to bring back to ASW: We talk about MTTR as a metric for deciding if a vulnerability management program is effective, but a core question arises: Is MTTR actually any good?

Part of the problem is calculating MTTR can be quite difficult, as we usually don't know when a individual issue was discovered, or mitigated. Do we use mean, or median? Jay runs through three methods to do the math, but the the takeaway - at least for me - is to not just take a metric at face value