Meshtastic For The Greater Good

Last week, my city was hit by a tornado. That’s not surprising here in Oklahoma, and thankfully this event was an F0 or possibly even an EF0 — a really weak tornado. Only a couple roofs collapsed, though probably half the houses in town are going to need roof repairs, thanks to the combination of huge hail and high winds. While it wasn’t too bad, power did go down in a few places around town, and this led to an interesting series of events.

Chat messages were coming in like this: “That was a [power] flicker, yeah. Even took down my Internet.” Followed by “Whee, [fiber Internet] got knocked out and now Starlink has too many clouds in the way.” And after ten minutes of silence, we got a bit worried to see “Time to hide under a bed. … Is cell service back?” It is a bit spooky to think about trying to help neighbors and friends after a disaster, in the midst of the communication breakdown that often follows. If he had needed help, and had no working communications, how long would it have taken for us to go check on him?
Continue reading “Meshtastic For The Greater Good”

Ventbot fans with 3D printed brackets and control circuit board with ESP32 breakout and multicolored 3D printed cases

Ventbots Are Fans Of HVAC And Home Automation

[WJCarpenter] had a common HVAC problem; not all the rooms got to a comfortable temperature when the heater was working to warm up their home. As often happens with HVAC systems, the rooms farthest from the heat source and/or with less insulation needed a boost of heat in the winter and cooling in the summer too. While [WJCarpenter] is a self-reported software person, not a hardware person, you will enjoy going along on the journey to build some very capable vent boosters that require a mix of each.

Ventbot control circuit board with ESP32 breakout in a red 3D printed case

There’s a great build log on hackaday.io here, but for those who need more of a proper set of instructions, there’s a step-by-step guide that should allow even a beginner hardware hacker to complete the project over on Instructables. There you’ll find everything you need to build ESPHome controlled, 3D printed, PC fan powered vent boosters. While they can be integrated into Home Assistant, we were interested to learn that ESPHome allows these to run stand-alone too, each using its own temperature and pressure sensor.

The many iterations of hardware and software show, resulting in thoughtful touches like a startup sequence that checks for several compatible temperature sensors and a board layout that accommodates different capacitor lead spacings. Along the way, [WJCarpenter] also graphed the noise level of different fans running at multiple speeds and the pressure sensor readings against the temperatures to see if they could be used as more reliable triggers for the fans. (spoiler, they weren’t) There are a bunch of other tips to find along the way, so we highly recommend going through all that [WJCarpenter] has shared if you want to build your own or just want some tips on how to convert a one-off project to something that a wider audience can adapt to their own needs.

Ventbot graphing of temperature, pressure, and fan noise

See a video after the break that doesn’t show the whole project but includes footage of the start-up sequence that tests each fan’s tachometer and the customizable ramp-up and ramp-down settings. Continue reading “Ventbots Are Fans Of HVAC And Home Automation”

Et Tu, Red Hat?

Something odd happened to git.centos.org last week. That’s the repository where Red Hat has traditionally published the source code to everything that’s a part of Red Hat Enterprise Linux (RHEL) to fulfill the requirements of the GPL license. Last week, those packages just stopped flowing. Updates weren’t being published. And finally, Red Hat has published a clear answer to why:

Red Hat has decided to continue to use the Customer Portal to share source code with our partners and customers, while treating CentOS Stream as the venue for collaboration with the community.

Sounds innocuous, but what’s really going on here? Let’s have a look at the Red Hat family: RHEL, CentOS, and Fedora.

RHEL is the enterprise Linux distribution that is Red Hat’s bread and butter. Fedora is RHEL’s upstream distribution, where changes happen fast and things occasionally break. CentOS started off as a community repackaging of RHEL, as allowed under the GPL and other Open Source licenses, for people who liked the stability but didn’t need the software support that you’re paying for when you buy RHEL.

Red Hat took over the reigns of CentOS back in 2014, and then imposed the transition to CentOS Stream in 2020, to some consternation. This placed CentOS Stream between the upstream Fedora, and the downstream RHEL. Some people missed the stability of the old CentOS, and in response a handful of efforts spun up to fill the gap, like Alma Linux and Rocky Linux. These projects took the source from git.centos.org, and rebuilt them into usable community operating systems, staying closer to RHEL in the process.

Red Hat has published a longer statement elaborating on the growth of CentOS Stream, but it ends with an interesting statement: “Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement.” What exactly is in that subscription agreement? Well according to Alma Linux, “the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.” Continue reading “Et Tu, Red Hat?”

This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride

There’s a fun logic flaw in how multiple online services handle OAuth logins, that abuses Microsoft’s Azure Active Directory service to allow account takeovers. The problem is how a site handles the “Sign In With Microsoft” option, when there’s an existing account under the same email address. This is an irritating problem for an end-user, when a site offers multiple sign-in options. Trying to remember which option was used to set up an account is a struggle, so many services automatically merge accounts.

The problem is that the Microsoft Azure authentication information includes an email address, but Microsoft hasn’t done any verification that the account in question actually controls that address. And in fact, it’s trivial for the Azure admin to change that address at whim. So if the service accepts that email address as authoritative, and auto-merges the accounts, it’s a trivial account takeover. And it’s more than just a theoretical problem, as researchers at descope were able to demonstrate the attack, and have found multiple medium and large services that were vulnerable, as well as at least two authentication providers that themselves were vulnerable to this attack.

Microsoft has pushed updates to the Azure AD service to make the issue easier to avoid, though it seems that the unverified “email” field is still being sent on authentication transactions. There is a new flag, “RemoveUnverifiedEmailClaim” that eliminates the issue, and is enabled by default for new applications. Unfortunately this means that existing vulnerable applications will continue to be vulnerable until fixed on the application side. Continue reading “This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride”

An Unexpected Upset In EV Charging Standards

Last November, Tesla open-sourced parts of its charging infrastructure, not-so-humbly unveiling it as the North American Charging Standard (NACS). It’s finally taking off with a number of manufacturers signing on.

Companies launching “standards” based on their previously proprietary technology in opposition to an established alternative usually leads to standards proliferation. However, with recent announcements from Ford, GM, and Rivian that they would begin supporting NACS in their vehicles, it seems a new dominant standard is supplanting CCS (and the all-but-dead CHAdeMO) in North America.

As Tesla already has the most extensive charging network on the continent and has begun opening it up for other EVs, it makes sense that other marques would want to support NACS, if nothing else to satiate customer demand for a dead-simple charging experience. Dongles are annoying enough for plugging in an external monitor. Having to mess with one while handling high-power electrical connections is less than ideal, to say the least.

If you want to add NACS to your own EV project, the standard is here. We’ve discussed some of the different standards before as well as work toward wirelessly charging EVs (besides the inductive charger on the EV1). It certainly seems like the time to get in on the ground floor of an EV charging empire with an army of Charglas.

Intel To Ship Quantum Chip

In a world of 32-bit and 64-bit processors, it might surprise you to learn that Intel is releasing a 12-bit chip. Oh, wait, we mean 12-qubit. That makes more sense. Code named Tunnel Falls, the chip uses tiny silicon spin quantum bits, which Intel says are more advantageous than other schemes for encoding qubits. There’s a video about the device below.

It is a “research chip” and will be available to universities that might not be able to produce their own hardware. You probably aren’t going to find them listed on your favorite online reseller. Besides, the chip isn’t going to be usable on a breadboard. It is still going to take a lot of support to get it running.

Intel claims the silicon qubit technology is a million times smaller than other qubit types. The size is on the order of a device transistor — 50 nanometers square — simplifying things and allowing denser devices. In silicon spin qubits, information resides in the up or down spin of a single electron.

Of course, even Intel isn’t suggesting that 12 qubits are enough for a game-changing quantum computer, but you do have to start somewhere. This chip may enable more researchers to test the technology and will undoubtedly help Intel accelerate its research to the next step.

There is a lot of talk that silicon is the way to go for scalable quantum computing. It makes you wonder if there’s anything silicon can’t do? You can access today’s limited quantum computers in the proverbial cloud.

Continue reading “Intel To Ship Quantum Chip”

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”