UAParser.js Malware in NPM, Squirrel Sandbox Escape, Securing CI/CD, & AppSec Videos – ASW #171

Supply chain and dependency vulns continue to be the usual appsec suspects for 2021. This UAParser.js package is clearly popular, making it a prime target for malware. The scenario seems straightforward and unsurprising: the developer's account was compromised and used to merge malicious code. It doesn't appear that the account was protected with multi-factor auth, so that's likely step one for ensuring your own environment is resistant to this type of threat (tip: use FIDO keys for your MFA). Nor does it appear that the project required signed commits -- although that might have been subverted anyway depending on how the keys were managed. It also raises another question: How many of these dependencies and libraries are really needed in the first place? Have we created false expectations around browser fingerprinting and versioning where instead we should be pushing for capability checks and feature detection? How much has the attack surface of our apps grown through code that we never really need? Check out the comment thread about the compromise at https://github.com/faisalman/ua-parser-js/issues/536#issuecomment-949742904

Last episode we talked about games and their threat models around cheating. Here's another type of vuln reported in a sandbox environment used by games, but whose root causes look familiar for many application domains. In this case, the popular Counter-Strike: Global Offensive game relies on a scripting language for players to develop custom modes and maps. Abstracting these types of modifications into a simpler scripting language is desirable because it's more accessible to players. It's also a means to attempt to reduce the attack surface and complexity of taking arbitrary C code from unknown creators and running it in the trusted environment of your own system. However, the language even has cautions about its security model and hasn't been actively maintained for about 5 years. This is the type of situation where a threat modeling discussion may lead to discussing when it's appropriate to fork a project in order to prevent it from becoming a liability. You can find the Squirrel project at http://squirrel-lang.org/

We rarely talk about SQL injection on the show for a few reasons -- it's increasingly rare in modern apps given the popularity of non-SQL datastores, modern web frameworks better enforce parameterized queries or use abstractions like ORM, and the techniques for exploiting them haven't really evolved much (largely because they don't need to). This article starts out with a SQL injection technique known since at least 2013. But memories are short and there's a lot of web hacking techniques to keep track of, so seeing how scientific notation can be used to manipulate SQL injection queries is pretty fun. (Plus, we always talk about the ancient vuln of path traversal, so it seems fair to mention and occasional SQL technique.) The point of the article is to highlight creativity in bypassing WAF rules and alerts. There's no new danger to queries that are properly handling parameters, but if you're running a WAF, it's a good way to revisit your expectations about what the WAF should be doing and what you're relying on it for.

Here's an article that lays out some actionable recommendations for securing the CI/CD process. It's always helpful to see a list that is more useful than generalizations like "write secure code", but getting into specifics also opens up decisions about what's right for the context of your own org. For example, do you even run SAST and, if so, when would you break a build? Do you have any security controls that would break a build? Do you check artifacts into a repo or do you track signed artifacts in a datastore? All of these are good departure points for improving the maturity of your DevOps practices -- and it's these practices that lead to better appsec, possibly without even needing an appsec team at all. For a similar list of security checks, take a look at what the Open Source Security Foundation has developed at https://github.com/ossf/scorecard

L0phtCrack is an ancient tool in appsec terms. It's notable, of course, for its provenance from L0pht, who were influential in creating the appsec space back in the 90s and creating infosec companies that remain part of the infosec industry today. L0phtCrack was also well known for putting theory to practice in demonstrating just how poorly Microsoft designed and implemented the original NTLM password hash. Briefly, passwords couldn't be longer than 14 characters and passwords were broken into two seven character halves to be hashed. In other words, an eight character password became two separate hashes of a seven character password and a one character password. While cracking password hashes still has some relevance for today's appsec ecosystems, there's at least a better shift towards MFA and cert-based authentication methods that has relegated the technique to a lower priority. Unfortunately, there's still a vast attack surface of app-layer vulns, phishing, and similar avenues of exploit such that obtaining a password hash is often the least necessary goal of an attacker.

While it's often a lot easier to skim and reference articles when learning about various appsec topics, watching a well-done presentation can be just as educational. In that vein, here's a 45-minute presentation from Maddie Stone about modern Android exploit techniques.

This is a great series of 30- to 50-minute presentations on various aspects of macOS security. Your appsec concerns might be focused on cloud environments and Linux systems, but it's very likely your developers are working from macOS systems. In either case, looking at threat models and exploitation techniques against other systems can be a good way to maintain creative thinking and fresh views of the apps you deal with on a daily basis. For more resources on macOS security research, check out https://objective-see.com/blog.html

Good example here to dig into the patch, think about the PR process, where the actual fix was made...

Interesting to think about: As professional coders become outnumbered by amateurs (and get to see how the security professionals have felt for years), how do professional developers and security people manage potentially less maturity in our applications?

A use-after-free webkit vulnerability was found in the playstation 4 firmware. Often it's one thing to know a vuln exists, another to be able to reliably exploit it, and then weaponize it into a jailbreak. This is part of why we suggest others to try to follow along on some blog posts, and see if they can reproduce these things themselves. It's often not as simple as it seems...