SSRF at a FinTech, Zoom’s Bounties, SLSA Build Provenance, & Raspberry Pi Credentials – ASW #192

Well-written description of discovering an SSRF flaw that leaked a JWT with admin credentials, which could then be used to extract sensitive data. It's a good example of the danger of making mistakes in mutual authentication between services (especially when there may be dozens of microservices) and the pitfalls of leaked security tokens. JWTs have their own drawbacks, including far-too-easy mistakes in cryptographic algorithms and a reliance on statelessness that makes revocation and rotation more difficult. For some additional information on JWT weaknesses and suggested alternatives, check out https://paseto.io.

Markdown strikes again! Well, a markdown extension. But it's still an interesting flaw that shares a theme with a pair of markdown issues we covered back in episode 187 (give it a listen at https://securityweekly.com/asw187). The exploit for this falls into the "dead simple" category and relies on a backslash and line break to fool a URI validator. The payload delivers a pipe to a command, which the server dutifully executes. It's also a useful patch that's easy to read even if you're not familiar with Ruby. And it'd make for a good exercise in threat modeling, secure coding, and reasoning through input validation. You can find the patch at https://github.com/jirutka/asciidoctor-include-ext/commit/c7ea001a597c7033575342c51483dab7b87ae155

We take a quick look at yet another company talking about its bounty awards and follow it up with one comment and one question. The comment is an observation on the cost of security when an app gets popular (and consequently receives more scrutiny) -- security is expensive (not to mention FTC consent orders). The question goes back to one we've asked before for these kinds of articles: Bounty awards give us a sense of the cost of finding flaws, what's the cost of fixing them? Presumably these are all tracked with metadata like time to remediate, lines of code changed, and probably long comment threads among DevOps and Security teams on triage and resolutions. It'd be interesting to see if there's a rough multiplier between a bounty and the developer+security hours to fix it.

It's encouraging to see SLSA continue to receive investment and demonstrations of how the framework can be implemented. This article describes a demonstration of establishing build provenance in order to gain confidence that the build hasn't been tampered with. Keep your threat models in mind as you read this -- it focuses on providing evidence of the build process and assertions that the build wasn't tampered with. The source itself is another matter (you can have a non-tampered build of tampered software). The article notes this, and SLSA itself is about the entire source-to-artifact process, so we'll highlight more articles as they come out.

This article is from the end of March and pairs nicely with the SLSA article on build provenance. The thing that stood out the most to me was the motto of, “A little copying is better than a little dependency”. Carrying this motto over to the world of NPM, it would be interesting to see what complexity or maintenance burden might diminish by applying this to popular packages like isarray or how the NPM ecosystem might have fared differently during the left-pad incident. To be fair, there's a difference between a potentially unnecessary package and avoiding the adverse actions of a package owner. But both situations can be mitigated by reducing the dependency graph.

This hits the appsec radar because availability is part of security and we don't talk about the A in CIA very often. It's also a good exercise in transparency, which provides a counterpoint to the Okta situation we covered in episode 190 (https://securityweekly.com/asw190). Finally, it gives us a second article this week that involves a pipe command and shells. In fact, it's the shell aspect that grabbed my attention. Bash programming is both concise and arcane. It's easy to pipe various utilities together and use Bash constructs to run a series of commands. But Bash can also be inscrutable, or at least carry a lot of mental cost even for those used to it. And its appeal as a "quick script" to accomplish a task can come with consequences for error handling and debugging. All of which is to say -- at what point do you replace a Bash script with something else and what criteria do you rely on to identify that point?

A small change in the default way Raspberry Pi's setup wizard handles the initial user account creation workflow. It's nice to see this change, however small it may seem, because it takes what might be a hardening checklist item (don't use default credentials) and makes the workflow reflect desired behavior (use non-default credentials, use a non-default user name). Small changes in large ecosystems can have significant positive impacts.

Cado's claiming to have discovered the first malware targeted to AWS Lambda. Several years into Lambda's existence, this sounds a little hard to believe, but let's review what they've figured out...

On the hardware side, many servers don't come with TPM modules by default. If you're the type to pick up a cheap used server on ebay (or just want to understand TPM better), this post might be of help.