This Week In Security: Flatpak Fixes, Android Malware, And SCADA Was IOT Before IOT Was Cool

Rowhammer attacks have been around since 2014, and mitigations are in place in most modern systems, but the team at gddr6.fail has found ways to apply the attack to current-generation GPUs.

Rowhammer attacks attach the electrical characteristics of RAM, using manipulation of the contents of RAM to cause changes in the contents of adjacent memory cells. Bit values are just voltage levels, after all, and if a little charge leaks across from one row to the next, you can potentially pull a bit high by writing repeatedly to its physical neighbors.

The attack was used to allow privilege escalation by manipulating the RAM defining the user data, and later, to allow reading and manipulation of any page in ram by modifying the system page table that maps memory and memory permissions. By 2015 researchers refined the attack to run in pure JavaScript against browsers, and in 2016 mobile devices were shown to be vulnerable. Mitigations have been put in place in physical memory design, CPU design, and in software. However, new attack vectors are still discovered regularly, with DDR4 and DDR5 RAM as well as AMD and RISC-V CPUs being vulnerable.

The GDDR6-Fail attack targets the video ram of modern graphics cards, and is able to trigger similar vulnerabilities in the graphics card itself, culminating in accessing and changing the memory of the PC via the PCI bus and bypassing protections.

For users who fear they are at risk — most likely larger AI customers or shared hosting environments where the code running on the GPU may belong to untrusted users — enabling error correcting (ECC) mode in the GPU reduces the amount of available RAM, but adds protection by performing checksums on the memory to detect corruption or bit flipping. For the average home user, your mileage may vary – there’s certainly easier ways to execute arbitrary code on your PC – like whatever application is running graphics in the first place!

Continue reading “This Week In Security: Flatpak Fixes, Android Malware, And SCADA Was IOT Before IOT Was Cool”

A photo of the HAT with the LoRa module and relay visible on the top

LoRaSense Pi Hat Aims To Kick Start IoT Projects

[Avi Gupta] recently sent in their LoRaSense RGB Pi HAT project. This “HAT” (Hardware Attached to Top) is for any Raspberry Pi with 40-pin header. The core of the build is the custom printed circuit board which houses the components and interconnects. The components include an SHT31 temperature and humidity sensor, an SX1278 LoRa module, and a 10 amp 220 VAC relay. The interconnects include support for UART, I2C, SPI, and WS2812B RGB LED interfaces as well as a stackable header for daisy chaining HATs.

The attached components in combination support a wide range of use cases. Possible uses for this Raspberry Pi HAT include smart home systems, agricultural projects, industrial monitoring, smart greenhouse, remote weather stations, or alerting systems. You can detect weather conditions, send and receive information, switch mains powered loads, and use RGB LEDs for status and alerting.

If you’re interested in LoRa technology be sure to read about the Yagi antenna that sends LoRa signals farther.

This Week In Security: Hardware Attacks, IoT Security, And More

This week starts off with examinations of a couple hardware attacks that you might have considered impractical. Take a Ball Grid Array (BGA) NAND removal attack, for instance. The idea is that a NAND chip might contain useful information in the form of firmware or hard-coded secrets.

The question is whether a BGA desolder job puts this sort of approach out of the reach of most attackers. Now, this is Hackaday. We regularly cover how our readers do BGA solder jobs, so it should come as no surprise to us that less than two-hundred Euro worth of tools, and a little know-how and bravery, was all it took to extract this chip. Plop it onto a pogo-pin equipped reader, use some sketchy Windows software, and boom you’ve got firmware.

What exactly to do with that firmware access is a little less straightforward. If the firmware is unencrypted and there’s not a cryptographic signature, then you can just modify the firmware. Many devices include signature checking at boot, so that limits the attack to finding vulnerabilities and searching for embedded secrets. And then worst case, some platforms use entirely encrypted firmware. That means there’s another challenge, of either recovering the key, or finding a weakness in the encryption scheme. Continue reading “This Week In Security: Hardware Attacks, IoT Security, And More”

Cutting An IoT Fan Free Of The Cloud

The cloud is supposed to make everything better. You can control things remotely, with the aid of a benevolent corporation and their totally friendly servers. However, you might not like those servers, and you might prefer to take personal control of your hardware. If that’s the case, you might like to follow the story of [ouaibe] and their quest to free a fan from the cloud.

The unit in question was a tower fan from Dreo. [ouaibe] noted that there was already a project to control the fans using Home Assistant, but pure lower-level local control was the real goal here. Work began on pulling apart the Dreo Android app to determine how it talked to the fan, eventually turning up a webserver on board, but little progress. The next step was to disassemble the unit entirely. That turned up multiple PCBs inside, with one obviously for wireless communication and another hosting a Sino Wealth microcontroller. Dumping firmwares followed,  along with reverse engineering the webserver, and finally establishing a custom ESPHome integration to fully control the fan.

[ouaibe] has shared instructions on how to cut your own fan from the cloud, though notes that the work won’t be extended to other Dreo products any time soon. In any case, it’s a great example of just how much work it can take to fully understand and control an IoT device that’s tethered to a commercial cloud server. It’s not always easy, but it can be done!

Hacking An IoT Camera Reveals Hard-Coded Root Password

Hacking — at least the kind where you’re breaking into stuff — is very much a learn-by-doing skill. There’s simply no substitute for getting your hands dirty and just trying something. But that doesn’t mean you can’t learn something by watching, with this root password exploit on a cheap IP video camera being a good look at the basics.

By way of background on this project, [Matt Brown] had previously torn into a VStarcam CB73 security camera, a more or less generic IP camera that he picked up on the cheap, and identified a flash memory chip from which he extracted the firmware. His initial goal was to see if the camera was contacting sketchy servers, and while searching the strings for the expected unsavory items, he found hard-coded IP addresses plus confirmation that the camera was running some Linux variant.

With evidence of sloppy coding practices, [Matt] set off on a search for a hard-coded root password. The second video covers this effort, which started with finding UART pins and getting a console session. Luckily, the bootloader wasn’t locked, which allowed [Matt] to force the camera to boot into a shell session and find the root password hash. With no luck brute-forcing the hash, he turned to Ghidra to understand the structure of a suspicious program in the firmware called encoder. After a little bit of poking and some endian twiddling, he was able to identify the hard-coded root password for every camera made by this outfit, and likely others as well.

Granted, the camera manufacturer made this a lot easier than it should have been, but with a lot of IoT stuff similarly afflicted by security as an afterthought, the skills on display here are probably broadly applicable. Kudos to [Matt] for the effort and the clear, concise presentation that makes us want to dig into the junk bin and get hacking.

Continue reading “Hacking An IoT Camera Reveals Hard-Coded Root Password”

Screenshot of eBay listings with Gigaset IoT devices being sold, now basically useless

A Giga-Sunset For Gigaset IoT Devices

In today’s “predictable things that happened before and definitely will happen again”, we have another company in the “smart device” business that has just shuttered their servers, leaving devices completely inert. This time, it’s Gigaset. The servers were shuttered on the 29th of March, and the official announcement (German, Google Translate) states that there’s no easy way out.

It appears that the devices were locked into Gigaset Cloud to perform their function, with no local-only option. This leaves all open source integrations in the dust, whatever documentation there was, is now taken down. As the announcement states, Gigaset Communications Gmbh has gotten acquired due to insolvency, and the buyer was not remotely interested in the Smart Home portion of the business. As the corporate traditions follow, we can’t expect open sourcing of the code or protocol specification or anything of the sort — the devices are bricks until someone takes care of them.

If you’re looking for smart devices on the cheap, you might want to add “Gigaset” to your monitored search term list — we’ll be waiting for your hack submissions as usual. After all, we’ve seen some success stories when it comes to abandoned smart home devices – like the recent Insteon story, where a group of device owners bought out and restarted the service after the company got abruptly shut down.

We thank [Louis] for sharing this with us!

Three ZigBee radios in ESD bags, marked "Zigbee Sniffer", "Router" and "Coordinator".

Crash IoT Devices Through Protocol Fuzzing

IoT protocols are a relatively unexplored field compared to most PC-exposed protocols – it’s bothersome to need a whole radio setup before you can tinker on something, and often, for low-level experiments, just any radio won’t do. This means there’s quite a bit of security ground to cover. Now, the U-Fuzz toolkit from [asset-group] helps us make up for it.

Unlike fuzzers you might imagine, U-Fuzz doesn’t go in blindly. This toolkit has provisions to parse protocols and fuzz fields meaningfully, which helps because many of devices will discard packets they deem too malformed. With U-Fuzz, you feed it a couple packet captures, help it make some conclusions about packet and protocol structure, and get suggestions on how to crash your devices in ways not yet foreseen.

This allows for basically arbitrary protocol fuzzing, and to demonstrate, we get examples on 5G, CoAP and ZigBee probing alike, with a list of found CVEs to wrap the README up. As Wikipedia often states, this list is incomplete, and you can help by expanding it. Fuzzing is an underestimated tool – it will help you hack ubiquitous wireless protocols, proprietary standards, and smart home hubs alike.