asw161

Application Security Weekly Episode #161 – August 09, 2021

Subscribe to all of our shows and mailing list by visiting: https://securityweekly.com/subscribe

1. Securing Modern Web Apps: Development Techniques are Changing – 12:30 PM-01:00 PM

Sponsored By

sponsor
Visit https://securityweekly.com/detectify for more information!

Announcements

  • 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!

  • Join us August 26th at 11am eastern to learn how to implement cloud security that actually works. If you missed any of our previously recorded webcasts or technical trainings, they are available for your viewing pleasure at https://securityweekly.com/ondemand

Description

The use of web apps, SPAs, and APIs are growing steadily and traditional scanning methods don’t provide enough coverage. The appsec tools need to innovate and become smarter and more contextual in order to test modern apps and APIs at scale. Tom Hudson, Security Research Team Lead at Detectify, will give a peek into how Detectify is innovating to help solve these modern app and API developer challenges.

Segment Resources:

– Sign up for updates and be the first to know about Detectify API scanning open beta: https://www.detectify.com/api
– Blog post announcing Detectify’s plans to expand scanner to fuzz public-facing APIs: https://blog.detectify.com/2021/08/03/detectify-fuzzing-public-facing-apis/

This segment is sponsored by Detectify.

Visit https://securityweekly.com/detectify to learn more about them!

Guest(s)

Tom Hudson

Tom Hudson – Security Research Team Lead at Detectify

@tomnomnom

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

JohnKinsella

John Kinsella

@johnlkinsella

Chief Architect at Accurics

MikeShema

Mike Shema

@Codexatron

Product Security Lead at Square

2. Router Auth Bypass, Weak IoT RNG, HTTP/2 Request Smuggling, & Kindle Fuzzing – 01:00 PM-01:30 PM

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

  • Security Weekly Unlocked will be held IN PERSON this December 5-8 at the Hilton Lake Buena Vista!

    We are excited to announce our first round of speakers: David Kennedy, Alyssa Miller, O’Shea Bowens, Marina Ciavatta, Patrick Coble, Chris Eng, Eric Escobar, Kevin Johnson, and Justin Kohler!

    Visit https://securityweekly.com/unlocked to register and check out our rockstar lineup!

Description

This week in the AppSec News: Hardware hacking for authn bypass and analyzing IoT RNG, Request Smuggling in HTTP/2, Kindle Fuzzing, Kubernetes Hardening, Countering Dependency Confusion, ATO Checklist, & more!

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Chief Architect at Accurics

  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. 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. 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. Need more Kubernetes security recommendations? NSA and CISA have you covered
MikeShema

Mike Shema

@Codexatron

Product Security Lead at Square

  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. 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. 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. 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. 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. 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. 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. 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.