[Thomas Roche] of NinjaLab is out with EUCLEAK, (pdf) a physical attack against Infineon security microcontrollers, and the security tokens that contain them. The name is a portmanteau of Euclidean and leak. And no surprise, it’s a data leak in some implementations of the Extended Euclidean Algorithm (EEA), a component of an Elliptical Curve Digital Signature Algorithm (ECDSA).

OK, time to step back. Infineon microcontrollers are the digital smart parts inside popular security tokens like the Yubikey 5, some Java smart cards, and even the Infineon TPMs. These devices all serve a similar purpose. They store one or more secret keys, and are guaranteed to never disclose those keys. Instead, they use their secret keys to do cryptographic functions, like ECDSA signatures, and output the result. There’s even a special set of tests, the Common Criteria, that are intended to backstop these guarantees. What’s interesting is that an otherwise excellent product like the Yubikey 5, that passes all these auditing and certification processes, is still vulnerable.

The actual attack is to perform ECDSA signatures while monitoring the physical chip with an electromagnetic probe. This tiny directional antenna can pick up on EM noise generated by the microprocessor. That EM noise leaks timing information about the internal state of the cryptography, and the secret key can be derived as a result.

This process does require physical access to the token for several minutes. To get useful readings, the plastic case around the security token does need to be disassembled to get the probe close enough to pick up signals. From there it’s at least an hour of post-processing to actually get the key. And most of these security tokens intentionally make the disassembly process rather difficult. The point isn’t that it’s impossible to open up, but that it’s impossible not to notice that your token has been tampered with.

Infineon has updated their libraries, doing more active countermeasures to make cryptography state indistinguishable from other CPU activity noise. If you have one of the affected devices, if a firmware update is not an option, setting a PIN or other biometric is quite effective at preventing the attack.

What might be most notable about this attack isn’t the attack itself, but that none of the test and audit framework around these devices protected against it. Our take here isn’t that those things are without merit, but instead that no certification can anticipate every way such a system could go wrong.

Revival Hijack on PyPI

We’ve repeatedly covered Typosquatting in various repositories, and even the more subtle dependency confusion over the years. Revival Hijack probably isn’t completely new, but researchers at JFrog have announced it and taken a major step towards preventing it in the PyPI repository, partially in response to finding it in use in the wild.

The idea here is pretty simple. For various reasons, packages on PyPI get deleted. PyPI makes it abundantly clear to the dev deleting the package, that among other things, the package name will become available for others to register. If someone else registers that name, and releases a new build with a higher version number, pip will gladly perform the update where the old package is installed.

The danger, of course, is that this quirk will be used to ship malicious packages. That’s not a theoretical issue, either. The pingdomv3 package was first published in 2019, retired and deleted in March 2024, and republished shortly after. Within a few days, the package was updated to include a malicious payload. Interestingly, the payload checked for a Jenkins environment, and downloaded and ran a script. JFrog’s automated monitoring caught the suspicious behavior, and PyPI removed the malicious package soon after. That one in particular got added to PyPI’s list of permanently retired package names.

Going forwards, JFrog is grabbing deleted package names with significant download counts, and holding them safely in a dedicated user account. It will be interesting to see if this attack or mitigations against it start showing up in other repositories.

SIM Card WiFi

WiFi security is a bizarre mish-mash of modern and legacy tech. Case in point, you can use a RADIUS server and a 2G SIM card to handle WiFi authentication. The authentication server generates a random challenge, and the SIM generates a signed response and temporary encryption key. It’s a cool, quirky idea, with a significant drawback. For effective authentication, the central server has to know the secret key of the authenticating SIM. Since that’s the primary thing SIMs are designed to prevent, the whole idea is of limited use, without a source for custom SIM cards.

Bits and Bytes

To really understand what a program is doing, running a system trace is hard to beat. That is a capture of every system call, which effectively captures every interaction with the rest of the system. The only real problem is that that much information is often like drinking from the firehose. To try to help with that problem, we now have Traceeshark, which loads system trace captures into Wireshark, which already has great tools for dealing with an overabundance of information.

And finally for this week, researchers at Praetorian took a look at the Rspack GitHub repository, and found several GitHub Actions vulnerabilities. GitHub Actions are automated actions in response to things like changes and pull requests. Projects often set up continuous integration pipelines in Actions, and run a test suite and build for each change. That does get a bit dicey, when running on pull requests from untrusted contributors. And that’s what was found at Rspack. New contributors could make pull requests that would automatically launch an Action run. From within the action, it was possible to leak both an NPM deployment token, as well as a GitHub Person Access Token. Whoops!