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” →

Forgotten Internet: UUCP

January 16, 2025 by 82 Comments

What’s Forgotten Internet? It is the story of parts of the Internet — or Internet precursors — that you might have forgotten about or maybe you missed out on them. This time, we’re looking at Unix-to-Unix Copy, more commonly called UUCP. Developed in the late 1970s, UUCP was a solution for sending messages between systems that were not always connected together. It could also allow remote users to execute commands. By 1979, it was part of the 7th Edition of Unix.

Ken Thompson and Dennis Ritchie may have used UUCP on a PDP-11 like this one. (Photo via Computer History Museum/Gwen Bell)

Operation was simple. Each computer in a UUCP network had a list of neighbor systems. Don’t forget, they weren’t connected, so instead of an IP address, each system had the other’s phone number to connect to a dial up modem. You also needed a login name and password. Almost certainly, by the way, those modems operated at 300 baud or less.

If a computer could dial out, when someone wanted to send something or do a remote execution, the UUCP system would call a neighboring computer. However, some systems couldn’t dial out, so it was also possible for a neighbor to call in and poll to see if there was anything you needed to do. Files would go from one system to another using a variety of protocols.

Continue reading “Forgotten Internet: UUCP” →

How Nyan Cat Was Ported To UEFI

January 13, 2025 by 13 Comments

The Unified Extensible Firmware Interface (UEFI) took over from the classical BIOS some years into the new millenium. It’s typically used for running a computer at the basic pre-OS level, and most of us don’t even notice it past boot time. However, you can do some neat things in this space—you can even port over Nyan Cat if you’re talented like [Cornelius].

That’s fun. Set your friend’s computer to boot into this instead of their OS by default and see how long it takes them to figure it out.

Yes, Nyan Cat is now available as a UEFI application, running via the EFI Simple Text Output Protocol. [Cornelius] approached this creation by first learning Rust, before progressing to the Hello World stage. Before long, the computer was booting up to display a simple text message with no OS required.

From there, creating the Nyan Cat animation required figuring out how to display it as a bunch of dancing characters, which is where the Simple Text Output Protocol came in. Nyan Cat was really the perfect animation for the UEFI environment, since its simple pixel art style was easily recreated with text. With a bit of work, the animation came together, with a remarkable resemblance to the original artwork.

All that’s missing is a routine to play the music over a PC speaker; only, those are hardly a thing anymore. A pity! In any case, if you’ve been cooking up your own nifty UEFI hacks, don’t hesitate to drop us a line!

It’s IP, Over TOSLINK!

January 9, 2025 by 19 Comments

At the recent 38C3 conference in Germany, someone gave a talk about sending TOSLINK digital audio over fiber optic networks rather than the very low-end short distance fibre you’ll find behind your CD player. This gave [Manawyrm] some ideas, so of course the IP-over TOSLINK network was born.

TOSLINK is in effect I2S digital audio as light, so it carries two 44.1 kilosamples per second 16-bit data streams over a synchronous serial connection. At 1544 Kbps, this is coincidentally about the same as a T1 leased line. The synchronous serial link of a TOSLINK connection is close enough to the High-Level Data Link Control, or HDLC, protocol used in some networking applications, and as luck would have it she had some experience in using PPP over HDLC. She could configure her software from that to use a pair of cheap USB sound cards with TOSLINK ports, and achieve a surprisingly respectable 1.47 Mbit/s.

We like this hack, though we can see it’s not entirely useful and we think few applications will be found for it. But she did it because it was there, and that’s the essence of this game. Now all that needs to happen is for someone to use it in conjunction with the original TOSLINK-over network fiber, for a network-over-TOSLINK-over-network abomination.

Pi Pico Makes SSTV Reception A Snap

January 4, 2025 by 11 Comments

There’s a paradox in amateur radio: after all the time and effort spent getting a license and all the expense of getting some gear together, some new hams suddenly find that they don’t have a lot to talk about when they get in front of the mic. While that can be awkward, it’s not a deal-breaker by any means, especially when this Pi Pico SSTV decoder makes it cheap and easy to get into slow-scan television.

There’s not much to [Jon Dawson]’s SSTV decoder. Audio from a single-sideband receiver goes through a biasing network and into the Pico’s A/D input. The decoder can handle both Martin and Scottie SSTV protocols, with results displayed on a TFT LCD screen. The magic is in the software, of course, and [Jon] provides a good explanation of the algorithms he used, as well as some of the challenges he faced, such as reliably detecting which protocol is being used. He also implemented correction for “slant,” which occurs when the transmitter sample rate drifts relative to the receiver. Fixing that requires measuring the time it took to transmit each line and adjusting the timing of the decoder to match. The results are dramatic, and it clears up one of the main sources of SSTV artifacts.

We think this is a great build, and simple enough that anyone can try it. The best part is that since it’s receive-only, it doesn’t require a license, although [Jon] says he’s working on an encoder and transmitter too. We’re looking forward to that, but in the meantime, you might just be able to use this to capture some space memes.

Continue reading “Pi Pico Makes SSTV Reception A Snap” →

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.