Typosquatting, Curl’s Security Update, & OpenSSF’s 10 Point Mobilization Plan – ASW #197

There's surely a maturity model somewhere for software projects that receive their first vuln report, first cryptographic implementation mistake, and first attack against their package management system. This typosquatting attack against Rust had little impact and on its own is mostly a curiosity. But it does point to the larger problem of managing dependencies and how attestation of packages is a problem that's agnostic to programming languages.

Two of the flaws reported to curl are fun examples of simple syntax gone wrong. One involves mishandling %2f in hostnames and the other involves mishandling cookie scopes in domains with a trailing dot. They're the kinds of bugs that look obvious in hindsight, yet understandably creep into code due to the nuances and complexity of normalizing data before operating on it. Curl is also an interesting project that has been a C implementation for decades and likely will remain that way for decades to come. The project's owner, Daniel Stenberg, has created not only one of the most useful web utilities, but also created a model for curating an open source project. Even though we're using some security flaws to talk about curl, it's not a project that's consistently plagued by flaws. Yet it could always use assistance and sponsorship to add new features and maintain the code. Find more details at https://curl.se/sponsors.html Read more about reporting security bugs in curl at https://curl.se/dev/secprocess.html

This 10 point plan, backed by financial investment to make it happen, is welcome news to the open source community. The points would also be great references for any appsec team looking to build or improve an internal secure SDLC program. Read more details at https://openssf.org/oss-security-mobilization-plan/, which also links to a PDF of the plan.

Returning to the topic of home labs and learning new security domains, here's a resource of information on reverse engineering.

We're always on the lookout for recommendations on how to build a narrative within security, whether it's pitching DevOps teams on what taking more responsibility for security means or gaining support and investment from leadership to grow security programs. Here's a summary of one of the keynotes from Black Hat Asia. We'll revisit this once the recording is available for everyone. But we also wanted to use this as a chance to ask our listeners what recent conference presentations have you seen that changed your mind on a subject? Or that inspired you to approach a problem differently and that led to success? Or even just a presentation you found insightful and entertaining?

Another summary of a presentation from Black Hat Asia. This one is about taking an attacker mindset -- a topic we like to highlight -- to previous vulns within a system in order to look for patterns or architecture weaknesses where new vulns might be found. The presentation whitepaper and slides are already available at - https://i.blackhat.com/Asia-22/Friday-Materials/AS-22-Fitzl-macOS-vulnerabilities-hiding-in-plain-sight-wp.pdf - https://i.blackhat.com/Asia-22/Friday-Materials/AS-22-Fitzl-macOS-vulnerabilities-hiding-in-plain-sight.pdf

This authentication bypass in F5 came out a few weeks ago. It's a flaw that falls into the "dead simple" category -- use a Basic Authentication header with a request that causes F5's state machine for handling user vs. admin authentication to be confused. The underlying flaw seems surprising in modern app design. Of course, this particular software stack may not be modern, but that leads to additional questions about how to migrate software architectures over time.

First responders recently were head scratching about a malicious package distributed via npm. After several days, it was discovered to be part of a penetration test a security company was doing, and that in order to be "as realistic as possible," an intern at the company uploaded the package with hopes that the pentest customer would download it. Realism is great, but how can we do this in a manner that doesn't send people into panic-response mode?

Modern iPhones continue to power bluetooth NFC, and ultra-wideband radios when the phone is turned "off," to enable "find my phone" and some payment capabilities. But...it turns out the bluetooth firmware is not signed, and there's an ability to use these radios for purposes other than intended.