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

Mike Shema

1. Go Vulnerability Management
   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.
2. Fuzzing beyond memory corruption: Finding broader classes of vulnerabilities automatically
   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/
3. Microsoft will disable Exchange Online basic auth next month
   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?
4. NSA to developers: We’ve got some software supply chain security tips for you
   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)
5. Pen Testing: Past, Present, and Future
   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.
6. Why Ports Are at Risk of Cyberattacks
   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.
7. FCC proposes cybersecurity changes to emergency alert system
   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.
8. Hacker Discovers How to Remotely Pwn a Game Boy Using ‘Pokémon Crystal’ After 22 Years
   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/
9. A Civil Society Glossary and Primer for End-to-End Encryption Policy in 2022
   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.

John Kinsella

1. Oxford physicist calls bs on quantum computing
   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?
2. 1800+ mobile apps found with hard-coded AWS credentials
   This seems to be an ongoing thing, I just wonder how we get devs to think about this more?
3. IBT to be enabled by default in Linux, maybe
   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?
4. Medical infusion pump found to have multiple remote vulnerabilities
   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?
5. What does a mature security team look like?
   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.
6. Remote root vuln found in Watchguard appliances