64×16 LED MQTT Laundry Display

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.

mqtt-led-matrix-driver-boardHe 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

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

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

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

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

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.

Finding ESP8266 Inside Big-Box Store IoT Plugs

When we buy new shiny toys, we usually open them up to at least have a look. [Scott Gibson] does the same, apparently. He found an ESP8266 module inside the EcoPlug brand WiFi-controlled wall switches.

The original device was intended to be controlled by a (crappy) app. He sniffed the UDP packets enough to send the on-off signals to an unmodified device, but where’s the fun in that? [Scott] gave it an upgrade by replacing the ESP8266’s firmware with his own and now he’s got a much more capable remote switch, one that speaks MQTT like the rest of his home automation system.

Continue reading “Finding ESP8266 Inside Big-Box Store IoT Plugs”