Writing for Hackaday involves drinking from the firehose of tech news, and seeing the latest and greatest of new projects and happenings in the world of hardware. But sometimes you sit back in a reflective mood, and ask yourself: didn’t this all used to be more exciting? If you too have done that, perhaps it’s worth considering how our world of hardware hacking is fueled, and what makes stuff new and interesting.

Hardware projects are like startup fads

When AliExpress has hundreds of kits for them, Nixie clocks are a mature project sector, by any measure.
Hardware projects are like startup fads, they follow the hype cycle. Take Nixie clocks for instance, they’re cool as heck, but here in 2024 there’s not so much that’s exciting about them. If you made one in 2010 you were the talk of the town, in 2015 everyone wanted one, but perhaps by 2020 yours was simply Yet Another Nixie Clock. Now you can buy any number of Nixie clock kits on Ali, and their shine has definitely worn off. Do you ever have the feeling that the supply of genuinely new stuff is drying up, and it’s all getting a bit samey? Perhaps it’s time to explore this topic.

I have a theory that hardware hacking goes in epochs, each one driven by a new technology. If you think about it, the Arduino was an epoch-defining moment in a readily available and easy to use microcontroller board; they may be merely a part and hugely superseded here in 2024 but back in 2008 they were nothing short of a revolution if you’d previously has a BASIC Stamp. The projects which an Arduino enabled produced a huge burst of creativity from drones to 3D printers to toaster oven reflow and many, many, more, and it’s fair to say that Hackaday owes its early-day success in no small part to that little board from Italy. To think of more examples, the advent of affordable 3D printers around the same period as the Arduino, the Raspberry Pi, and the arrival of affordable PCB manufacture from China were all similar such enabling moments. A favourite of mine are the Espressif Wi-Fi enabled microcontrollers, which produced an explosion of cheap Internet-connected projects. Suddenly having Wi-Fi went from a big deal to built-in, and an immense breadth of new projects came from those parts.

Tell us then, What’s new?

So back to 2024, and a Hackaday writer at her desk in the English countryside. 3D printers are still our bread and butter, but they’re on Amazon special offer these days. Small Linux boards are ten a penny, and microcontrollers that put the Arduino’s ATmega in the shade are only a few cents from China. It almost feels as though everything is mainstream, and all we’re getting are increments rather than huge leaps. I want new stuff again, I want exciting stuff!

Happily, the world of technology doesn’t stand still. We all know that the Next Big Thing is just around the corner, and our desire to make cool new stuff will be revitalised by it. But what will it be? My eyes are on ASIC fabrication, I think Tiny Tapeout must only be the start of perhaps the most exciting epoch of them all. But what do you think on the matter, where will your Next Big Thing come from? We’re really interested to hear your views in the comments.

Header image: The RepRap Mendel 3D printer, one of the more successful early affordable designs. Dkoukoul, CC BY-SA 3.0.

hackaday.com/2024/09/06/ask-ha…

What’s a dog to do if they want to do some accessible skateboarding? [Simone Giertz]’s three-legged pup, [Scraps], got the chance to try a LEGO Technic board for her thrills.

This electric LEGO skateboard features six motors and paw pedals to let [Scraps] steer while [Giertz] remotely controls the speed of the board. While it’s not a particularly fast ride, it does let [Scraps] live out her dreams of being a YouTube dog skateboard celebrity.

A video from [Giertz] wouldn’t be complete without a life lesson, and this time it was the importance of rest to the creative process. Sometimes when a solution eludes you, it’s just time to take a break. The steering mechanism, in particular, was giving her trouble but became simple the next morning. We’re also treated to an adorable shot of [Scraps] napping when the initial shoot of her riding the board wasn’t going as planned.

Want to try your hand at making your own skateboard? How about a deck from recycled plastic, tank treads instead of wheels, or is a rocket-powered skateboard more your speed?

youtube.com/embed/N1eo5bXtZeM?…

hackaday.com/2024/09/06/an-ele…

Estonia has revealed that Moscow was behind a series of cyber attacks targeting of several Estonian ministries in 2020, in a rare move that publically accuses another state actor of a cyber-attack.

euractiv.com/section/defence-a…

[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!

hackaday.com/2024/09/06/this-w…

Google's anti-competitive advertising practices are harming UK publishers and advertisers, the UK's Competition and Markets Authority (CMA) found on Friday (6 September), amid similar investigations in the EU and US over the company's monopolistic behaviour in search and ad markets.

euractiv.com/section/competiti…

Gli esperti hanno pubblicato il codice dell’exploit e un’analisi dettagliata della vulnerabilità zero-day di Google Chrome.

L’exploit PoC si riferisce a un bug di Type Confusion con ID CVE-2024-5274 (punteggio CVSS: 8,8) nel motore V8, che viene utilizzato per elaborare JavaScript nel browser. Il problema si verifica perché il programma interpreta erroneamente un tipo di dati come un altro tipo, il che può portare a arresti anomali, danneggiamento dei dati e persino esecuzione di codice arbitrario.

Google ha inizialmente rilasciato una correzione per la vulnerabilità nel maggio 2024, ma i dettagli tecnici sono stati nascosti per impedire agli aggressori di sfruttare la falla. La situazione è cambiata dopo che i ricercatori @mistymntncop e @buptsb hanno pubblicato il codice dell’exploit su GitHub .

Avere un codice PoC ha lati positivi e negativi. Da un lato è utile per gli specialisti della sicurezza informatica che possono studiare la vulnerabilità e sviluppare misure di protezione più efficaci. D’altro canto il codice può essere utilizzato dagli hacker per creare veri e propri exploit ed effettuare attacchi.

Questa vulnerabilità è stata sfruttata negli attacchi ai siti web governativi della Mongolia, che hanno colpito sia gli utenti iOS che quelli Android che visitavano i siti infetti.

Gli attacchi facevano parte di una campagna più ampia che ha sfruttato anche un’altra vulnerabilità critica di Chrome, CVE-2024-4671. In entrambe le campagne gli aggressori hanno utilizzato exploit simili a quelli utilizzati dalle società di spyware commerciale Intellexa e NSO Group.

Google ha già rilasciato un aggiornamento per Chrome: versione 125.0.6422.112/.113 per Windows e Mac e versione 125.0.6422.112 per Linux. Si consiglia vivamente agli utenti di aggiornare immediatamente il proprio browser per proteggersi da possibili attacchi.

L'articolo Il Codice Exploit è Online del bug di Google Chrome: rischio di attacchi in aumento proviene da il blog della sicurezza informatica.