Router Auth Bypass, Weak IoT RNG, HTTP/2 Request Smuggling, & Kindle Fuzzing – ASW #161

A week after talking about hardware hacking in episode 160 comes this write-up on *both* hardware hacking through a Universal Asynchronous Receiver/Transmitter (UART) connection and finding a classic path traversal flaw. The article helpfully walks through the basic steps of finding the communication point on the device with JTAGulator and then using the subsequent shell access to explore the device. All of this leads to some nice analysis of software running on the device. It's an easy read that will appeal to hardware and software hackers alike.

Who knew we'd have two hardware-related articles the week after talking about hardware security in episode 160? Here's an article that looks at the cryptographic suitability of the random number generator (RNG) on various IoT devices. Spoiler: the hardware abstraction layer underpinning the software calls to obtain random numbers has a weak failure mode -- in some cases returning 0. That's decidedly not a good thing when an RNG is overwhelmed with requests for numbers. The article goes into some details about what's needed for a CSRNG so that the CS part is less "completely simple" and more "cryptographically secure".

While HTTP/3 is just settling into being finalized (check out episode 153 for more), HTTP/2 is still dealing with flaws stemming from HTTP/1. Last year James Kettle shared his research on the impact and pervasiveness of request smuggling vulns. At the time, one of the security recommendations was to switch to HTTP/2. Well...the recommendation still stands, but there's a caveat -- lots of HTTP/2 servers are downgrading to HTTP/1 on the backend with predictable consequences. This is the type of flaw that's frustrating to see. After all, there's a more secure method available, but the work of moving services off of HTTP/1 and onto HTTP/2 clearly isn't finished. For more details, check out the whitepaper at https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Kettle-HTTP2-The-Sequel-Is-Always-Worse-wp.pdf

Here's an article for our fans of fuzzing. If you like to read on Kindle, patch your device. If you like to read about Kindle, this goes into lots of detail on the system's architecture, the libraries it uses to parse file formats, and the toolchain the researcher used to create a fuzzing environment. The amount of detail in the article should help you explore more about the Kindle or generalize the approach to other libraries you might have you security sights on.

Many modern app architectures rely on Kubernetes, so it's nice to see more guidance on making sure it's secure. Read the whole doc if you'd like to understand many principles within k8s and the security concerns that come with them. Or just read page 2 for a quick list of recommendations (hint: don't run as root). We're still crossing our fingers for the day when a hardening guide can be extremely successful with just the phrase, "Use the default configuration." Until then, take the time to understand the security boundaries of your k8s system, where its controls are, and how to keep it secure. The document itself is available https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF

Appsec shouldn't just be about finding vulns. DevOps teams benefit from advice and architectures that make those vulns harder to introduce. And when vulns inevitably crop up, appsec and devops teams need good strategies for how to spend their engineering budgets on fixing flaws and improving architecture. This article is more of a call to action for how Linux kernel security could be improved. Many of its ideas could easily transfer to any large software project, regardless of programming language or type of software.

It's often easier to explain how to find vulns than it is to fix them. Sure, appsec is still struggling to eradicate the ancient vulns of SQL injection and XSS despite them having straightforward solutions available in pretty much any modern programming language. There are other simple vulns whose potentially simple solutions become more complex as codebases and organizations become larger. Thus, it's important to find solutions that scale well and rely far more on automation than manual work. This example from Twilio involves a lot of manual effort to align an org on coding patterns, but with a payoff in automation and security that successfully addresses an entire class of vulns.

We often turn a dubious eye towards the utility of checklists and top 10 lists as a means of improving security. After all, they tend to be misinterpreted as standards or focus on technical risks without any consideration of business context or security strategies that make the checklists unnecessary (like using React instead of teaching a devops team about XSS). This checklist stood out for two reasons. One, almost every app has an authenticated experience and therefore needs account protections. Two, it importantly goes beyond technical platitudes (use MFA) and includes considerations of the user experience and workflows for customer service. It's always nice to see discussions centered on the product and user as opposed to just a technical rehash of CWEs or top 10 entries.

How do you research a new-ish protocol like http2? Well, first you have to write your own library so you can manipulate things to your desire. Portswigger's director of engineering James Kettle started there, and proceeded to find quite a lot of really, really bad implementations in the wild.

Similar to issues found with the javascript netmask library that we discussed earlier this year, now Rust and Go are found to have not been parsing octal formatted IP addresses correctly.

A security consultancy had a vendor ship them a "secured" laptop as part of a pentest - similar to what they'd give to their staff. The project was to see if a malicious user, if they gained physical access, could gain access to the laptop, or the corporate network. Through a fun read, we see the team at Dolos Group identify the TPM, realize they can't connect their logic probes to it, but then find an alternate way to access the TPM - without soldering or a significant amount of time (a threat metric that Microsoft mentions as to when users should use higher forms of security). In the end, it took longer to image the laptop than to gather the credentials. The appsec angle here is just because you have a TPM (or HSM - I could see similar issues there), and are using a TPM - you still need to make sure you're using it in the most secure manner. Also - glad no soldering's required, as the soldering iron isn't connected in the pic with the rework station... ???? (h/t arstechnica)