Opposite Direction – ASW #168

This article is a concise, clear threat model and evaluation. It brings a confluence of design focused on the user experience (use your phone to pay for transit), design choices based on business context (allow payments from a locked phone in order to prevent overcrowding due to latency and inconvenience in unlocking), and possible impacts (what compensating controls are in place to make this more difficult as a fraud vector). It's a good example of how a flaw in one part of a complex system can be mitigated by other checks, which is especially important when money is involved. Check out the research paper at https://practical_emv.gitlab.io/assets/practical_emv_rp.pdf

Although the article assumes some familiarity with Prototype Pollution and how JavaScript inheritance works through prototypes, it links to several examples of exploits that can help fill in those gaps. It also has some useful techniques for crafting payloads and demonstrating the weaknesses of pattern-based validation and the ordering mistake of doing security checks before normalizing data. For example, one exploit used the payload of "pro[]to" with the knowledge that the raw "proto" string would otherwise be blocked, but that the "[]" characters would be stripped -- turning the payload into "proto" after the security check. The researchers did a good job of identifying vulns in high-profile apps and turning what were mostly XSS exploits into a decent bounty haul. But the bigger takeaway is perhaps why this design pattern exists in the first place? Turning parameters into JavaScript objects seems like a thing to do just because it's possible, as opposed to reasoning through the security implications of serialization attacks and the challenges in avoiding this class of attack. It looks like more of a design pattern in search of a problem that introduces more insecurity than it does to serve as an effective solution.

Yeah, another week another article about supply chain and Google security. What really stands out here is that the Linux Foundation is driving constructive security hardening of open source projects with sponsorship from Google. This isn't about bug bounty awards and financing more people to point out flaws that projects already know exist or have too few devs to address. It's about getting more support to increase the security practices around those projects, of which fixing vulns is just a small part. In fact, the approach isn't something that would be relatively straightforward to adapt by orgs building their own software and who rely on open source dependencies. It's based on the SLSA framework (https://slsa.dev) and practices recommended by the Open Source Security Foundation (https://github.com/ossf/scorecard). The practices include improving how code is managed, how dependencies are managed, and getting to more mature efforts like fuzzing -- things that all software projects should be considering. Check out the program and the types of security improvements they're looking for at https://sos.dev

Making HTTPS ubiquitous is a commendable goal and something that appsec teams have been pushing for decades. This article isn't a cautionary tale of be-careful-what-you-wish-for -- it's good to have HTTPS everywhere. But what it does highlight is that making something secure and maintaining that security are two very distinct responsibilities. Let's Encrypt did a great job of making certs easy to obtain (i.e., free) and easier to maintain by popularizing the ACME protocol. But all certs eventually expire, even the root ones. And while we can predict when it will happen, the expiration date is right in the cert after all, we can't always predict what it will affect. This is also what brings out the tension in backwards compatibility and the maintenance of old software, particularly IoT devices. Such devices could still have a long life ahead of them, but they need to have a new certificate to trust in order to continue making secure HTTPS connections.

You might not have millions of lines of Android and Java code, but regardless of how many lines of code you do have, you'll want to make sure it's secure. (You might not have millions of negative press either, but that's a different topic.) When huge companies like Facebook release open source security tools, it's always interesting to see what problems they're trying to solve (scalability, it's always something something "at scale") and what security issues concern them. Another thing that usually informs these kinds of tools is the developer experience. In other words, building scanners so they integrate with workflows that devs are already using and presenting accurate vulns with remediation actions that devs can take. Even if those aren't novel concepts, seeing how they've been successfully implemented is always helpful -- and even more so if the tooling can be adopted by other organizations. Check out the announcement at https://engineering.fb.com/2021/09/29/security/mariana-trench/ and the project on GitHub at https://github.com/facebook/mariana-trench/

At ASW we're fans of fuzzing. In fact, another article this week mentions fuzzing as part of measuring a project's security scorecard. But extolling the virtues of fuzzing is a bit like saying how important an application asset inventory is -- a simple idea that's a lot easier said than done. Well, this article helps with more of the saying part and linking out to other articles that help show how it's done. If you're dealing with C code, IoT devices, or user-generated content like images, video, or HTML, then you should start planning how to introduce fuzzing to your SDLC. And even if you're building apps in memory-safe languages, fuzzing can be a natural evolution of your testing processes.

This is a good companion to the article about the https://sos.dev efforts to improve open source security. The details here are focused on GitHub, but the principles and the threat models behind it can apply to any CI/CD pipeline. If you're using any parts of the tech stack mentioned here, review the access controls, configurations, and secrets management to make sure they match the level of security you expect.

When will we (they?) learn...

I'm adding this in here to remind us that while we care about security, and developers do as well...it's not their core focus.