Hacking An IoT Camera Reveals Hard-Coded Root Password

July 24, 2024 by Dan Maloney 21 Comments

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

Hackaday Links: May 19, 2024

May 19, 2024 by Dan Maloney 4 Comments

If there was one question we heard most often this week, it was “Did you see it?” With “it” referring to the stunning display of aurora borealis — and australis, we assume — on and off for several days. The major outburst here in North America was actually late last week, with aurora extending as far south as Puerto Rico on the night of the tenth. We here in North Idaho were well-situated for prime viewing, but alas, light pollution made things a bit tame without a short drive from the city lights. Totally worth it:

Hat tip to Tom Maloney for the pics. That last one is very reminiscent of what we saw back in 1989 with the geomagnetic storm that knocked Québec’s grid offline, except then the colors were shifted much more toward the red end of the spectrum back then.

Continue reading “Hackaday Links: May 19, 2024” →

The Easy Way To Make A Smart Appliance

April 7, 2024 by Jenny List 32 Comments

It seems that finding an appliance without some WiFi connectivity and an app to load your laundry data into the cloud is an increasingly difficult thing to do in the 2020s. Many of us resolutely refuse to connect these smart appliances to the Internet, but not because we don’t see the appeal — we just want to do it on our own terms.

[Terence Eden] did just this with his rice cooker, using a surprisingly straightforward approach. He simply connected it to the mains via an energy monitoring smart plug, and that was the hardware part, done. Of course, were it that simple we probably wouldn’t be featuring this here, as the meat of this project lies in connecting it to his smart home systems and getting something useful from it.

He’s using Home Assistant, and after a bit of messing about had it part of his home automation system. Then it was time for Appliance Status Monitor, which allowed him to easily have the rice cooker send him a notification once it has done its thing by monitoring the power it was using. All online, part of a smart home, and not a byte of his data captured and sold to anyone!

This isn’t the first home automation project we’ve brought you from this source.

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

A Giga-Sunset For Gigaset IoT Devices

April 3, 2024 by Arya Voronova 73 Comments

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

April 2, 2024 by Arya Voronova 1 Comment

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.

Hackaday Links: March 31, 2024

March 31, 2024 by Dan Maloney 5 Comments

Battlelines are being drawn in Canada over the lowly Flipper Zero, a device seen by some as an existential threat to motor vehicle owners across the Great White North. The story started a month or so ago, when someone in the government floated the idea of banning devices that could be “used to steal vehicles by copying the wireless signals for remote keyless entry.” The Flipper Zero was singled out as an example of such a nefarious device, even though relatively few vehicles on the road today can be boosted using the simple replay attack that a Flipper is capable of, and the ones that are vulnerable to this attack aren’t all that desirable — apologies to the 1993 Camry, of course. With that threat hanging in the air, the folks over at Flipper Devices started a Change.org petition to educate people about the misperceptions surrounding the Flipper Zero’s capabilities, and to urge the Canadian government to reconsider their position on devices intended to explore the RF spectrum. That last bit is important, since transmit-capable SDR devices like the HackRF could fall afoul of a broad interpretation of the proposed ban; heck, even a receive-only SDR dongle might be construed as a restricted device. We’re generally not much for petitions, but this case might represent an exception. “First they came for the Flipper Zero, but I did nothing because I don’t have a Flipper Zero…”

Continue reading “Hackaday Links: March 31, 2024” →