UK IT Specialist Unable To Boil Water, Make Tea

October 20, 2016 by Elliot Williams 54 Comments

In our latest episode of “IoT-Schadenfreude Theater” we bring you the story of [Mark], a British man who can’t boil water. Or more specifically, a man who can’t integrate MQTT with Amazon Echo, or IFTTT with HomeKit.

Yes, yes. We all love to laugh at a technology in its infancy. It’s like when robots fall down: it’s a cheap shot and things will surely get better, right? Indeed, the Guardian has had its fun with this particular WiFi kettle before — they’re British and nothing is more important than a remote-controlled cuppa.

Every time we hear about one walled-garden protocol not speaking to another, and the resulting configuration mayhem that ensues, we can’t help think that [Mike] was right: home automation has a software problem. But that’s putting the blame on the technology. (We’re sure that [Mark] could have made the kettle work if he’d just applied a little Wireshark.)

There’s another mismatch here — one of expectations about the users. A water kettle is an object that should be usable by grandmothers, and a complex networked device is clearly aimed at techies and early adopters. Combining the two is asking for trouble. Non-functioning IoT devices are the blinking 12:00 of our generation.

What do you think? Where’s the blame here? Poor design, bad software stack, stupid users, or failure of mega-corps to integrate their systems together? More importantly, how could we make it better?

Headline image:Fredy Velásquez Orozco, via Wikimedia Commons Thumbnail image: Markus Schweiss, also Wikimedia Commons.

64×16 LED MQTT Laundry Display

October 11, 2016 by Rich Hawkes 2 Comments

When you have an MQTT broker receiving messages, you want to be able to see them. [Xose Pérez] already had a system set up that sent him notifications, but he had a pair of 32×16 LED matrices, so he decided to make a big, bright sign to let him know when he got an important message sent to the broker.

[Xose Pérez] had already built a laundry monitor which was sending messages to an MQTT broker so he wouldn’t forget his laundry sitting in the washing machine. To communicate with the broker, he used an ESP-12. He had already ported an Arduino library for the Holtek HT1362C display drivers used by the matrices to work with his driver board.

He wanted to try out SMD soldering so he built a custom PCB to hold the ESP-12, power supply, passive components, and a connector and he describes his methods and results. Instead of hardcoded messages, he wanted the system to be configurable and display messages coming in, not only from his laundry system, but also from other sensors. A web interface, built with jQuery and WebSockets, running on the ESP-12 allows the user to subscribe to a topic on the broker and show a customized name and value on the display when a payload is available.

All-in-all, [Xose Pérez] has posted a great tutorial in which he goes over the hardware he built, the libraries he used, SMD soldering, how he made the enclosure, and even his choice in IDE (PlatformIO). He also posted the software, board designs and enclosure models software and hardware on bitbucket. The end result is a great looking LED matrix that displays not only his laundry’s status, but also anything else he wants to from his MQTT broker.

If you want to try your hand with MQTT, the ESP8266 is a wonderful device for sensor nodes, and any Linux box (like the Raspberry Pi) makes an easy broker. Check out [Elliot Williams’] Minimal MQTT series and you will be up and running in no time.

Reverse Engineering The Internet Of Coffee

October 11, 2016 by Jenny List 14 Comments

The public promise of the Internet Of Things from years ago when the first journalists discovered the idea and strove to make it comprehensible to the masses was that your kitchen appliances would be internet-connected and somehow this would make our lives better. Fridges would have screens, we were told, and would magically order more bacon when supplies ran low.

A decade or so later some fridges have screens, but the real boom in IoT applications has not been in such consumer-visible applications. Most of your appliances are still just as unencumbered by connectivity as they were twenty years ago, and that Red Dwarf talking toaster that Lives Only To Toast is still fortunately in the realm of fiction.

The market hasn’t been devoid of IoT kitchen appliances though. One is the Smarter Coffee coffee machine, a network-connected coffeemaker that is controlled from an app. [Simone Margaritelli] bought one, though while he loved the coffee he really wasn’t keen on its not having a console application. He thus set about creating one, starting with reverse engineering its protocol by disassembling the Android version of its app.

What he found was sadly not an implementation of RFC 2324, instead it uses a very simple byte string to issue commands with parameters such as coffee strength. There is no security, and he could even trigger a firmware upgrade. The app requires a registration and login, though this appears to only be used for gathering statistics. His coffee application can thus command all the machine’s capabilities from his terminal, and he can enjoy a drink without reaching for an app.

On the face of it you might think that the machine’s lack of security might not matter as it is on a private network behind a firewall. But it represents yet another example of a worrying trend in IoT devices for completely ignoring security. If someone can reach it, the machine is an open book and the possibility for mischief far exceeds merely pranking its owner with a hundred doppio espressos. We have recently seen the first widely publicised DDoS attack using IoT devices, it’s time manufacturers started taking this threat seriously.

If the prospect of coffee hacks interests you, take a look at our previous coverage.

[via /r/homeautomation]

How To Become Part Of An IoT Botnet

October 6, 2016 by Jenny List 28 Comments

We should all be familiar with the so-called Internet Of Things, a proliferation of Internet-connected embedded electronics. The opportunities offered to hardware hackers by these technologies have been immense, but we should also be aware of some of the security issues surrounding them.

Recently, the website of the well-known security researcher [Brian Krebs] suffered a DDoS attack. What made this attack different from previous ones wasn’t its severity, but that it had been directed not from botnets of malware-laced Windows PCs but from compromised IoT devices.

One might ask how it could be possible to take control of such low-end embedded hardware, seeing as it would normally be safely behind a firewall, preloaded with its own firmware, and without a clueless human at its terminal to open malware-laden email attachments. The answer is quite shocking but not entirely surprising, and lies in some astonishingly poor security on the part of the devices themselves. An exposé of one such mechanism comes courtesy of [Brian Butterly], who took an unremarkable IP webcam and documented its security flaws.

The camera he examined exposes two services, a web interface and a Telnet port. While from a security perspective their lack of encryption is a concern this should not pose a significant danger when the device is safely on a private network and behind a suitable firewall. The problem comes from its ability to send its pictures over the Internet, for the owner to be able to check their camera from their phone some kind of outside access is required. Expensive cameras use a cloud-based web service for this task, but the cheap ones like the camera being examined simply open a port to the outside world.

If you are familiar with basic firewall set-up, you’ll be used to the idea that open ports are something that should be under control of the firewall owner; if a port has not been specifically opened then it should remain closed. How then can the camera open a port? The answer lies with UPnP, a protocol enabled by default on most home routers that allows a device to request an open port. In simple terms, the camera has an inherently insecure service which it asks the router to expose to the world, and in many cases the router meekly complies without its owner being any the wiser. We suspect that many of you who have not done so already will now be taking a look at your home router to curtail its UPnP activities.

We covered the [Brian Krebs] DDoS story as it unfolded last week, but we’re sure this is likely to be only the first of many stories in this vein. As manufacturers of appliances struggle to learn that they are no longer in the dumb appliance business they need to start taking their software security very seriously indeed.

Webcam image: Asim18 (Own work) [CC BY-SA 3.0], via Wikimedia Commons.

Distributed Censorship Or Extortion? The IoT Vs Brian Krebs

September 29, 2016 by Elliot Williams 118 Comments

Now it’s official. The particular website that was hit by a record-breaking distributed denial of service (DDOS) attack that we covered a few days ago was that of white-hat security journalist [Brian Krebs]: Krebs on Security.

During the DDOS attack, his site got 600 Gigabits per second of traffic. It didn’t involve amplification or reflection attacks, but rather a distributed network of zombie domestic appliances: routers, IP webcams, and digital video recorders (DVRs). All they did was create HTTP requests for his site, but there were well in excess of 100,000 of these bots.

In the end, [Krebs’] ISP, Akamai, had to drop him. He was getting pro bono service from them to start with, and while they’ve defended him against DDOS attacks in the past, it was costing them too much to continue in this case. An Akamai exec estimates it would have cost them millions to continue defending, and [Brian] doesn’t blame them. But when Akamai dropped the shields, his hosting provider would get slammed. [Krebs] told Akamai to redirect his domain to localhost and then he went dark.

Continue reading “Distributed Censorship Or Extortion? The IoT Vs Brian Krebs” →

Extra-Large Denial Of Service Attack Uses DVRs, Webcams

September 26, 2016 by Elliot Williams 46 Comments

Brace yourselves. The rest of the media is going to be calling this an “IoT DDOS” and the hype will spin out of control. Hype aside, the facts on the ground make it look like an extremely large distributed denial-of-service attack (DDOS) was just carried out using mostly household appliances (145,607 of them!) rather than grandma’s old Win XP system running on Pentiums.

Slide from <a href="http://slideplayer.org/slide/906693/">this talk</a> by Lisa Plesiutschnig — Replace computers with DVRs. Slide from this talk by Lisa Plesiutschnig

We can argue all day about whether a digital video recorder (DVR) or an IP webcam is an “IoT” device and whether this DDOS attack is the biggest to date or merely among them, but the class of devices exploited certainly are not traditional computers, and this is a big hit. Most of these devices run firmware out of flash, and it’s up to the end user (who is not a sysadmin) to keep it up to date or face the wrath of hackers. And it’s certainly the case that as more Internet-facing devices get deployed, the hacker’s attack surface will grow.

Why did the DDOS network use these particular devices? We’re speculating, but we’d guess it’s a combination of difficult-to-update firmware and user “convenience” features like uPnP. To quote the FBI “The UPnP describes the process when a device remotely connects and communicates on a network automatically without authentication.” You can see how this would be good for both the non-tech-savvy and hostile attackers, right? (Turn off UPnP on your router now.)

We alternate between Jekyll and Hyde on the IoT. On one hand, we love having everything in our own home hooked up to our local WiFi network and running on Python scripts. On the other hand, connecting each and every device up to the broader Internet and keeping it secure would be a system administration headache. Average users want the convenience of the latter without having to pay the setup and know-how costs of the former. Right now, they’re left out in the cold. And their toasters are taking down ISPs.

Hackaday Prize Entry: Theia IoT Light-switch

September 24, 2016 by Jenny List 17 Comments

There are it seems no wireless-enabled light switches available in the standard form factor of a UK light switch. At least, that was the experience of [loldavid6], when he decided he needed one. Also, none of the switches he could find were open-source, or easy to integrate with. So he set out to design his own, and the Theia IoT light switch is the result.

In adapting a standard light switch, he was anxious that his device would not depend on the position of the switch for its operation. Therefore he had to ensure that the switch became merely an input to whichever board he designed, rather than controlling the mains power. He settled upon the ESP8266 wireless-enabled microcontroller as the brains of the unit, with a relay doing the mains switching. He first considered using an LNK304 off-line switching PSU chip to derive his low voltages, but later moved to an off-the-shelf switch-mode board.

So far two prototype designs have been completed, one for each power supply option. Boards have been ordered, and he’s now in the interminable waiting period for international postage. All the KiCad and other files are available for download o the project’s hackaday.io page, so you can have a look for yourselves if you are so inclined.

You might ask why another IoT light switch might be needed. But even though they are now available and inexpensive, there is still a gap for a board that is open, and more importantly does not rely on someone else’s cloud backend. Plus, of course, this board can be used for more than lighting.

Light bulb image: Осадчая Екатерина (Own work) [CC BY-SA 4.0], via Wikimedia Commons.