Dirty Pipe, AutoWarp Vuln in Azure, TLStorm Hits UPS Devices, Car Hacking – ASW #188

We have a new named vuln that "allows overwriting data in arbitrary read-only files", which leads to "privilege escalation because unprivileged processes can inject code into root processes." It's quite a fun read that walks through a very long journey to uncover a curious bug from log files being sent to a pipe that ultimately revealed a serious security flaw -- and a one-line fix (well, technically the same line in two places) to correct an uninitialized variable. As the article notes, the name is a riff on the "Dirty Cow" vuln from 2016 (https://dirtycow.ninja).

My favorite type of article -- a clear writeup on the pentester's thought process for identifying a vuln, a vuln of consequence (gaining Root Owner access in Azure) and a path traversal.

Orca is back with another vuln in Azure and a writeup that walks through the affected service, Azure Automation, and their steps to picking apart permissions in order to gain cross-account access.

This article shows how attack surfaces change over time for attackers motivated by targeting software with huge user populations. After several decades, we've finally moved on from yet another critical Flash vuln. Unfortunately, we're still dependent on software and we're still humans writing software and there's still bugs in that software. What this article highlights is the shift from deprecated apps like Flash to other ubiquitous software like Chrome.

At first this looks like a vuln in very specific OT (UPS devices used within critical infrastructure), but poking at some of the details reveals lessons for secure development and the supply chain. The flaw boils down to an app that ignored error messages from the third-party TLS library it uses. Like lots of software, the TLS library (NanoSSL) provided cautions against ignoring error messages. Notably, it also boasted of having robust ASN.1 parsing and secure string handling with "'length strings' instead of more common 'C-length strings'" and they include fuzzing as part of their SDLC. [^1] But here we see secure code being used insecurely. As a consequence of ignoring TLS errors, the UPS devices could be tricked into loading malicious firmware -- essentially putting them under an attacker's control. So we can also add a lack of more robust firmware signing to the missed opportunities here for secure software. The TLStorm article is at https://www.armis.com/research/tlstorm/ [^1] https://www.mocana.com/press-releases/mocana-nanossl-customers-not-vulnerable-ssl-attack-revealed-black-hat -- skipping over the marketing language of this article, it's good to know that fuzzing and secure string handling was considered part of the library's development.

Sure, computers are binary, but appsec rarely is. One of the most common phrases in threat modeling and appsec commentary is "it depends". In other words, context is important for how an app is used, who is using that app, and how those users might be targeted. This is a good example that borrows from the concept of harm reduction taken from public health practices that aim to help drug users. Don't get caught up in any metaphors here. In this appsec example, the idea is that users may not have good choices available to them (such as widespread use of Signal among their peers) and therefore educate those users on how to use a messaging platform like Telegram more safely. For the appsec and DevOps side of things, understanding the threats described in an article like this is a good step towards building more secure features within an app -- something just as important as technical basics like making decisions to avoid entire attack classes (such as using memory-safe languages).

Fun video on how to start hacking CAN bus. I'm surprised he's able to get so far without other sources on the bus.

VUSec found ways past the existing protection for "Spectre class" exploits that they are calling "branch history injection." This allows fooling the CPU into leaking arbitrary kernel memory.

A reminder that us appsec guys are in a bubble, as well as a reminder to keep trying to break out of said bubble.

The headline sorta says it all, but it's interesting to consider how could we fix/stop this

Today would be a good day to make sure your package managers themselves are up-to-date.