This Week In Security: BatBadBut, DLink, And Your TV Too

So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.

When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash \ to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.

And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.

Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild. Continue reading “This Week In Security: BatBadBut, DLink, And Your TV Too”

This Week In Security: XZ, ATT, And Letters Of Marque

The xz backdoor is naturally still the top story of the week. If you need a refresher, see our previous coverage. As expected, some very talented reverse engineers have gone to work on the code, and we have a much better idea of what the injected payload does.

One of the first findings to note is that the backdoor doesn’t allow a user to log in over SSH. Instead, when an SSH request is signed with the right authentication key, one of the certificate fields is decoded and executed via a system() call. And this makes perfect sense. An SSH login leaves an audit trail, while this backdoor is obviously intended to be silent and secret.

It’s interesting to note that this code made use of both autotools macros, and the GNU ifunc, or Indirect FUNCtions. That’s the nifty feature where a binary can include different versions of a function, each optimized for a different processor instruction set. The right version of the function gets called at runtime. Or in this case, the malicious version of that function gets hooked in to execution by a malicious library. Continue reading “This Week In Security: XZ, ATT, And Letters Of Marque”

This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256

The Linux command wall is a hold-over from the way Unix machines used to be used. It’s an abbreviation of Write to ALL, and it was first included in AT&T Unix, way back in 1975. wall is a tool that a sysadmin can use to send a message to the terminal session of all logged-in users. So far nothing too exciting from a security perspective. Where things get a bit more interesting is the consideration of ANSI escape codes. Those are the control codes that moves the cursor around on the screen, also inherited from the olden days of terminals.

The modern wall binary is actually part of util-linux, rather than being a continuation of the old Unix codebase. On many systems, wall runs as a setgid, so the behavior of the system binary really matters. It’s accepted that wall shouldn’t be able to send control codes, and when processing a message specified via standard input, those control codes get rejected by the fputs_careful() function. But when a message is passed in on the command line, as an argument, that function call is skipped.

This allows any user that can send wall messages to also send ANSI control codes. Is that really a security problem? There are two scenarios where it could be. The first is that some terminals support writing to the system clipboard via command codes. The other, more creative issue, is that the output from running a binary could be overwritten with arbitrary text. Text like:
Sorry, try again.
[sudo] password for jbennett:

You may have questions. Like, how would an attacker know when such a command would be appropriate? And how would this attacker capture a password that has been entered this way? The simple answer is by watching the list of running processes and system log. Many systems have a command-not-found function, which will print the failing command to the system log. If that failing command is actually a password, then it’s right there for the taking. Now, you may think this is a very narrow attack surface that’s not going to be terribly useful in real-world usage. And that’s probably pretty accurate. It is a really fascinating idea to think through, and definitively worth getting fixed. Continue reading “This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256”

This Week In Security: Loop DOS, Flipper Responds, And More!

Here’s a fun thought experiment. UDP packets can be sent with an arbitrary source IP and port, so you can send a packet to one server, and could aim the response at another server. What happens if that response triggers another response? What if you could craft a packet that continues that cycle endlessly? That is essentially the idea behind Loop DoS (Denial of Service).

This unique avalanche of packets has been managed using specific implementations of several different network services, like TFTP, DNS, and NTP. There are several CVEs being used to track the issue, but CVE-2024-2169 is particularly odd, with the description that “Implementations of UDP application protocol are vulnerable to network loops.” This seems to be a blanket CVE for UDP, which is particularly inappropriate given that the first DoS of this sort was first reported in 2009 at the latest.

More details are available in a Google Doc. There some interesting tidbits there, like the existence of cross-protocol loops, and several legacy protocols that are vulnerable by design. The important thing to remember here is you have to have an accessible UDP port for this sort of attack to take place, so if you’re not using it, firewall it.

Flipper Flips Back

We’ve covered the saga of the Flipper Zero vs the Canadian government, in the context of car theft. The short version is that Canada has seen an uptick of car thefts from organized crime. Rather than meaningfully dealing with this problem, the Canadian government went looking for scapegoats, and found the Flipper Zero.

Well now, Flipper has responded, and put simply, the message is “stop the madness”. There has never been a confirmed case of using a flipper to steal a car, and it’s very unlikely it’s ever happened. On a modern car with proper rolling-code security, it’s not meaningfully possible to use the Flipper Zero for the theft. The two primary ways criminals actually steal cars are with dedicated keyfob repeaters and CAN bus hackers.

There is a petition to sign, and for Canadians, Flipper suggests contacting your local member of parliament. Continue reading “This Week In Security: Loop DOS, Flipper Responds, And More!”

This Week In Security: Apple Backdoors Curl, Tor’s New Bridge, And GhostRace

OK, that headline is a bit of a cheap shot. But if you run the curl binary that Apple ships, you’re in for a surprise if you happen to use the --cacert flag. That flag specifies that TLS verification is only to be done using the certificate file specified. That’s useful to solve certificate mysteries, or to make absolutely sure that you’re connecting to the server you expect.

What’s weird here is that on a MacOS, using the Apple provided curl binary, --cacert doesn’t limit the program to the single certificate file. On an Apple system, the verification falls back to the system’s certificate store. This is an intentional choice by Apple, but not one that’s aimed particularly at curl. The real magic is in Apple’s SSL library, which forces the use of the system keychain.

The current state of things is that this option is simply not going to do the right thing in the Apple provided binary. It’s documented with the note that “this option is supported for backward compatibility with other SSL engines, but it should not be set.” It’s an unfortunate situation, and we’re hopeful that a workaround can be found to restore the documented function of this option. Continue reading “This Week In Security: Apple Backdoors Curl, Tor’s New Bridge, And GhostRace”

This Week In Security: Blame The Feds, Emergency Patches, And The DMA

The temptation to “take the money and run” was apparently too much for the leadership of the AlphV ransomware crime ring. You may have heard of this group as being behind the breach of Change Healthcare, and causing payment problems for nearly the entire US Healthcare system. And that hack seems to be key to what’s happened this week.

It’s known that a $22 million payment made it through the bitcoin maze to the AlphV wallet on the 1st. It’s believed that this is a payment from Change Healthcare to recover ransomed files. An important detail here is that AlphV is a ransomware-as-a-service provider, and the actual hacking is done by “affiliates”, who use that service, and AlphV handles the infrastructure, maintaining the actual malware, and serving as a payment processor. That last one is key here.

A couple days after that big payment landed in the AlphV account, a seizure notice went up on the AlphV TOR site, claiming that it had been taken down by the FBI and associated agencies. There was something a bit odd about it, though. See, the FBI did seize the AlphV Tor site back in December. The seizure notice this time was an exact copy, as if someone had just done a “save page as”, and posted the copy.

There is precedent for a ransomware group to close up shop and disappear after hitting a big score. The disruption AlphV enabled in the US health care system painted a big target on them, and it didn’t take a tactical genius to realize it might be good to lay low for a while. Pocketing the entire $22 million ransom probably didn’t hurt either. The particularly nasty part is that the affiliate that actually pulled off the attack still claims to have four terabytes of sensitive data, and no incentive to not release it online. It’s not even entirely clear that Change Healthcare actually received a decryption key for their data. You do not want to deal with these people.

Continue reading “This Week In Security: Blame The Feds, Emergency Patches, And The DMA”

This Week In Security: Forksquatting, RustDesk, And M&Ms

Github is struggling to keep up with a malware campaign that’s a new twist on typosquatting. The play is straightforward: Clone popular repositories, add malware, and advertise the forks as the original. Some developers mistake the forks for the real projects, and unintentionally run the malware. The obvious naming choice is forksquatting, but the researchers at apiiro went with the safer name of “Repo Confusion”.

The campaign is automated, and GitHub is aware of it, with the vast majority of these malicious repositories getting removed right away. For whatever reason, the GitHub algorithm isn’t catching all of the new repos. The current campaign appears to publishing millions of forks, using code from over 100,000 legitimate projects. It’s beginning to seem that the squatting family of attacks are here to stay.

RustDesk and Odd Certificates

The RustDesk remote access software is interesting, as it’s open source, allows self-hosting, and written in Rust. I’ve had exploring RustDesk as a todo item for a long time, but a bit of concerning drama has just finished playing out. A user pointed out back in November that a test root certificate was installed as part of the RustDesk installation. That root cert is self-signed with SHA1. There is also concern that the RustDesk binaries are signed with a different certificate.

There have been new events since then. First, there was a Hacker News thread about the issue earlier this month. The next day, CVE-2024-25140 was registered with NIST, ranking an insane CVE 9.8 CVSS. Let’s cut through some FUD and talk about what’s really going on.

Continue reading “This Week In Security: Forksquatting, RustDesk, And M&Ms”