Application Security Weekly #161

Sponsored By

Announcements

• Don't forget to check out our library of on-demand webcasts & technical trainings at securityweekly.com/ondemand.

• SC Media debuts its all-new SC digital experience, fully integrated with Security Weekly podcast content and more. The new site increases the scope and scale of original content resources from editorial staff, contributors, and the far-reaching CyberRisk Alliance network. Visit www.scmagazine.com to check out the new look!

Guest

Tom Hudson

Security Research Team Lead at Detectify

Tom Hudson started his career as a software engineer and got into security when a former employer invited him to the company bug bounty program. The experience landed him on the HackerOne scoreboard. Since then, Tom has become a prominent figure in the hacker community, known for his many hacking tools that he hosts on Github.

Hosts

Mike Shema

Tech Lead at Block

John Kinsella

Senior Engineering Leader at AWS

@jlk_

Announcements

• CyberRisk Alliance, in partnership with InfraGard, has launched the Critical Infrastructure Resilience Benchmark study. Measure your readiness for ransomware by completing the survey and getting your score. Visit https://securityweekly.com/CIRB to take the survey

• In an overabundance of caution, we have decided to flip this year’s SW Unlocked to a virtual format. The safety of our listeners and hosts is our number one priority. We will miss seeing you all in person, but we hope you can still join us at Security Weekly Unlocked Virtual! The event will now take place on Thursday, Dec 16 from 9am-6pm ET. You can still register for free at https://securityweekly.com/unlocked.

Hosts

Mike Shema

Tech Lead at Block

1. 1. Bypassing Authentication on Arcadyan Routers with CVE-2021–20090 and rooting some Buffalo
   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.
2. 2. You’re Doing IoT RNG
   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".
3. 3. HTTP/2 flaws expose organizations to fresh wave of request smuggling attacks
   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
4. 4. Do you like to read? I can take over your Kindle with an e-book
   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.
5. 5. NSA, CISA release Kubernetes Hardening Guidance
   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
6. 6. Linux Kernel Security Done Right
   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.
7. 7. Dependencies, Confusions, and Solutions: What Did Twilio Do to Solve Dependency Confusion
   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.
8. 8. Account Takeover (ATO) Checklist
   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.

John Kinsella

Senior Engineering Leader at AWS

@jlk_

1. 1. Portswigger’s http2 desync paints a pretty bad picture…
   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.
2. 2. We’re not finished with octal IP games yet – golang and rust latest to patch
   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.
3. 3. Stealing credentials from TPM with no soldering required
   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)
4. 4. Need more Kubernetes security recommendations? NSA and CISA have you covered