This Week In Security: ACME.sh, Leaking LEDs, And Android Apps

Let’s Encrypt has made an enormous difference to the landscape of the web. The protocol used for authenticating and receiving certificates, ACME, has spawned quite a few clients of various flavors. Some are written in Rust, some in Python or Go, and a few in straight Bash shell script. One of those last ones, acme.sh, was doing something odd when talking to a particular “Certificate Authority”, HiCA. This pseudo-CA only supports acme.sh, and now we know why. The folks behind HiCA found an RCE exploit in acme.sh, and decided to use that exploit to do certificate issuance with more “flexability”. Oof.

The nuts and bolts here is that HiCA was working as a CA-in-the-Middle, wrapping other CA’s authentication services. Those services don’t support ACME authentication at all, and HiCA used the acme.sh vulnerability to put the authentication token in the place SSL.com expected to find it. So, just a good community member offering a service that ACME doesn’t quite support, right?

Well, maybe not so innocent. The way it appears this works, is that the end user sends a certificate request to HiCA. HiCA takes that information, and initiates a certificate request off to SSL.com. SSL.com sends back a challenge, and HiCA embeds that challenge in the RCE and sends it to the end user. The end user’s machine triggers the RCE, which pushes the challenge token to the well-known location, and bypasses the ACME protection against exactly this sort of CA-in-the-middle situation.

The last piece of the authentication process is that the signing server reaches out over HTTP to the domain being signed, and looks for the token to be there. Once found, it sends the signed certificates to HiCA, who then forward them on to the end user. And that’s the problem. HiCA has access to the key of every SSL cert they handled. This doesn’t allow encryption, but these keys could be used to impersonate or even launch MitM attacks against those domains. There’s no evidence that HiCA was actually capturing or using those keys, but this company was abusing an RCE to put itself in the position to have that ability.

The takeaway is twofold. First, as an end user, only use reputable CAs. And second, ACME clients need to be hardened against potentially malicious CAs. The fact that HiCA only supported the one ACME client was what led to this discovery, and should have been a warning flag to anyone using the service. Continue reading “This Week In Security: ACME.sh, Leaking LEDs, And Android Apps”

Hackaday Links Column Banner

Hackaday Links: June 11, 2023

As Tom Nardi mentioned in this week’s podcast, the Northeast US is pretty apocalyptically socked in with smoke from wildfires in Canada. It’s what we here in Idaho call “August,” so we have plenty of sympathy for what they’re going through out there. People are turning to technology to ease their breathing burden, with reports that Tesla drivers are activating the “Bioweapon Defense Mode” of their car’s HVAC system. We had no idea this mode existed, honestly, and it sounds pretty cool — the cabin air system apparently shuts off outside air intake and runs the fan at full speed to keep the cabin under positive pressure, forcing particulates — or, you know, anthrax — to stay outside. We understand there’s a HEPA filter in the mix too, which probably does a nice job of cleaning up the air in the cabin. It’s a clever idea, and hats off to Tesla for including this mode, although perhaps the name is a little silly. Here’s hoping it’s not one of those subscription services that can get turned off at a moment’s notice, though.

Continue reading “Hackaday Links: June 11, 2023”

We’ve Got A Saxaboom At Home Son

Most parents have heard a familiar story. Their lovely child comes up, having seen a celebrity rocking out with a funny $20 toy from the 80s, and asks for it. Of course, you reply, it’s just 20 dollars. However, a quick scan through eBay reveals that everyone else’s kid has also been asking for this obscure toy for a school event, which now costs around $700. [Ben] found himself in that exact position and made a crucial off-hand comment, “I bet I could make one of those.” That was how his hectic journey into the world of toy reproduction began.

All [Ben] had for reference when recreating a Sax-A-Boom were pictures and sound clips. Modeling complex sweeping shapes in CAD is difficult, and [Ben] commissioned a 3d model from a professional on Fiverr. [Ben] broke down the model into printable sections and tweaked it to account for buttons. After a concerning amount of putty, wet sanding, and elbow grease, [Ben] had a decently smooth body for an instrument. The device’s guts is an ESP32-based board called Sonatino, built around music generation. The music samples came from a virtual instrument clone on GitHub and loaded onto an SD card.

Time pressure crept in towards the end, and [Ben] had to go for some dirty solution that he would have preferred (popsicle sticks and epoxy for button mounting). Yes, there were some gaps and paint flaws, but ultimately [Ben’s] son rocked the school presentation. It’s a beautiful journey through creating something with a high level of finish on a limited timescale.

Perhaps future versions of the Sax-A-Boom can take it further by adding a breath sensor, like this 3d printed MIDI instrument.

Continue reading “We’ve Got A Saxaboom At Home Son”

How Far Can An EULA Go?

We read this news with mixed glee and horror: a company called Telly is giving TVs away, for the low price of having to live with an always-on advertisement bar and some pretty stringent terms and conditions. Break the terms, and they’ll repossess your TV. If you don’t give them the TV, they have your credit card on record and they think the set is worth $1,000.

The hacker in me sees free hardware, so I checked out the terms and conditions, and it doesn’t look good. They’ve explicitly ruled out opening up or physically modifying the device, and it has to continually have WiFi – for which you pay, naturally. It sounds like it could easily tell if you try to tamper with it. My next thought was, perhaps too cynically, to get one, put it in the closet, and wait for the company to go bankrupt. Because you know that business model isn’t going to last.

But it’s clear that they’ve seen through me. The most bizarre clause is that you have to “Use the Product as the primary television in Your household”. Now, we’re not lawyers, but it seems like an amazing stretch that they can tell you how intensively you are to use the product. Can you imagine a license with a keyboard that demanded that you only use it to write sci-fi novels, or that you have to use it more than any other keyboard?

Nope. Too many hoops to jump through for a silly free TV. You can keep your dystopian future.

How To Install Mac OS On The Nintendo Wii

What if you could run Mac OS on a Nintendo Wii game console? That’s probably not a thought that has occurred to many Wii owners or Mac OS users, but that is no excuse not to give it a try, as [Michael] handily demonstrates in a recent video by running Mac OS 9 on a Nintendo’s legendary console. The first major issue is what anyone who has ever tried to put a Hackintosh together knows: just because a target system runs the same CPU architecture can you necessarily install Mac OS (or OS X) for Intel x86 on any Intel x86 system. The same is true for the Wii with its PowerPC CPU and running Mac OS 9 for PowerPC on it.

In order to make this work, a workaround is employed, which uses the fossilized Mac-on-Linux project to run PowerPC Mac OS essentially on Linux for the Wii. This is a kernel module which allows Mac OS to run at basically native speeds on Linux, but it being a Linux kernel module, it meant that [Michael] had to hunt down the correct kernel to go with it. After creating an SD card with a functioning bootloader, he was able to boot into Wii Linux with MoL enabled, and try to install Mac OS.

OS X didn’t work for some reason, but Mac OS 9 did work, albeit with severe font rendering and audio glitches. All of which seems to come down to that while it is possible to get Mac OS running on the Wii, doing so is definitely more for the challenge and experience. By the way, if all this sounds a bit familiar, it’s because [Michael] referenced the Mac-on-Wii work that [Dandu] did last year to make this latest iteration happen.

Continue reading “How To Install Mac OS On The Nintendo Wii”

Barcodes Enter The Matrix In 2027

Beep. We’ve come a long way since June 26, 1974 when the first bar code was scanned at a grocery store in Troy, Ohio. That legendary pack of Juicy Fruit proved that even the smallest of items could now carry numbers associated with inventory and price.

By now, we’re all too familiar with this sound as self-checkouts have become the norm. Whereas you yourself could at one time literally check out during the transaction, you must now be on your toes and play find the bar code on every item.

What does the consumer gain from the bar code today? Practically nothing, except the chance to purchase, and potentially return, the item without too much hassle. Well, the non-profit outfit that runs the bar code world — GS1 US — wants to change all that. By 2027, they are confident that all 1D bar codes will be replaced with 2D bar codes similar to QR codes. Why?

Continue reading “Barcodes Enter The Matrix In 2027”

PUF Away For Hardware Fingerprinting

Despite the rigorous process controls for factories, anyone who has worked on hardware can tell you that parts may look identical but are not the same. Everything from silicon defects to microscopic variations in materials can cause profoundly head-scratching effects. Perhaps one particular unit heats up faster or locks up when executing a specific sequence of instructions and we throw our hands up, saying it’s just a fact of life. But what if instead of rejecting differences that fall outside a narrow range, we could exploit those tiny differences?

This is where physically unclonable functions (PUF) come in. A PUF is a bit of hardware that returns a value given an input, but each bit of hardware has different results despite being the same design. This often relies on silicon microstructure imperfections. Even physically uncapping the device and inspecting it, it would be incredibly difficult to reproduce the same imperfections exactly. PUFs should be like the ideal version of a fingerprint: unique and unforgeable.

Because they depend on manufacturing artifacts, there is a certain unpredictability, and deciding just what features to look at is crucial. The PUF needs to be deterministic and produce the same value for a given specific input. This means that temperature, age, power supply fluctuations, and radiation all cause variations and need to be hardened against. Several techniques such as voting, error correction, or fuzzy extraction are used but each comes with trade-offs regarding power and space requirements. Many of the fluctuations such as aging and temperature are linear or well-understood and can be easily compensated for.

Broadly speaking, there are two types of PUFs: weak and strong. Weak offers only a few responses and are focused on key generation. The key is then fed into more traditional cryptography, which means it needs to produce exactly the same output every time. Strong PUFs have exponential Challenge-Response Pairs and are used for authenticating. While strong PUFs still have some error-correcting they might be queried fifty times and it has to pass at least 95% of the queries to be considered authenticated, allowing for some error. Continue reading “PUF Away For Hardware Fingerprinting”