Archives

This Week In Security: Putty Keys, Libarchive, And Palo Alto

April 19, 2024 by 3 Comments

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto” →

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

April 12, 2024 by 23 Comments

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

April 5, 2024 by 11 Comments

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

March 29, 2024 by 1 Comment

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!

March 22, 2024 by 8 Comments

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

March 15, 2024 by 8 Comments

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

March 8, 2024 by No comments

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” →