Go Vuln Project, OSS-Fuzz Successes, No More Basic Auth, NSA Supply Chain Hardening – ASW #211

Having a tool like govulncheck maintained as part of the core Go toolset is a welcome step towards software composition analysis for the language. The most interesting aspect of this is the project's stance on severity -- they explicitly avoid making any qualitative or quantitative statements on a vuln's impact. Instead, the take a descriptive approach to flaws and shift the decision of severity to the devops or appsec team who has more context about the affected environment. It's a sort of shift left for vuln triage that, in this case, is likely to be more successful due to the integrated nature of the tooling (it's part of the native Go ecosystem) and the (currently) relatively low amount of known vulns.

Since its launch in 2016, OSS-Fuzz has identified and helped fix "more than 8,000 security vulnerabilities and more than 26,000 other bugs in open source projects..." That's an amazing number and one that would be really fun to explore in terms of severity of issues found, classes of issues, the time spent on creating the fuzzers, as well as the time spent fixing all those bugs. In other words, how does the investment in fuzzing pay off compared to other methods? Speaking of classes of issues, most fuzzing identifies memory-safety flaws. This article shows how work on new sanitizers -- modules that target different types of security issues -- is paying off with the identification of a command injection flaw. Not only is this a great result for the initial investment in creating new sanitizers, it also demonstrates that fuzzing will effectively reach beyond the classic problems in memory unsafe languages and be applicable to the modern world of Go, Rust, and others. Here's another article about it from The Record, https://therecord.media/google-touts-fuzzing-open-source-tool-after-discovering-tinygltf-bug/

I included this article not so much to talk about Exchange, but to talk about authentication protocols, standards, and deprecating features. Basic Auth sends a secret in cleartext -- we have much better design patterns now, such as signed requests, that never expose a shared secret beyond the initial agreement on what the secret should be. As an exercise for out listeners, what are some other standards like Basic Auth that you'd love to see removed from modern web stacks and otherwise relegated to a history of unwise design choices?

Use this guidance to inform the Secure SDLC program you need to create or to refine the one you already have. Yes, it has headings like "Develop Secure Code", which are simple to say and difficult to execute on. But the guidance is solid and provides a helpful framework for enumerating and prioritizing work to protect the code you write, the code you consume, and the ultimate software artifacts you create. Check out the press release and guide at the following links: - https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3146465/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/mc_cid/e254c17a31/mc_eid/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/ - https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF (pdf)

Yes, NCC Group does lots of pentesting, so it's no surprise they would reflect on their work and how it relates to modern appsec practices. What appealed most to me was the future of pentesting -- how to adapt to orgs that are seeing diminishing returns from periodic manual analysis.

Ok, I mostly included this article because for once a picture of container ships was used to illustrate the topic of security for actual container ships (and where they dock). The article is about OT and Industrial IOT, not the cliched graphic references to Linux container security or Docker. I also included it as a way to talk about how different operating environments and expectations influence security decisions. Ports are unlikely to accommodate agile practices and ad hoc updates, ships even less so.

Look at this article as a companion to the "Why Ports Are at Risk of Cyberattacks" also included in this episode. In this case, the environment includes federated systems owned and managed by a wide variety of operators, all of which must meet basic security practices. It's a sort of hardware manifestation of how to manage and secure a vast amount of microservices.

This is a fun article about exploiting 20+ year old software. It's also a wonderful exercise in protocol analysis that's easy to follow. The author writes well, provides many examples, and is looking largely at human-readable text within TCP and HTTP packets. Even if the target is two decades old, the techniques are all relevant and applicable today -- just think of the HTTP request smuggling we've talked about a few times already this year. Check out the blog post at https://xcellerator.github.io/posts/tetsuji/

This article comes from July and covers some technical and policy aspects of end-to-end encryption (e2e). We touch on e2e occasionally and encryption quite often. I've included this article as a reminder that e2e discussions can't just focus on technical implementations; they have product security, trust & safety, and privacy impacts. This article contributes some history and terminology to such discussions.

I think many of us have thought this, but here's somebody who can make solid statements about the state of quantum computing, when we should be worried about this, and where money is being spent - and if it should be spent. This ties back to security and appsec from a prioritization point of view - yes, this will eventually be important, but how much should be concerned in the immediate future?

This seems to be an ongoing thing, I just wonder how we get devs to think about this more?

A suggestion has been made to enable Indirect Branch Tracking by default on the Linux Kernel. Sounds like it won't affect non-Intel systems, and is a decent benefit to the Intel systems. One question, though - as we have more of these hardware-specific solutions, for an organization with heterogeneous hardware environment, how do they ensure that their applications are being protected?

Of note here, to me, is a telnet-related vulnerability. CVSS score is 2.2, but...is telnet enabled on a medical device a low-severity issue in 2022?

Previous ASW Keith Hoodlet has had some interesting appsec-related blog posts recently. His most recent talking about the maturity of security teams - and what affects that maturity - is a short but good think piece.