Halloween Horror – ASW #169

While we don't have specifics on the breach, Twitch has noted that a server configuration error was taken advantage of to gain unauthorized access to their systems. Among the data exposed, a few people have pointed out DB connection strings with passwords in addition to business-related info like how much money top streamers have been earning. With a leak of source code, it'll be interesting if bug bounty researchers go after vulns discoverable via source, or if other attackers find exploitable flaws to once again compromise one of Twitch's systems. This breach got a lot of coverage. Here's a sampling of additional articles: - https://threatpost.com/twitch-source-code-leaked/175359/ - https://www.zdnet.com/article/twitch-attributes-breach-to-server-configuration-error-resets-all-stream-keys/ - https://www.vice.com/en_us/article/jg8w9b/the-twitch-hack-is-worse-for-streamers-than-for-twitch

As listeners know, one of the favorite vulns here at ASW is path traversal -- it's simple to exploit, tends to be very high impact, and needs no other tooling than a browser's navigation bar. So it's pretty eventful when we see this type of ancient vuln pop up in Apache httpd server. True to form, the payloads are trivial and scanners are already using it to search for common files that might lead to further compromise of a system: - /cgi-bin/.%2e/app/etc/local.xml - /cgi-bin/.%2e/app/etc/env.php - /cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd The patch for this also fell into the category of having to release a patch for the patch in order to properly fix the vuln. It's understandably a critical vuln. Furthermore, as listeners also know, we're huge fans of fuzzing here at ASW. So it's also nice to see fuzzing help identify a moderate vuln, in this case a null pointer dereference, that was also fixed in this release. Check out the release notes from Apache at https://httpd.apache.org/security/vulnerabilities_24.html

It's amazing that a software feature from 1992 remains supported in Excel to this day. It's also tragic because these XLM macros have also been a frequently abused attack surface over the decades. Now, with an apparent spike in attacks by "top tier threat actors" against this feature, Microsoft has moved to disable this legacy feature by default. This article is a chance to reflect on when and how to make decisions on creating a secure default, deprecating a feature, or removing a feature altogether. On one hand, supporting a feature for almost 30 years is impressive. On the other hand, being consistently exploited for so long has to raise a red flag to at least rearchitect such a brittle are of code. A similarly ancient and ever-vulnerable piece of software, Flash, took almost as long to disappear from web browsers. Hopefully we'll see more acceleration in other cases so these timelines can be measured in months or years rather than decades. Now, if only we could encourage these same top-tier threat actors to target year-old unpatched vulns and weak designs in parsers, we might see further progress made by the infosec community...

We come across lots of articles that have a vendor angle to them. Sometimes that angle is implicit, sometimes explicit. This one caught the attention of ASW by the nature of the problem it was looking at combined with an open source project to help solve that problem. Making code changes, even simple ones, at scale can be tedious -- but many times those changes are necessary. Think of cases for bumping a package version or changing a configuration line for Terraform or Kubernetes to enable a more secure setting. This OpenRewrite project looks to make such refactoring possible in a safe and quick manner. Of course, code changes don't come without risk, so you'll need some robust testing and error handling to catch unintended consequences, but the idea of using automation to save developers' time has a great appeal to it. Check out more documentation at https://docs.openrewrite.org/ and the open source repo at https://github.com/openrewrite/rewrite

We pull on a thread from this article able wildcard certs to talk about the economics and incentives of application security. For the longest time, presenters at infosec and appsec conferences pointed out attacks against unencrypted HTTP traffic, to the point of trying to shame sites into adopting HTTPS. Fortunately, HTTPS has become more pervasive and unencrypted HTTP traffic is almost eradicated. Of course, there were also several flaws along the way in TLS stacks -- something we're still dealing with in the divergence of OpenSSL, BoringSSL, and other TLS stacks. But there were also costs to HTTPS adoption and security concerns in handling certs. We like certs, certs can be a big part of mutual authentication between services. So it's worth discussing some of the challenges or trade-offs that come with different certs. As an additional resource on TLS history, insights, and implementations, check out https://blog.ivanristic.com (in particular the "OpenSSL Cookbook" and "Bulletproof SSL and TLS" book). We covered ALPACA back in episode 154 on June 14, 2021.

This is the second time we've covered a blog post from Phil Venables. And while appsec is only part of a cybersecurity program, it's definitely a critical piece. It's a quick read and even if it feels like high-level advice, it should serve as a reminder that strategic architecture and preventative maintenance should be on your appsec roadmaps. That kind of focus on secure by default and tamping down legacy tech (aka paying off tech debt) may have a far more positive security impact than any appsec tool you might deploy. Oh -- and you have an app inventory to go along with that, right?

We talked about this recently, but here's an article to think about this a little more. We're hitting an imbalance of discussion around the supply chain of our source code vs the supply chain of our cloud providers.