It’s time to strap on our propeller beanies, because we’re going to talk crypto. The short version is that some SSH handshakes can expose enough information for a third party to obtain the host’s private signing key. That key is the one that confirms you are connecting to the SSH server you think you are, and if the key validation fails, you get a big warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

The math that makes this warning work is public-private key cryptography. The problem we’re talking about today only shows up in RSA authentication. Specifically those that use the Chinese Remainder Theorem (CRT) to quickly calculate the modulos needed to generate the cryptographic signature. If something goes wrong during that calculation, you end up with a signature that is mathematically related to the secret key in a different way than intended. The important point is that knowing this extra value *significantly* weakens the security of the secret key.

This attack has been known for quite some time, but the research has been aimed at causing the calculation fault through power vaults or even memory attacks like Rowhammer. There has also been progress on using a lattice attack against captured handshakes, to make the attack practical with less known information. The real novel element of this week’s approach (pdf) is that it has been tested against SSH.

The paper’s authors performed weekly scans of the entire IPv4 public network space, capturing the handshake from any listening SSH server, and also had 5 years of historic data to draw from. And the results are mixed. There is a Cisco SSH server string that is extremely common in the dataset, and only once did one of these machines send a miscalculated handshake. Possibly a random ram bit flip to blame. And on the other hand, the string “SSH-2.0-Zyxel SSH server” had so many bad signatures, it suggests a device that *always* sends a miscalculated signature.

If an adversary is able to recover a server’s private host signing key, this does
not give the adversary the ability to decrypt passively collected SSH
connections to the compromised host….

It’s vital to understand what this does and does not allow. A server certificate that is compromised through this attack can be used to impersonate that server, making Man-in-the-Middle (MitM) attacks dangerously effective. On the other hand, this does not allow decryption of SSH sessions. It does not allow access to SSH services. And the most common SSH daemon, OpenSSH, has mitigations against sending these miscalculated signatures.

FTP Part 1

Progress has a lineup of developer tools, and among them is WS_FTP. This business-grade FTP server had what we’ll charitably call an undocumented feature: arbitrary file upload to the OS file system. The good news is that it only affects servers with the Ad Hoc Transfer Module turned on, and does require authentication. The bad part is that anywhere on the filesystem, and that’s an obvious recipe for problems, earning this issue a CVSS of 9.1. Thankfully the issue was found privately by Progress engineers, and the fix was offered in the November. There is also an official workaround, to disable just the offending module.

FTP Part Deux

Yet another FTP implementation, CrushFTP, had a serious vulnerability. CVE-2023-43177 is a weird issue that starts with a 404 error also returning a valid session cookie for the “anonymous” user. Anonymous has no privileges, but does pass the code checks for having a valid username. That’s the quirk that makes this one an unauthenticated attack. The real flaw is that if the AS2-To header is present in one of these pseudo-authenticated requests, all the request headers get sucked into the user-info object. That object includes some important data, and the logic flaw makes all of it writable. That seems like it should be the vulnerability, but some decent security hardening makes it difficult to directly exploit.

The next step is to harness another function, drain_log(), which can copy a file to any location, append some XML, and delete a file. That appended XML is a huge problem for exploitation, but it turns out there’s one of those overwritten items that can turn off the extra XML. Now we have an interesting primitive — move any file to any location, deleting the source location. This is used to leak the sessions.obj file, which contains session tokens for logged-in users. With a valid user, arbitrary files can be uploaded, and then moved with the previous primitive, allowing for easy overwrite of any file on the system.

There are two final notes on this story to make. First, the CrushFTP developers pulled off an overnight turnaround on getting this issue patched. So many big companies take 89 days on a 90-day disclosure, the timely fix is refreshing. And secondly, in the Converge write-up, I was struck by the statement: “Converge security researchers responsibly disclosed a critical unauthenticated zero-day vulnerability.” There’s the obvious, that this was an attempt to put as many impressive-sounding buzzwords in a summary as possible. But I have to point out that “responsibly disclosed” and “zero-day” are mutually exclusive. If it was responsibly disclosed, it was not used as a 0-day.

Reptar on Ice (Lake)

There’s a weird glitch in some Intel processors, and the CPU security ninja himself, [Tavis Ormandy], has the story. X86 instructions are a bit… arcane. You can have an instruction, and add a prefix to make it do something a bit different. For example, rep movsb is the memory moving movsb, repeated several times. The fun part is that you can add that prefix, well, repeatedly. rep rep rep rep movsb is perfectly valid assembly, and is actually really useful for getting binary contents to line up the way it needs to.

There’s another interesting prefix, rex, the register extension, used to stuff even more register data into a single instruction. When that extra data isn’t needed, the rex prefix is ignored just like the rep prefixes. At least that’s the idea. It turns out that on Ice Lake and later, a movs instruction with both prefixes does something squirrelly to internal processor state. After this instruction, various strange behavior is witnessed, usually ending with a halt or exception. It seems like yet another example of memory corruption inside the CPU internals. Fun!

While [Tavis] and company didn’t manage to turn this into an actual exploit, Intel’s advisory seems to indicate that such an attack would be possible. There’s a decent chance your OS has already shipped the microcode that fixes this, and BIOS updates are rolling out, too.

Bits and Bytes

Microsoft is tired of authenticator spam. That’s essentially an attack where multiple authenticator requests get sent, and the attacker hopes the user will get confused or overwhelmed, and approve the request. So now, on the Microsoft Authenticator, potentially spammy authenticator requests are silent, and requests that are more likely to be legitimate are given priority.

What’s worse than getting hit with a data breach? Getting reported to the SEC by your attacker, apparently. This is really adding insult to injury, though chances are there’s more to this story. Maybe the perpetrators shorted the company stock before making the filing? Who’s to say? (Probably the FBI.)

There’s a twenty year old vulnerability in Windows that just got fixed, and it’s unfortunate that this one didn’t come in early enough to get full coverage. The vulnerability is triggered by the Web Speech API. As Chromium doesn’t natively implement a Text-To-Speech (TTS) service, this API results in calls outside the browser sandbox. The bug is in an XML parser used to parse the Speech Synthesis Markup Language. It’s a wild ride, and worth a read, even though we ran out of time and space to cover it fully here.