This Week In Security: EUCLEAK, Revival Hijack, And More

[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. Continue reading “This Week In Security: EUCLEAK, Revival Hijack, And More”

I2C For Hackers: Digging Deeper

Last time, I gave you an overview of what you get from I2C, basics like addressing, interface speeds, and a breakdown of pullups. Today, let’s continue looking into I2C capabilities and requirements – level shifting, transfer types, and quirks like combined transfers or clock stretching.

Level Shifting

Continue reading “I2C For Hackers: Digging Deeper”

Art of 3D printer in the middle of printing a Hackaday Jolly Wrencher logo

3D Printering: Switch And Klip(per)

Last time I tried to convince you that, if you haven’t already, you should try running your 3D printer with Klipper. There are several ways to actually make it work.

The first thing you need is something to run the Klipper host. Most people use a Raspberry Pi and if you already have one that runs OctoPrint, for example, you might well use it. Just tuck your SD card away in case you give up and install a fresh Linux system on a new card.

The Creality Sonic Pad has issues, but it does work.

However, a Pi isn’t your only option. You should be able to make it work on nearly anything that runs Linux. We’ve even seen it running on Windows under WSL. If you have an old laptop that can run Linux, that would work, too. We’ve even heard it works on a Chromebook.

The other option is to get a “pad.” Several vendors make touchscreens with some Linux single-board computer bundled together with Klipper preinstalled. For example, there is the Creality Sonic Pad, along with similar devices from other 3D printing companies.

If you decide to go that route, you might want to make sure it is easy to install your own software easily. Some pads, like the Creality unit, are notorious for having so much customization that they don’t lend themselves to upgrades unless they come from the manufacturer. In some cases, you can wipe out the stock firmware and install a normal operating system, but at that point, you could probably just buy a Pi and a touchscreen, right?

Continue reading “3D Printering: Switch And Klip(per)”

Hackaday Links Column Banner

Hackaday Links: September 1, 2024

Why is it always a helium leak? It seems whenever there’s a scrubbed launch or a narrowly averted disaster, space exploration just can’t get past the problems of helium plumbing. We’ve had a bunch of helium problems lately, most famously with the leaks in Starliner’s thruster system that have prevented astronauts Butch Wilmore and Suni Williams from returning to Earth in the spacecraft, leaving them on an extended mission to the ISS. Ironically, the launch itself was troubled by a helium leak before the rocket ever left the ground. More recently, the Polaris Dawn mission, which is supposed to feature the first spacewalk by a private crew, was scrubbed by SpaceX due to a helium leak on the launch tower. And to round out the helium woes, we now have news that the Peregrine mission, which was supposed to carry the first commercial lander to the lunar surface but instead ended up burning up in the atmosphere and crashing into the Pacific, failed due to — you guessed it — a helium leak.
Continue reading “Hackaday Links: September 1, 2024”

Hackaday Podcast Episode 286: Showing Off SAOs, Hiding From HOAs, And Beautiful Byproducts

Even when the boss is away, the show must go on, so Dan slid back behind the guest mic and teamed up with Tom to hunt down the freshest of this week’s hacks. It was a bit of a chore, with a couple of computer crashes and some side-quests down a few weird rabbit holes, but we managed to get things together in the end.

Tune in and you’ll hear us bemoan HOAs and celebrate one ham’s endless battle to outwit them, no matter what the golf cart people say about his antennas. Are you ready to say goodbye to the magnetic stripe on your credit card? We sure are, but we’re not holding our breath yet. Would you 3D print a 55-gallon drum? Probably not, but you almost can with a unique Cartesian-polar hybrid printer. And, if you think running MS-DOS on a modern laptop is hard, guess again — or, maybe you just have to get really lucky.

We also took a look at a digital watch with a beautiful display, a hacked multimeter, modern wardriving tools, switchable magnets, and debate the eternal question of v-slot wheels versus linear bearings. And finally, you won’t want to miss our look at what’s new with 3D scanning, and the first installment of Kristina’s new “Boss Byproducts” series, which delves into the beauty of Fordite.

Download the DRM-free MP3.

Continue reading “Hackaday Podcast Episode 286: Showing Off SAOs, Hiding From HOAs, And Beautiful Byproducts”

This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA

We finally have some answers about the Windows IPv6 vulnerability — and a Proof of Concept! The patch was a single change in the Windows TCP/IP driver’s Ipv6pProcessOptions(), now calling IppSendError() instead of IppSendErrorList(). That’s not very helpful on its own, which is why [Marcus Hutchins]’s analysis is so helpful here. And it’s not an easy task, since decompiling source code like this doesn’t give us variable names.

The first question that needs answered is what is the list in question? This code is handling the option field in incoming IPv6 packets. The object being manipulated is a linked list of packet structs. And that linked list is almost always a single member list. When calling IppSendErrorList() on a list with a single member, it’s functionally equivalent to the IppSendError() in the fixed code. The flaw must be in the handling of this list with multiple members. The only way to achieve that criteria is to send a lot of traffic at the machine in question, so it can’t quite keep up with processing packets one at a time. To handle the high throughput, Windows will assemble incoming packets into a linked list and process them in batch.

So what’s next? IppSendErrorList(), takes a boolean and passes it on to each call of IppSendError(). We don’t know what Microsoft’s variable name is, but [Marcus] is calling it always_send_icmp, because setting it to true means that each packet processed will generate an ICMP packet. The important detail is that IppSendError() can have side effects. There is a codepath where the packet gets reverted, and the processing pointer is set back to the beginning of the packet. That’s fine for the first packet in the list, but because the function processes errors on the entire list of packets, the state of the rest of those packets is now much different from what is expected.

This unexpected but of weirdness can be further abused through IPv6 packet fragmentation. With a bit of careful setup, the reversion can cause a length counter to underflow, resulting in data structure corruption, and finally jumping code execution into the packet data. That’s the Remote Code Execution (RCE). And the good news, beyond the IPv6-only nature of the flaw, is that so far it’s been difficult to actually pull the attack off, as it relies on this somewhat non-deterministic “packet coalescing” technique to trigger the flaw.

Continue reading “This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA”