Go Crypto in Practice, Excel Executes Python, Protecting Users, DARPA Distills – ASW #253

The description of “High-Assurance Go Cryptography in Practice” caught my eye.

I like the angle this takes: boring. As in no complex math, no fancy cryptosystems, just an approach to building an application that cares about memory safety, testing, fuzzing, and a few more topics.

In other words, lots of development principles that apply to more that cryptography. I particularly like the stated goal of readability.

Here's a recording from GoLab Talks: High-assurance Go cryptography.

“Scaleable” is an easy go-to word for “hard,” or “works in the real world with real users.” I like the underlying premise of articles like this -- that implementing a security recommendation isn't as straightforward as a security team might wish. What would be more interesting is understanding the design choices that go into efforts like this and how they could inform others working on similar large systems.

Facebook's blog post alludes to some of the challenges, such as shifting computing from centralized servers to distributed devices. It would be great to see a technical postmortem when it E2EE for Messenger finally launches.

I usually don't grab articles like this, but thought it'd be a way to talk about an incidental aspect of the story -- that discord is a common vector for targeting victims. There’ve also been cryptocurrency scams that have used discord as an attack vector. So, if you're discord, how might you better protect users?

Execute Python in Excel! Now, the first appsec response could be a snarky comment about how this won't end well. But I think that's exactly what preserves appsec as a "Department of No" or an unhelpful impediment to business. Sure, this sounds worrisome at first -- after all, Excel doesn't have a stellar security history. But I think that's exactly how appsec can demonstrate useful threat models and present recommendations for making those worries less worrisome.

I mostly thought of skipping this item. It's an RCE that requires user interaction and a malicious file. But it did remind me that maybe we don't talk about appsec for non-enterprise users and non-enterprise apps enough? So maybe there's an aspect and appsec where we cover UX concerns or ways to ensure apps auto-update to keep users secure?

Check out the disclosure over at the Zero Day Initiative.

More AI security coverage, more familiar security concepts (and a small marketing pitch). What I like about this is the similar vs. different framing. It feels like a nice way to approach appsec for AI without making it look like a security program would need to start from scratch.

Check out the PDF here.

This really just gets a mention because it's a path injection vuln. And a very straightforward (and impactful) one at that. The payload is dead simple: “GET /setup/setup-s/%u002e%u002e/%u002e%u002e/user-create.jsp?...”

There's still room in all those memory-safe languages for other types of flaws. Especially a very web-specific type of flaw that's been around for 25+ years.

Yes, we talked about Top 10 lists in general back in episode 242, but this episode covered a lot of LLMs and generative AI. Plus, version 1.0.1 of this top 10 list was published just two days ago.

Check out the PDF here.

They've also set up a site for the project at https://llmtop10.com.

The US Government is the largest software development organization in the world. A lot of that software they can no longer update - source lost, or received binaries only from a vendor, or the dev team is gone, etc. But still there may be reason to update the software - vulnerabilities, or just performance enhancements or migration to different hardware.

DARPA has a project (V-SPELLS - Verified Security and Performance Enhancement of Large Legacy Software) where they want to decompile binaries - to something more useful than what one would get from IDA Pro, so individuals can take the decompiled results, modify them, and recompile the application - in a safe, testable, repeatable manner. One of the teams working on this is at Georgia Tech...nothing to show yet, but perhaps we can get a team member on to discuss this work in the future!

At some level, often we can't trust the security of hardware. Case in point is key management - just because there's a trusted compute module in your hardware, that doesn't necessarily mean your keys are secure. How is your application using and handling those keys?

In the case of Windows 11, apparently it gets a key from the TPM, keeps it in memory while encrypting and decrypting a BitLocker-encrypted volume. The post author figured out how to hook a simple logic analyzer up to a few traces on his motherboard, get the data stream of the key, get that decoded and mount an encrypted volume.

There's ways to do better key handling than this, but usually at some point if the key is outside the CPU, there's a way to intercept that key...

(h/t hackaday)

The latest version of Kali is out with updates and a few new tools. One new item is Kali Autopilot, a attack automation framework that leverages the great collection of tools that they have gathered into the distro over the years.

Also, the release blog post talks about infrastructure work that the team is doing to on the mirrors packaging, build automation etc. The work of a package maintainer can be significant, so seeing them add more automation is great.