Talking Heads – ASW #150

Find My Threat Model -- Apple's AirTags are out and under scrutiny. Apple has designed some privacy protections and countermeasures to abuse, particularly the malicious use of AirTags for stalking. However, the controls largely apply to just the iPhone ecosystem. This makes for an interesting exercise in threat modeling and evaluating how effective a control really is if it requires being a part of that ecosystem and what a better default design could be. One hardware teardown, including links to additional resources and work from others on reverse engineering these devices, is at https://colinoflynn.com/2021/05/apple-airtag-teardown-test-point-mapping/ We covered some privacy-related aspects of AirDrop in episode 148. You can find the associated paper at https://www.usenix.org/system/files/sec21fall-heinrich.pdf. Many of those authors also looked into the "Find My" feature and released a paper back in March. Check it out for an overview of the protocols involved and their review of its design. You can find that paper at https://arxiv.org/pdf/2103.02282.pdf

The word of the week may be ecosystem. Qualcomm has system-on-chip modem that handles cell traffic like 4G and 5G. This modem has its own protocol for communicating with other subsystems and software components, including the Linux kernel. Researchers started fuzzing this protocol and found a service vulnerable to a heap overflow. With this in hand, it's game over for the modem's software and the integrity guarantees of Qualcomm's TrustZone, giving an attacker potential access to SMS and voice on an affected Android device. The ecosystem angle kicks in when users try to figure out if they're affected and start looking for patches from their device providers. Check out the original research at https://research.checkpoint.com/2021/security-probe-of-qualcomm-msm/ For some additional background on fuzzing TrustZone and security, CheckPoint has another article from 2019 at https://research.checkpoint.com/2019/the-road-to-qualcomm-trustzone-apps-fuzzing/

These vulns came out of a "thorough code audit" conducted by Qualys in the fall of 2020. They have new life now that an update is available from Exim. Given that at least one vuln has a description of "unauthenticated RCE" and MTAs are by nature exposed to the internet, it's time to start updating systems. Another reason this stands out is that many of the vulns affect all versions of Exim, reaching back as its roots 17 years ago in 2004. It seems even the boring services like MTAs and DNS still have some fruitful attack surface for patient researchers. And considering how many of these vulns related to memory safety issues (heap overflows, underflows, and out-of-bounds writes) and integer overflows, this is the type of software project where a refactor in another language starts to sound desirable. More details on the blog post at https://blog.qualys.com/vulnerabilities-research/2021/05/04/21nails-multiple-vulnerabilities-in-exim-mail-server

It may not be in the most popular Python package and it may have a pretty limited exploitation scenario, but it does have one of our favorite types of flaws -- directory traversal. It's a quick read and a reminder that simple flaws should ideally have simple means of detection. Whether you're running a commercial SAST, a simple linter, or something in between, the ability to identify code that handles path manipulation should be a requirement. And if you're not looking at the code itself, you can always review the environment where the code runs to ensure it's well isolated and only has access to the resources (filesystem or otherwise) it needs.

Throwing this article into the mix for its combination of two recurring themes for this episode: hardware/firmware security and flaws with long lifespans. Even if you're not running an affected system, the write-up offers insights on analyzing drivers on Windows systems. This is also a good example of how drivers have been a prominent attack vector against operating systems -- they have varying code quality, can have insufficient access control for privileged actions, and are avenues to the kernel. This class of vulns isn't limited to Windows. It's one of the motivating reasons that the Linux kernel is looking at drivers for its initial adoption of Rust within its codebase. We talked about that and another firmware vuln, Boothole, back in episode 147.

We've mentioned the CITL a few times over the years and the benefits of evaluating what steps software builders have taken to harden their binaries. They've just open sourced their tools analyzing binaries. Even in 2021 we've covered some vulns in software that didn't have basic stack protections or similar exploitation countermeasures that modern compilers and operating systems make easy to implement. CITL has some past research on browsers and operating systems; it would be great to see this expand into IoT, especially in the Industrial and OT side of things.

This article doesn't have a direct security theme to it, but it is a fun read about the transformation of code to CPU instructions. It's an accessible read despite the low-level nature. If you're been reading about Spectre-style attacks, it would add some more insight into CPU behavior. The question it brings to my mind is: Are you smarter than a compiler? In compiled languages, it's not uncommon to run into inscrutable code or code intended to be more optimal than the compiler can supposedly optimize. While there can be edge cases in high-performance computing where such source code sorcery might be required, this is a chance to advocate for the idea that readable code is secure code. Code that someone else can understand and maintain is better than clever tricks. After all, compilers have advanced enough that they not only can optimize code extremely well, they also provide sanitizers to help identify when that code runs into undefined behavior or misuses a memory address. Yet as with all things appsec, context matters -- if you're trying to zero memory in order to remove a secret, then compilers might actually be working against you unless you're using functions explicitly designed for such a purpose.

This is a brief followup on the SigStore effort we covered back in episode 143. Google has now released code to sign and verify signatures for containers. It's a good step in the spirit of "show, don't tell" for making efforts successful. Not only does this help make it easier to sign containers within the CI/CD process, but also to verify them. After all, there's no point in signing software if no one checks the signature. We've seen this kind of failure before with HTTPS and its invalid certificate errors that everyone just clicks through anyway. Check out the repo at https://github.com/sigstore/cosign

Wondering about a cloud native technology, property, or concept? Want to talk about blue green deployments until you're blue in the face and your friends are green with envy? Well, this glossary will get you started on the basics so you can understand common principles behind cloud native architectures. The structure is particularly nice because it presents each term not only with an understandable definition, but also puts it into context in terms of why it's important (the problem it addresses) and how it addresses that problem. This format, using clearly explained terms with a problem statement and solution, would also lend itself very well to threat modeling.

A bonus article for appsec archivists: The infamous "double decode" vuln in IIS was disclosed 20 years ago. This directory traversal flaw plagued unpatched web servers for several years and was absurdly trivial to exploit. Since then we've seen web servers, particularly IIS, become significantly hardened against this and other flaws. But we've also seen this attack surface shift from the web server to the web frameworks and packages running on those servers. Directory traversal might not be as prevalent now, but it still persists. Check out the advisory from Microsoft at https://docs.microsoft.com/en-us/security-updates/securitybulletins/2001/ms01-026

I'm providing this partially for discussion - is this what a k8s maturity model should look like?