A Forecast for Threat Groups, K8s Security Audit, GhostToken on Google, BrokenSesame – ASW #238

Microsoft is now organizing eight threat actor groups into weather phenomena. In addition to Patch Tuesday, prepare for Blizzards on Wednesday, Tempests on Thursday, and Floods over the weekend.

No forecasts with Smooth Operator, Scattered Spider, or Fancy Bears.

We like celebrating transparency here on ASW. This week it's a public report from NCC Group about their security audit of Kubernetes.

These types of reports are useful to read for their example of how to explain and summarize results of security work, learn the types of issues that security teams look for, and imagine how to apply that work to other projects. These reports don't often share the detailed methodologies and tools that the team uses, nor do they often share what security tests failed (what they found secure). But they're still informative references whether you use k8s or not.

Also, the standard ASW memory-safe language warning applies. There aren't any particularly concerning issues identified from this effort, but it does highlight that memory safety is just one type of vuln class and memory-safe languages still require secure architectures and good designs.

Compromised credentials are the best "backdoor" into a system. With improved MFA, this typically means attackers need to go for compromised cookies (since the auth/authz session cookies are post-login identifiers). Here's a scenario where this applies to OAuth tokens and, what's interesting, is that the OAuth grants can be both hidden from and unremovable by the victim.

Kudos to Wiz for finding more cloud-related security issues and kudos again to providing succinct summaries for their articles. It's hard to improve on their version, which describes the issue as, "A container escape vulnerability, combined with accidental 'write' permissions to a private registry, opened a backdoor for Wiz Research to access Alibaba Cloud databases and potentially compromise its services through a supply-chain attack."

While the article is about specific examples from C and C++, the underlying problem of typos impacting security generalizes to many languages. There's the obvious typo-squatting, but also less obvious behavior changes that might occur between testing and production due to typos in macros, execution flags, feature flags, or other things that influence code.

I also love the point at the end of the article -- this is the type of flaw that compilers should take care of by applying security mitigations automatically and by default.

I'm trying to find articles that are more than just prompt injection. Prompt injection is fun, like figuring out different XSS payloads is fun, but its impact is situational. Plus, it's not the only security implication of ChatGPT-style risks. Many of the items in this doc may feel beyond the scope of appsec, but they should land in the kind of threat modeling that appsec teams should be doing for how their org is adopting these technologies.

It's easy for us to praise codeql, but what has it done for us lately? GitHub's put together a page of vulnerabilities that were discovered with the help of codeql

Previously we recently covered a Socket's "safe npm" in ASW 234, now GitHub is introducing "package provenance" for npm - allowing publishers to publish provenance along with the package. So - basically package signing.

Is this good enough? Managing a blacklist takes more effort, but in both cases, the consumer needs to use these tools. The node/javascript community has a reputation of being lazy - will they embrace one of these tools, or does it need to be more enforced by default?

I'll confess - I don't use gdb very often...directly. Debugging is an area where I prefer pointy-clicky.

Of course in our current times, we now have gdb with chatgpt built in. It's still text based and not pointy-clicky, but might be helpful for some users...

Wiz decided to take their ball and play somewhere else, so now they're looking at Alibaba's cloud services, apparently. They've found an RCE and privilege escalation in their postgres-based analytics services.

Props to the naming department, as well - BrokenSesame!

While there's no direct security updates, AWS has updated their "well architected" framework - of which one of the six pillars does focus on security. I'm posting this mostly as a refresher to folks that it exists - by studying and following their framework(s) your resulting systems on AWS will likely be more secure.