Security Hacks

1498 Articles

New Bambu Lab Firmware Update Adds Mandatory Authorization Control System

January 17, 2025 by 105 Comments

As per a recent Bambu Lab blog post, its FDM printers in the X1 series will soon receive a firmware update that adds mandatory authentication for certain operations, starting with the firmware update on January 23rd for the aforementioned FDM printers. These operations include performing firmware upgrades, initiating a print job (LAN or cloud), remote video access and adjusting parameters on the printer. Using the printer directly and starting prints from an SD card are not affected.

As reasoning for this new feature Bambu Lab points to recent exploits that gave strangers access to people’s printers, though cheekily linking to an article on an Anycubic printer exploit. While admittedly a concern, this mostly affects internet-exposed printers, such as those that are tied into a ‘cloud’ account. Even so, LAN-based printing also falls under this new mandatory authentication system, with Bambu Lab offering a new tool called Bambu Connect for those who insist on using non-Bambu Lab branded software like OrcaSlicer. This allows for exported G-code files to be sent to a (property authenticated) Bambu Lab printer.

For those who do not wish to use this feature, not upgrading the firmware is currently the only recourse. Although this firmware update is only for X1-series printers, Bambu Lab promised that it’ll arrive for their other printers too in due time. While Bambu Lab printer owners consider installing the alternative X1 Plus firmware, the peanut gallery can discuss the potential security issues (or lack thereof) of an open Fluidd or similar UI on their LAN-connected, Klipper-based FDM printers.

Thanks to [mip] for the tip.

This Week In Security: Rsync, SSO, And Pentesting Mushrooms

January 17, 2025 by 14 Comments

Up first, go check your machines for the rsync version, and your servers for an exposed rsync instance. While there are some security fixes for clients in release 3.4.0, the buffer overflow in the server-side rsync daemon is the definite standout. The disclosure text includes this bit of nightmare fuel: “an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.”

A naive search on Shodan shows a whopping 664,955 results for rsync servers on the Internet. Red Hat’s analysis gives us a bit more information. The checksum length is specified by the remote client, and an invalid length isn’t properly rejected by the server. The effect is that an attacker can write up to 48 bytes into the heap beyond the normal checksum buffer space. The particularly dangerous case is also the default: anonymous access for file retrieval. Red Hat has not identified a mitigation beyond blocking access.

If you run servers or forward ports, it’s time to look at ports 873 and 8873 for anything listening. And since that’s not the only problem fixed, it’s really just time to update to rsync 3.4.0 everywhere you can. While there aren’t any reports of this being exploited in the wild, it seems like attempts are inevitable. As rsync is sometimes used in embedded systems and shipped as part of appliances, this particular bug threatens to have quite the long tail. Continue reading “This Week In Security: Rsync, SSO, And Pentesting Mushrooms” →

Using The ESP8266 For Low-Cost Fault Injection

January 15, 2025 by 10 Comments

As a general concept, fault injection is a technique that studies how a system reacts to unusual or unexpected external forces. The idea is that, if you can trigger a glitch at the precise moment, you might be able to use that to your advantage in disabling security features or otherwise gaining further access to the device in question. In the hardware world, this could be achieved by fiddling with the power going into the device, or subjecting it to extreme temperatures.

We’ve covered voltage glitching attacks on these pages in the past, but most of the tools used are fairly expensive if you’re not doing this kind of thing professionally. Luckily for us, [Aditya Patil] has developed a fault injection tool that can run on a standard ESP8266 development board. Obviously it’s not as capable as a bespoke device costing hundreds of dollars, but if you just want to experiment with the concept, it’s a fantastic way to wrap your head around it all.

Continue reading “Using The ESP8266 For Low-Cost Fault Injection” →

This Week In Security: Backdoored Backdoors, Leaking Cameras, And The Safety Label

January 10, 2025 by 3 Comments

The mad lads at watchTowr are back with their unique blend of zany humor and impressive security research. And this time, it’s the curious case of backdoors within popular backdoors, and the list of unclaimed domains that malicious software would just love to contact.

OK, that needs some explanation. We’re mainly talking about web shells here. Those are the bits of code that get uploaded to a web server, that provide remote access to the computer. The typical example is a web application that allows unrestricted uploads. If an attacker can upload a PHP file to a folder where .php files are used to serve web pages, accessing that endpoint runs the arbitrary PHP code. Upload a web shell, and accessing that endpoint gives a command line interface into the machine.

The quirk here is that most attackers don’t write their own tools. And often times those tools have special, undocumented features, like loading a zero-size image from a .ru domain. The webshell developer couldn’t be bothered to actually do the legwork of breaking into servers, so instead added this little dial-home feature, to report on where to find all those newly backdoored machines. Yes, many of the popular backdoors are themselves backdoored.

This brings us to what watchTowr researchers discovered — many of those backdoor domains were either never registered, or the registration has been allowed to expire. So they did what any team of researchers would do: Buy up all the available backdoor domains, set up a logging server, and just see what happens. And what happened was thousands of compromised machines checking in at these old domains. Among the 4000+ unique systems, there were a total of 4 .gov. domains from governments in Bangladesh, Nigeria, and China. It’s an interesting romp through old backdoors, and a good look at the state of still-compromised machines.

Continue reading “This Week In Security: Backdoored Backdoors, Leaking Cameras, And The Safety Label” →

Close up of a Hornet Nest circuit board

PoE-Power Protection: The Hornet Nest Alarm Panel

January 4, 2025 by 31 Comments

Have you ever thought of giving new buzz to outdated wired alarm systems or saving money while upgrading your home security? The Hornet Nest Alarm Panel, to which hacker [Patrick van Oosterwijck] contributes, does just that. Designed for domotics enthusiasts, it offers 42 sensor zones and seamless integration with Home Assistant and ESPHome. This open-source gem uses the wESP32 board, which combines an ESP32 with Ethernet and Power over Ethernet (PoE) for robust, reliable connectivity. Check out the Crowd Supply campaign for details.

So what makes this Hornet Nest special? Besides its hackable nature, it repurposes existing wired sensors, reducing waste and cost. Unlike WiFi-dependent solutions, the PoE-powered ESP32 ensures stable performance, even in hard-to-reach locations. The optional USB programming port is genius—it’s there when you need it but doesn’t clutter the board when you don’t. With its isolated circuits, long-cable safety, and smart Ethernet, WiFi, and Bluetooth combination, this system ticks every DIY box.

Hackaday has featured other DIY PoE-powered projects, offering more inspiration for smart automation enthusiasts.

Continue reading “PoE-Power Protection: The Hornet Nest Alarm Panel” →

This Week In Security: IOCONTROL, (Location) Leaking Cars, And Passkeys

January 3, 2025 by 11 Comments

Claroty’s TEAM82 has a report on a new malware strain, what they’re calling IOCONTROL. It’s a Linux malware strain aimed squarely at embedded devices. One of the first targets of this malware, surprisingly, is the Iraeli made Orpak gas station pumps. There’s a bit of history here, as IOCONTROL is believed to be used by CyberAv3ngers, a threat actor aligned with Iran. In 2023 a group aligned with Israel claimed to have compromised the majority of the gas stations in Iran. IOCONTROL seems to have been deployed as retribution.

There are a few particularly interesting aspects of this malware, and how TEAM82 went about analyzing it. The first is that they used unicorn to emulate the obscure ARM platform in question. This was quite an adventure, as they were running the malicious binary without the normal Linux OS under it, and had to re-implement system calls to make execution work. The actual configuration data was encrypted as the data section of the executable, presumably to avoid simple string matching detection and analysis.

Then to communicate with the upstream command and control infrastructure, the binary first used DNS-Over-HTTPS to resolve DNS addresses, and then used the MQTT message protocol for actual communications. Once in place, it has the normal suite of capabilities, like code execution, cleanup, lateral scanning, etc. An interesting speculation is that the level of control this malware had over these gas pumps, it was in a position to steal credit card information. This malware family isn’t limited to gas pumps, either, as it’s been spotted in IoT and SCADA devices from a whole host of vendors. Continue reading “This Week In Security: IOCONTROL, (Location) Leaking Cars, And Passkeys” →

38C3: Taking Down The Power Grid Over Radio

January 1, 2025 by 20 Comments

You know how you can fall down a rabbit hole when you start on a project? [Fabian Bräunlein] and [Luca Melette] were looking at a box on a broken streetlamp in Berlin. The box looked like a relay, and it contained a radio. It was a Funkrundsteueremfänger – a radio controlled power controller – made by a company called EFR. It turns out that these boxes are on many streetlamps in many cities, and like you do, they thought about how cool it would be to make lights blink, but on a city-wide basis. Haha, right? So they bought a bunch of these EFR devices on the used market and started hacking.

They did a lot of background digging, and found out that they could talk to the devices, both over their local built-in IR port, but also over radio. Ironically, one of the best sources of help they found in reversing the protocol was in the form of actually pressing F1 in the manufacturer’s configuration application – a program’s help page actually helped someone! They discovered that once they knew some particulars about how a node was addressed, they could turn on and off a device like a street lamp, which they demo with a toy on stage. So far, so cute.

But it turns out that these boxes are present on all sorts of power consumers and producers around central Europe, used to control and counteract regional imbalances to keep the electrical grid stable. Which is to say that with the same setup as they had, maybe multiplied to a network of a thousand transmitters, you could turn off enough power generation, and turn on enough load, to bring the entire power grid down to its knees. Needless to say, this is when they contacted both the manufacturer and the government.

The good news is that there’s a plan to transition to a better system that uses authenticated transmissions, and that plan has been underway since 2017. The bad news is that progress has been very slow, and in some cases stalled out completely. The pair view their work here as providing regulators with some extra incentive to help get this important infrastructure modernization back on the front burner. For instance, it turns out that large power plants shouldn’t be using these devices for control at all, and they estimate that fixing this oversight could take care of most of the threat with the least effort.

National power grids are complicated machines, to say the least, and the impact of a failure can be very serious. Just take a look at what happened in 2003 in the US northeast, for instance. And in the case of real grid failure, getting everything back online isn’t as simple a just turning the switches back on again. As [Fabian] and [Luca] point out here, it’s important to discover and disclose when legacy systems put the grid in potential danger.