Okta & LAPSUS$, Fuzzing Rust, SQL Injection & Stale Code, Log4j Lessons – ASW #190

We'll touch on a few lessons that can be drawn from this breach. A big one that stands out to me is the importance of effective communication that provides transparency, actionable details, and a reasoned explanation of risk. While the breach may have impacted over 300 of Okta's customers, it also seems to have led to over 300 articles written about it. Here's a sampling of additional items on the topic: - https://krebsonsecurity.com/2022/03/a-closer-look-at-the-lapsus-data-extortion-group/ - https://www.microsoft.com/security/blog/2022/03/22/dev-0537-criminal-actor-targeting-organizations-for-data-exfiltration-and-destruction/ - https://www.zdnet.com/article/microsoft-confirms-lapsus-hit-account-with-limited-access-after-gang-released-alleged-bing-and-cortana-source/ - https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/ - https://www.bbc.com/news/technology-60864283 - https://www.philvenables.com/post/insider-threat-blast-radius-perspective-updated -- This is in fact from August 2020 and not specifically about the Okta breach, but it's a great summary of how to approach mitigating the type of threat demonstrated by the breach.

As much as we love advocating for languages that address classes of vulns, specifically memory safety issues, we're just as empathic about pointing out that there are plenty of other security issues beyond buffer and heap abuse. This flaw in Rust could lead to a local DoS via a user-supplied regex. It's not necessarily the most exciting flaw, nor is the type of flaw new. What is relatively new is how fuzzing is being used to identify these types of issues. It's great to see investments in fuzzing produce meaningful improvements to software security. Be sure to read the Rust advisory as well at https://groups.google.com/g/rustlang-security-announcements/c/NcNNL1Jq7Yw

If you enjoy hacking on the Linux kernel, debugging multithreaded programs, or analyzing race conditions, then this article is for you -- the rest of us will skip these headache-inducing topics and move on... But there's another aspect of this article I wanted to call attention to that's independent of the C code and CPU details. The article uses several graphs to demonstrate data collected during the analysis and a set of simpler graphs to demonstrate the underlying concept of race conditions. Visualizations like these can be really effective at enriching text and help readers understand complex topics. If you're working on your own write-ups about vulns, flaws, recommendations, or any metrics, strive to include simple, well-designed visualizations to help tell your story.

For me, SQL injection is barely yawn-worthy these days. It feels like it should be a thing of the past and any modern flaw must be (well, one hopes...) due to legacy code. Which is the angle I wanted to take with this article -- lots of infosec articles like to include metrics like CVSS scores (a perfect 10!), the number of times an app is downloaded on a weekly basis, or how many results for an app comes back from a tool like Shodan. These are rough indicators of popularity and impact, but rough and often with too many confounding variables to be of any real uses other than to paint a picture of "this is an important vuln". On the other hand, I'd be curious to see metrics for vulns related to age of the code base, such as date of the commit that first introduced the vuln, date of the last commit to the affect file, and date of the last commit to the affected repo. To me, those can build a picture of how well maintained the codebase is and whether security tools -- if they're being run at all -- are providing quality results.

NSA and CISA first released this hardening guide back in August 2021 and have now released an update based on industry feedback. We covered the first release, with the sentiment of, "This is great work, but wouldn't it be nice if a hardening guide consisted of a single page that said to use the default configuration?" That sentiment still stands; it'd be great for hardening guides to shrink as default secure configurations expand. Even so, if you're not familiar with kubernetes security, reading a hardening guide like this is a great introduction to important concepts. The guide includes a lot of the "why" a hardening step is useful, which helps the reader gain more knowledge about the design assumptions of kubernetes rather than just being a dry checklist of steps to go through.

I'm highlighting this article to talk about the aspect of log4j as an indicator of the state of appsec, patching, and app inventories. The technical aspects of log4j aren't as important for this discussion. What's really scary -- and something to remember as we talk about the best modern tools and DevOps approaches -- are observations like 50% of installations impacted by log4j were flagged as end of support. The cloud isn't immune, with Qualys detecting 68,000 vulns in cloud workloads. If there's one metric that feels like a positive trend, it's that the average remediation time was 17 days. I'd love to know more about this remediation metric, such as what the median time was and if there was a distinction in remediation times between applying a patch vs. having up update a dependency.

Lots of software uses zlib. Lots. Here's a chance to discuss risk, the distinctions between impact and likelihood, and why patching is important regardless of whether this may become a "really bad bug".

I've always been a fan of compiler-driven security improvements, especially the various sanitizers that LLVM makes available for compile-time and run-time analysis. And I've always been suspicious of "clever" code that attempts to outsmart a compiler or that's written for the compiler to understand better than a human reading it. But it's also important to realize when compilers are working against you, such as the classic "dead code" that just zeroes memory -- when zeroing memory is in fact important for scrubbing secrets. This is a great article that lays out specific recommendations for improving the state of compiled binaries.

Several flaws were announced this week in Sophos, including a CVSS 9.8 authentication bypass and RCE in the web admin console.

While the title is slightly click-baitey, the idea the author's trying to get across is C is almost a "protocol" for all other languages to be based upon. The appsec link here is the complexity included by depending up on C libraries increases the exposure for vulnerabilities.