CVEs 4 CSPs, Malicious PyPi, Bounty Programs, Shared Responsibility, & Breach Costs – ASW #175

XSS is boring (sorry). What's interesting is how new attention to old applications can identify new attack surfaces. We saw this over the summer with the ProxyLogon vuln (https://proxylogon.com). That vuln inspired these researchers to look into Exchange in order to reproduce the issue, which is a common approach and a great way to learn and practice appsec techniques. Along the way, they discovered a reflected XSS in an error page that took some simple, clever crafting to make a payload successful. For more about ProxyLogon, check out the show notes for episode 163 at https://securityweekly.com/asw163 For more about the Exchange autodiscover issue, check out the show notes for episode 167 at https://securityweekly.com/asw167

Last episode our supply chain word of week was npm. This week it's Python. Next week it'll be -- well, let's not spoil the surprise. (Spoiler: whatever supply chain story comes out next week likely won't be a surprise.) This article stands out for how the malicious packages operated. The researchers note how these malicious packages use traffic to pypi.python.org to hide their traffic (which eventually goes through a CDN to the attacker-managed command and control server). We've mentioned more than once that controlling egress traffic for package dependencies is a good step towards hardening supply chain security. This example is a good reminder that even that level of trust can be subverted. If you're trying to further harden your dependency security by establishing a local mirror that's the only approved source for packages, this might be the article to help accelerate that work. Check out the research at https://jfrog.com/blog/python-malware-imitates-signed-pypi-traffic-in-novel-exfiltration-technique/ For more details about dependency confusion in Python, check out https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

There's a lot of "State of the [something]" style articles out there from vendors, usually behind a registration wall. Here's one in that vein from Bugcrowd and their view of the bug bounty space. When we cover bounty programs, it's usually because we're highlighting a cool vuln that a bug bounty researcher wrote up or discussing when's the right time to start a program. This article gives us a different and equally important angle. A major highlight is the demographics of bug bounty researchers, especially in age and gender. The majority of researchers are millennials and Gen Z, with Gen Z representing about half the researchers overall. This is great news for appsec as it shows continued interest in understanding how apps are built in order to better take them apart. Unfortunately, gender representation is massively skewed, with only 3% female and 1% other or genderfluid according to their report. If we're going to talk about the importance of empathy in building collaboration with appsec and DevOps teams, then we also need to talk about empathy in understanding the barriers that keep under-represented groups out of appsec or make them feel less welcome.

This probably counts as our thinkpiece-adjacent article of the week (or month?). On the heels of talking about the long list of lessons learned from the ChaosDB vulns in Azure, it seems like a good time to revisit the deeper importance of shared responsibility models. For example, we look forward to the day when hardening guides are no longer multi-page PDFs and are instead a handful of bullet points that starts off with, "Use the defaults". This is something that generalizes to more than cloud service providers -- think of complex services like Kubernetes and how secure you'd consider a default installation. In fact, this is also a tie-in to the article about cloud CVEs.

If you want to fill up your supply chain bingo card, these recordings have it all -- Solar Winds, SBOM, SLSA, SigStore, and more. We've lately been highlighting conferences with publicly available recordings. Let us know if there's a session that stands out to you or that raises lots of questions, we'd love to cover it on the show.

We'll cover the appsec-related (and privacy-related and coolness-related) presentations after the conference in February 2022. Until then, we wanted to give you a heads up that the schedule is now available and there's time to get a discounted early registration.

We naturally talk a lot about the technical details behind flaws and the tools and (automated!) processes to fix them. When we talk about threat models, we also take care to include impacts to business workflows or how a feature might be abused in a way that impacts the safety of users. Here's an article that talks about the legal and business impacts of breaches. Check out the Regulation impacts in particular -- they have direct relevance to appsec practices and a secure SDLC. These types of costs, and being proactive to mitigate them, can be important influences on an appsec program.

After finding vulnerabilities in AWS and Azure, researchers at Wiz are recommending the formation of a vulnerability database for cloud providers. The issue isn't just knowing if a vulnerability has been addressed by a cloud provider, but in some cases while they can automatically fix the issue for new subscriptions, existing users may have to reconfigure their services to get the fix themselves. So a system is needed to allow enumeration of issues. It looks like there's also some work being done by the CSA at https://universalvulnerabilityidentifier.org/ - hopefully between the two we'll get a great resource.

6M routers - apparently made by Sky? - were vulnerable to DNS rebinding attack that, combined with default known credentials, allow taking over a customer's router. h/t Zack Whittaker's https://this.weekinsecurity.com/

It's been a while since we heard of a uPNP vulnerability, but here's one which provides an RCE into an on-prem router.