IoT Coop Door Cares For Chickens, Tests Home Automation

Most chickens are pretty good at putting themselves to bed when the sun sets, and [Eddy]’s chickens are no exception. But they’re not terribly thoughtful about closing up after themselves, so he set about on a long-term project to automate the door of their coop.

An open door overnight leaves chickens and their food vulnerable to predation. Rather than handle the chore manually and risk one forgetful moment that could wipe out his flock, [Eddy] used a servo to power the door and an Arduino to control it. To keep track of bedtime and wakeup, a Raspberry Pi looks up the local civil dawn and twilight times online and tells the Arduino when the moment is at hand. The Pi cleverly caches the times for use the next day in case the WiFi connection is down, and also provides a web interface to check on the door’s status and manually override the cycle. Result: safe, happy chickens.

If all this seems a bit much for a simple job, [Eddy] agrees. But he’s using this as a testbed to develop a home automation framework that can be retasked at will. Sounds like he’s on the right track to us, but for more IoT animal husbandry tips, he’ll want to check out this small farm automation effort.

Continue reading “IoT Coop Door Cares For Chickens, Tests Home Automation”

Hajime, Yet Another IoT Botnet

Following on the heels of Mirai, a family of malware exploiting Internet of Things devices, [Sam Edwards] and [Ioannis Profetis] of Rapidity Networks have discovered a malicious Internet worm dubbed Hajime which targets Internet of Things devices.

Around the beginning of October, news of an IoT botnet came forward, turning IP webcams around the world into a DDoS machine. Rapidity Networks took an interest in this worm, and set out a few honeypots in the hopes of discovering what makes it tick.

Looking closely at the data, there was evidence of a second botnet that was significantly more sophisticated. Right now, they’re calling this worm Hajime.

Continue reading “Hajime, Yet Another IoT Botnet”

UK IT Specialist Unable To Boil Water, Make Tea

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.)

Strongbad's VCR
Strongbad’s VCR

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

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”