Scams and Security in Web3*, URL Parsing Problems, AWS Glue, CI/CD Compromises – ASW #180

This article comes from right at the end of 2021, but it's worth highlighting as a writeup that conveys a good security-testing mindset as well as apps that get caught by parsing subtleties even when they're taking several good hardening steps. Security testers love looking for SSRF vulns because the underlying design pattern is common within web apps and these types of vulns can get good payouts in bug bounty programs. In this example, the researcher went through several hoops to identify what allow lists were in place and what defenses the app implementation to protect against SSRF. Ultimately, the attack succeeded with diligent domain analysis and a helpful backslash within the URL authority section.

An early contender for theme of the year seems to be parsing flaws and exploits that take advantage of inconsistencies among implementations. Last episode it was cache poisoning and how different tech stacks handle headers, cookies, and URL fragments (https://securityweekly.com/asw179). This episode it's all about URLS. The HTTP/2 and HTTP/3 standards are much more prescriptive about how to handle those protocols, including requirements on normalization. The RFC 3986 is clear about the syntax of a URL, but that doesn't always translate to consistent parsing (https://www.rfc-editor.org/rfc/rfc3986.html). Code not only has to be written to adhere to the RFC's expectations, but also keep up with errata. The past 2-3 years have shown how HTTP request smuggling has been a consequence of mismatched parsing and protocol interpretation. URLs look like they'll continue to cause problems as well.

Looks like this episode is covering all sorts of angles on the crypto and web3 fronts. This writeup, a casual code review, didn't identify any egregious flaws within the code -- it was a casual read after all. Setting aside the domain of the code, the writeup has some useful insights on writing code to enable easier reviews. We have SAST, of course, but such tools aren't comprehensive and still don't have good analysis of complex workflows. As the author points out, there are ways to document code to enable more effective manual review, whether it's pointing to standards that are being implemented or commenting on important sequences for code flows. Or even just having code written to be reader-friendly.

We covered a handful of articles from NCC Group last year (and another this episode). They've created a list of their 2021 work, which covers so many domains that there's surely something of interest for most readers. Some of the security tools might be useful for your own environments, the publicly reported security audits help show how to reason through different threat models and analyze how well an app fares against them, and since supply chain promises to be an eternal topic, there's a section on scaling vuln reduction and improving open source security.

Here's another year in review article, this time from the Apache Software Foundation and what they've seen in vuln reports and CVEs for their software. But the real gem is part of a quote that reminds us that creating secure software isn't where appsec ends. It's probably right at the very beginning, because as the ASF president notes, "...reports show that users are being exploited by old issues in ASF software that have failed to be updated for years". In other words, having a basic program for patching and dealing with EOL software is critical to effective security. Read the ASF report at https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report2

While summer is the big security conference season, there are still many others throughout the year. Enigma is a good one coming up in February. Consider checking it out and, if you do, let us know what presentations you enjoyed and why! We usually cover at least one or two presentations that come out of this, but we'd also love to know which ones stand out to our audience.

I'm sharing...a twitter thread this week. Web3, even! Our first web3 story of the year! There's been a good number of crypto security issues towards the end of 2021, and I plan to put the spotlight on this area more in 2022. Up first we have a tale of how a scammer was able to create a new token $YEAR which claimed to be a year in review of your eth transaction history. TL;DR: The Etherium team created a language called Solidity for developers to write contracts on the blockchain. It looks like java, but typed and a few other small improvements. While the community eyeballed the published code for $YEAR's contract, they didn't fully understand the purpose of what looked like a typo. After a few hours of the token being live, it's owner changed ownership to a uniswap contract address. This allowed token purchases to continue, but sales to be blocked. To somebody looking at a graph of the token, they'd see the price going up, and as this is a crypto token, that means they too must buy, entering the roach motel. After 30 minutes of this, the attacker cleaned out 30eth (around US$100, as of Jan 12th)

The Orca guys have been busy...

"So much work, energy, and time has gone into creating a trustless distributed consensus mechanism, but virtually all clients that wish to access it do so by simply trusting the outputs from these two companies without any further verification." The noise around this is getting louder. If you're building Web3 systems, how do you address this?

Good list from NCC, unfortunately including my mortal enemy, Docker in Docker.