ASW #227 – Dr. David Movshovitz

We've seen source exposed in recent breaches associated with Okta, LastPass, and Microsoft. Here's a different breach where the attackers have put a $10M value on preventing exposure of source code from a game company.

My usual response to source code leaks from an appsec perspective is to worry about hard-coded secrets, but otherwise not expect that to unleash a sudden flood of vulns. But maybe in gaming there's an added dimension of leaked source on creating new cheats or bypassing anti-cheating and anti-bot controls.

Intellectual property concerns are the same whenever a company's source is leaked. What makes one leak risker than another? I like to think of it in terms of Kerckhoff's principle, which is roughly -- the security of a crypto system design shouldn't rely on that design being secret from an attacker. In a reformulation here, the security of an app shouldn't weaken if the attacker has its source code.

It's been a while since we've seen a security issue in BIND. The generic joke about network outages and app downtime is that, "it's always DNS."

But I'm highlighting this less to talk about CVE-2022-3094 and instead bring BIND into the discussion about programming language choice and refactoring complex apps.

The History of BIND talks about why we're still on version 9 after an unsuccessful attempt to recreate it for version 10. This presentation in 2014 from Shane Kerr shares a wealth of insight into why a refactor into Python and C++ failed, from the challenges of turning prototype code into production code ("...you need real users running the code") to the demands of multiple sponsors to how the project accrued tech debt within its first year.

The presentation also provides suggestions and lessons that modern appsec and devops teams should consider when thinking about refactoring to memory safe languages like Go and Rust.

We talk a lot about refactoring code to memory safe languages, with as much emphasis on how to do as the why to do so.

So here comes an example of refactoring a service into Typescript (!?) from Go (!?).

It's an excellent, well-reasoned writeup that makes sense for the problem the team needed to tackle. Two sentences really stood out to me, "Lacking expertise in the Go stack made us shy away from making any big changes" and "Worst of all, there were very few tests!"

In other words, this was an engineering decision. It was made with security in mind, but the underlying reason wasn't something like, "We just need memory safety because appsec said so." It was a project to make a service more reliable, equally secure (if not more so), and gain confidence in its stability and correctness through better test harnesses. Well done!

We mentioned the git code audit in episode 226, but only to mention one of the findings as it related to integer issues.

Here's another interesting angle: Security flaws in C, what their implementation might look like in Rust, and how much the language might act as a safeguard for the developer.

I repeat a lot that memory safety is good, but insufficient for appsec. We've seen path traversals, authentication failures, and more within memory-safe languages. This article gives very concrete examples and insights on how Rust works, how it can minimize the impact of some insecure code, and how developers must still practice secure coding practices with it.

Yes, Chat GPT3, OpenAI, and all the AI is getting repetitive. I highlighted this because it feels like one situation where there may be both potential benefit and a reason to rely on GPT3 as a solution -- explaining risks and findings in plain language. It's easy to get caught up in jargon when talking about vulns and risks, and that jargon changes depending on cloud service provider. So having a clear, concise explanation is appealing. Let's just hope that explanation remains correct.

C and C++ code isn't going away and new code will still be written in it. This article shows how existing security-oriented tools in compilers continue to grow their coverage for major codebases.

We're talking about app logs this week, so it made sense to include a recent article on how they can be leveraged for security.

The SQL Slammer worm careened through the internet 20 years ago. (Back when style guides still had Internet as uppercase.)

As always, we look back at events like this to find lessons that can inform appsec and devops teams of today.

Additional resources:

• MS02-039
• Slammed! | WIRED
• CA-2003-04
• sapphire (an early nickname of the worm)

If we're going to mention the SQL Slammer worm this week, why not mention the premier SQL injection testing tool.

Piggybacking off of the memory safety issues highlighted in recent articles and discussions, this article breaks down what memory safety is and why it matters.

It also includes examples of the types of security vulnerabilities that exist when writing in a memory "unsafe" language, including vulnerabilities such as "Out of Bounds Read and Writes" and the "Use after Free" vulnerability.

The cyber talent pipeline is a huge cause for debate and concern among many infosec professionals. As per the Global Cybersecurity Outlook report for 2023 by the World Economic Forum: "Cyber talent recruitment and retention continues to be a key challenge for managing cyber resilience. A broad solution to increase the supply of cyber professionals is to expand and promote inclusion and diversity efforts. In addition, understanding the broad spectrum of skills needed today can help organizations to expand their hiring pools.

A number of promising initiatives are already in place, but these tend to focus on small cohorts". So what better time to get people interested in cyber than when they are children? This article outlines the resources available to young children to educate and interest them in cybersecurity from as young as kindergarten.

My personal favorite? "Threat Intelligence and Me", which has an ongoing webcomic pairing at littlebobbycomic.com

This article goes deep into three vulnerabilities found in the popular open-source library OpenEMR, which is used to manage healthcare software. Also introduced in this article is the concept of an 'exploit chain', which is when two or more vulnerabilities are exploited to cause problems.

SNYK is a SAST tool that provides source code vulnerability scanning as well as software composition analysis. While I'm somewhat new to using it, I'm impressed by its ease of use and robust secure coding educational resources.

An educational article regarding exploit chain vulnerabilities and real-world examples (such as the SolarWinds attack). This article piggybacks nicely with the exploits discussed earlier in the OpenEMR vulnerabilities.