Atheris Python Fuzzer, Bronze Bit Attack, & FireEye Highlights – ASW #134

Passwords have been threatened with extinction for years, yet remain the most pervasive proof of identity within apps. WebAuthn is trying to bring a new generation of hardware-backed identity proofs. Here's another example of trying to redirect the asteroid to the dinosaurs of authentication.

At first glance, it might feel like an indirect relation to AppSec, but if you're talking with a DevOps team about conducting postmortems and providing transparency on issues -- whether security or stability -- this is another good example to reference. Plus, it's a reminder that you can't prevent all breaches, so having mature detection and response capabilities should always be a part of your secure development lifecycle. Yet a followup from FireEye highlights the supply chain aspect of this compromise, firmly placing the threat into appsec territory. (https://www.fireeye.com/blog/products-and-services/2020/12/global-intrusion-campaign-leverages-software-supply-chain-compromise.html) Some more technical details on responding are available from CISA at https://cyber.dhs.gov/ed/21-01/.

IoT is notorious for insecure designs, especially in default configurations and poor authentication, so why is it also recreating vulns in well-understood protocols, especially when so much of it is reusing open source components?

This is another case where a company needs a second go-around to fortify it's first fix for a vuln. It's also another case where a company is using an embedded browser variation that ends up being less secure than just using a browser in the first place. We've gone from Java as the promised write-once run anywhere to bastardizing the browser so JavaScript can become the write-once XSS anywhere.

Google brings fuzzing to Python, taking advantage of new language features in Python 3.8 and taking the time to make libFuzzer work for as many distributions as possible -- an effort that takes the tool beyond a research effort and into a useful DevOps capability.

Another bug that was patched and needed a patch for the patch. The flaw itself stems from a subtle nuance in the interplay of encryption and signing -- and even worse when they don't have any interplay at all. Read a more detailed background of Kerberos and how this flaw affects it at https://blog.netspi.com/cve-2020-17049-kerberos-bronze-bit-theory/.

Old print driver plus user mode code in the kernel makes for a flaw reaching from Windows 10 back to Windows 7. Some interesting research revealed in Black Hat Europe that sheds light on the trade-off between maintaining legacy code vs. rearchitecting code into isolated modules.

There's an interesting thread on oss-security about what do you do with the issues found from fuzzing? It's easy to let the fuzzer rip, but do you just patch, or do you attempt to validate each issue, and create/disclose CVEs as you process the findings?

A survey of 1200 OSS contributors found that they spend 2.27% of their time on appsec, their average ideal time to spend is 2.33%. They want clear, non-noisy results so they can fix them, not to audit, and find security to be "a procedural hindrance" "best left for the lawyers and process freaks." Less than 3% of time spent on appsec, yet close to 50% are paid by their employers to work on OSS. Security subsection pages 31-33.