The Open Source Smart Home

November 6, 2019 by Gerrit Coetzee 27 Comments

[Tijmen Schep] sends in his project, Candle Smart Home, which is an exhibit of 12 smart home devices which are designed around the concepts of ownership, open source, and privacy.

The central controller runs on a Raspberry Pi which is running Mozilla’s new smart home operating system. Each individual device is Arduino based, and when you click through on the site you get a well designed graphic explaining how to build each device.

It’s also fun to see how many people worked together on this project and added their own flair. Whether it’s a unique covering for the devices or a toggle switch that can toggle itself there’s quite a few personal touches.

As anyone who’s had the sneaking suspicion that Jeff Bezos was listening in to their conversations, we get the need for this. We also love how approachable it makes hacking your own hardware. What are your thoughts?

ESP8266 And ESP32 WiFi Hacked!

September 5, 2019 by Elliot Williams 48 Comments

[Matheus Garbelini] just came out with three (3!) different WiFi attacks on the popular ESP32/8266 family of chips. He notified Espressif first (thanks!) and they’ve patched around most of the vulnerabilities already, but if you’re running software on any of these chips that’s in a critical environment, you’d better push up new firmware pretty quick.

The first flaw is the simplest, and only effects ESP8266s. While connecting to an access point, the access point sends the ESP8266 an “AKM suite count” field that contains the number of authentication methods that are available for the connection. Because the ESP doesn’t do bounds-checking on this value, a malicious fake access point can send a large number here, probably overflowing a buffer, but definitely crashing the ESP. If you can send an ESP8266 a bogus beacon frame or probe response, you can crash it.

What’s most fun about the beacon frame crasher is that it can be implemented on an ESP8266 as well. Crash-ception! This takes advantage of the ESP’s packet injection mode, which we’ve covered before.

The second and third vulnerabilities exploit bugs in the way the ESP libraries handle the extensible authentication protocol (EAP) which is mostly used in enterprise and higher-security environments. One hack makes the ESP32 or ESP8266 on the EAP-enabled network crash, but the other hack allows for a complete hijacking of the encrypted session.

These EAP hacks are more troubling, and not just because session hijacking is more dangerous than a crash-DOS scenario. The ESP32 codebase has already been patched against them, but the older ESP8266 SDK has not yet. So as of now, if you’re running an ESP8266 on EAP, you’re vulnerable. We have no idea how many ESP8266 devices are out there in EAP networks, but we’d really like to see Espressif patch up this hole anyway.

[Matheus] points out the irony that if you’re using WPA2, you’re actually safer than if you’re unpatched and using the nominally more secure EAP. He also wrote us that if you’re stuck with a bunch of ESP8266s in an EAP environment, you should at least encrypt and sign your data to prevent eavesdropping and/or replay attacks.

Again, because [Matheus] informed Espressif first, most of the bugs are already fixed. It’s even percolated downstream into the Arduino-for-ESP, where it’s just been worked into the latest release a few hours ago. Time for an update. But those crusty old NodeMCU builds that we’ve got running everything in our house? Time for a full recompile.

We’ve always wondered when we’d see the first ESP8266 attacks in the wild, and that day has finally come. Thanks, [Matheus]!

Warshipping: A Free Raspberry Pi In The Mail Is Not Always A Welcome Gift

August 19, 2019 by Roger Cheng 39 Comments

Leading edge computer security is veiled in secrecy — a world where novel attacks are sprung on those who do not yet know what they need to protect against. Once certain tactics have played out within cool kids’ circles, they are introduced to the rest of the world. An IBM red team presented what they’re calling “warshipping”: sending an adversarial network to you in a box.

Companies concerned about security have learned to protect their internet-accessible points of entry. Patrolling guards know to look for potential wardrivers parked near or repeatedly circling the grounds. But some are comparatively lax about their shipping & receiving, and they are the ideal targets for warshipping.

Bypassing internet firewalls and security perimeters, attack hardware is embedded inside a shipping box and delivered by any of the common carriers. Security guards may hassle a van bristling with antennas, but they’ll wave a FedEx truck right through! The hardware can be programmed to stay dormant through screening, waiting to probe once inside the walls.

The presentation described several ways to implement such an attack. There is nothing novel about the raw hardware – Raspberry Pi, GPS receiver, cellular modems, and such are standard fare for various projects on these pages. The creative part is the software and in how they are hidden: in packing material and in innocuous looking plush toys. Or for persistence, they can be hidden in a wall mounted plaque alongside some discreet photovoltaic panels. (Editor’s note: What? No Great Seals?)

With this particular technique out in the open, we’re sure others are already in use and will be disclosed some years down the line. In the meantime, we can focus our efforts on more benign applications of similar technology, whether it is spying on our cat or finding the nearest fast food joint. The hardware is evolving as well: a Raspberry Pi actually seems rather heavyweight for this, how about a compact PCB with both an ESP32 and a cellular modem?

Via Ars Technica.

This Week In Security: Facebook Hacked Your Email, Cyber On The Power Grid, And A Nasty Zero-day

May 1, 2019 by Jonathan Bennett 33 Comments

Ah, Facebook. Only you could mess up email verification this badly, and still get a million people to hand over their email address passwords. Yes, you read that right, Facebook’s email verification scheme was to ask users for their email address and email account password. During the verification, Facebook automatically downloaded the account’s contact list, with no warning and no way to opt out.

The amount of terrible here is mind-boggling, but perhaps we need a new security rule-of-thumb for these kind of situations. Don’t ever give an online service the password to a different service. In order to make use of a password in this case, it’s necessary to handle it in plain-text. It’s not certain how long Facebook stored these passwords, but they also recently disclosed that they have been storing millions of Facebook and Instagram passwords in plain-text internally.

This isn’t the first time Facebook has been called out for serious privacy shenanigans, either: In early 2018 it was revealed that the Facebook Android app had been uploading phone call records without informing users. Mark Zuckerberg has recently outlined his plan to give Facebook a new focus on privacy. Time will tell whether any real change will occur.

Cyber Can Mean Anything

Have you noticed that “cyber” has become a meaningless buzz-word, particularly when used by the usual suspects? The Department of Energy released a report that contained a vague but interesting sounding description of an event: “Cyber event that causes interruptions of electrical system operations.” This was noticed by news outlets, and people have been speculating ever since. What is frustrating about this is the wide range of meaning covered by the term “cyber event”. Was it an actual attack? Was Trinity shutting down the power stations, or did an intern trip over a power cord?
Continue reading “This Week In Security: Facebook Hacked Your Email, Cyber On The Power Grid, And A Nasty Zero-day” →

Car Alarm Hacks 3 Million Vehicles

March 8, 2019 by Al Williams 30 Comments

Pen testing isn’t about evaluating inks. It is short for penetration testing — someone ensuring a system’s security by trying to break in or otherwise attack it. A company called Pen Test Partners made the news last week by announcing that high-end car alarm systems made by several vendors have a critical security flaw that could make the vehicles less secure. They claim about three million vehicles are affected.

The video below shows how alarms from Viper/Clifford and Pandora have a simple way to hijack the application. Once they have access, they can find the car in real time, control the door locks, and start or stop the car engine. They speculate a hacker could set off the alarm from a nearby chase car. You’d probably pull over if your alarm started going off. They can then lock you in your car, approach, and then force you out of the car.

Continue reading “Car Alarm Hacks 3 Million Vehicles” →

Fail Of The Week: EPROMs, Rats’ Nests, Tanning Lamps, And Cardboard On Fire

January 2, 2019 by Elliot Williams 87 Comments

It all started when I bought a late-1990s synthesizer that needed a firmware upgrade. One could simply pull the ROM chip, ship it off to Yamaha for a free replacement, and swap in the new one — in 2003. Lacking a time machine, a sensible option is to buy a pre-programmed aftermarket EPROM on eBay for $10, and if you just want a single pre-flashed EPROM that’s probably the right way to go. But I wanted an adventure.

Spoiler alert: I did manage to flash a few EPROMs and the RM1X is happily running OS 1.13 and pumping out the jams. That’s not the adventure. The adventure is trying to erase UV-erasable EPROMS.

And that’s how I ended up with a small cardboard fire and a scorched tanning lamp, and why I bought a $5 LED, and why I left EPROMs out in the sun for four days. And why, in the end, I gave up and ordered a $15 EPROM eraser from China. Along the way, I learned a ton about old-school UV-erasable EPROMs, and now I have a stack of obsolete silicon that’s looking for a new project like a hammer looks for a nail — just as soon as that UV eraser arrives in the mail.

Continue reading “Fail Of The Week: EPROMs, Rats’ Nests, Tanning Lamps, And Cardboard On Fire” →

35C3: Finding Bugs In Bluetooth

December 30, 2018 by Elliot Williams 24 Comments

[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.

In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.

As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the ~~address~~ handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.

All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.

Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.

You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.

Continue reading “35C3: Finding Bugs In Bluetooth” →