[Symantec] Reports Hajime seems to be a white hat worm that spreads over telnet in order to secure IoT devices instead of actually doing anything malicious.
[Brian Benchoff] wrote a great article about the Hajime Worm just as the story broke when first discovered back in October last year. At the time, it looked like the beginnings of a malicious IoT botnet out to cause some DDoS trouble. In a crazy turn of events, it now seems that the worm is actually securing devices affected by another major IoT botnet, dubbed Mirai, which has been launching DDoS attacks. More recently a new Mirai variant has been launching application-layer attacks since it’s source code was uploaded to a GitHub account and adapted.
Hajime is a much more complex botnet than Mirai as it is controlled through peer-to-peer propagating commands through infected devices, whilst the latter uses hard-coded addresses for the command and control of the botnet. Hajime can also cloak its self better, managing to hide its self from running processes and hide its files from the device.
The author can open a shell script to any infected machine in the network at any time, and the code is modular, so new capabilities can be added on the fly. It is apparent from the code that a fair amount of development time went into designing this worm.
So where is this all going? So far this is beginning to look like a cyber battle of Good vs Evil. Or it’s a turf war between rival cyber-mafias. Only time will tell.
You’d be forgiven for thinking this was going to be an anti-IoT rant: who the heck needs an IoT rice cooker anyway? [Microentropie], that’s who. His rice cooker, like many of the cheapo models, terminates heating by detecting a temperature around 104° C, when all the water has boiled off. But that means the bottom of the rice is already dried out and starting to get crispy. (We love the crust! But this hack is not for us. This hack is for [Microentropie].)
So [Microentropie] added some relays, a temperature sensor, and an ESP8266 to his rice cooker, creating the Rice Cooker 2.0, or something. He tried a few complicated schemes but was unwilling to modify any of the essential safety features of the cooker. In the end [Microentropie] went with a simple time-controlled cooking cycle, combined with a keep-warm mode and of course, notification of all of this through WiFi.
There’s a lot of code making this simple device work. For instance, [Microentropie] often forgets to press the safety reset button, so the ESP polls for it, and the web interface has a big red field to notify him of this. [Microentropie] added a password-protected login to the rice cooker as well. Still, it probably shouldn’t be put on the big wide Internet. The cooker also randomizes URLs for firmware updates, presumably to prevent guests in his house from flashing new firmware to his rice cooker. There are even custom time and date classes, because you know you don’t want your rice cooker using inferior code infrastructure.
In short, this is an exercise in scratching a ton of personal itches, and we applaud that. Next up is replacing the relays with SSRs so that the power can be controlled with more finesse, adding a water pump for further automation, and onboard data logging. Overkill, you say? What part of “WiFi-enabled rice cooker” did you not understand?
Security for anything you connect to the internet is important. Think of these devices as doorways. They either allow access to services or provides services for someone else. Doorways need to be secure — you wouldn’t leave your door unlocked if you lived in the bad part of a busy city, would you? Every internet connection is the bad part of a busy city. The thing is, building hardware that is connected to the internet is the new hotness these days. So let’s walk through the basics you need to know to start thinking security with your projects.
If you have ever run a server and checked your logs you have probably noticed that there is a lot of automated traffic trying to gain access to your server on a nearly constant basis. An insecure device on a network doesn’t just compromise itself, it presents a risk to all other networked devices too.
The easiest way to secure a device is to turn it off, but lets presume you want it on. There are many things you can do to protect your IoT device. It may seem daunting to begin with but as you start becoming more security conscious things begin to click together a bit like a jigsaw and it becomes a lot easier.
Continue reading “IoT Security is Hard: Here’s What You Need to Know”
[Pen Test Partners] have found some really scary vulnerabilities in AGA range cookers. They are connected by SMS by which a mobile app sends an unauthenticated SMS to the AGA to give it commands for instance preheat the oven, You can also just tell your AGA to turn everything on at once.
The problem is with the web interface; it allows an attacker to check if a user’s cell phone is already registered, allowing for a slow but effective enumeration attack. Once the attacker finds a registered device, all they need to do is send an SMS, as messages are not authenticated by the cooker, neither is the SIM card set up to send the messages validated when registered.
This is quite disturbing, What if someone left a tea towel on the hob or some other flammable material before leaving for work, only to come back to a pile of ashes? This is a six-gazillion BTU stove and oven, after all. It just seems the more connected we are in this digital age the more we end up vulnerable to attacks, companies seem too busy trying to push their products out the door to do simple security checks.
Before disclosing the vulnerability, [Pen Test Partners] tried to contact AGA through Twitter and ended up being blocked. They phoned around trying to get in contact with someone who even knew what IoT or security meant. This took some time but finally they managed to get through to someone from the technical support. Hopefully AGA will roll out some updates soon. The company’s reluctance to do something about this security issue does highlight how sometimes disclosure may not be enough.
[Via Pen Test Partners]
With a plethora of IoT projects and inexpensive commercial smart light fittings and mains switches appearing, you might be forgiven for thinking that another offering in this crowded marketplace would be superfluous. But there is always room for improvement in any field, and in this particular one [Xose Pérez] has done just that with his Espurna board.
This board is a very well executed ESP8266 mains relay, with an on-board mains power supply and power monitoring. It was designed with his Espurna (“Spark” in Catalan) custom firmware in mind, which offers support for Alexa, Domoticz, Home Assistant and anything that supports MQTT or HTTP REST APIs.
Best of all, it’s a piece of open source hardware, so you can download everything you need from his GitHub repository to create your own. For the ultimate in convenience you can even order the PCB ready-made from OSH Park.
As a demonstration of the Espurna board in a real application, he’s produced a smart socket project neatly enclosed in a wall-wart style box with an inbuilt Euro style plug and socket.
We’ve featured [Xose]’s work several times before here at Hackaday, he’s something of an IoT wizard. Most recently there was his work with Alexa and the ESP8266, but before that was his MQTT LED array for his laundry monitor.
It’s long been a staple of future-gazing, the idea that we will reach a moment at which all of life’s comforts can be summoned at the press of a button. Through the magic of technology, that is, without the army of human servants with which wealthy Victorians surrounded themselves to achieve the same aim.
Of course, to reach this button-pressing Nirvana, someone has to make the buttons. There are plenty of contenders for the prize of One Button To Rule Them All, the one we’ll probably have seen the most of is Amazon’s Dash. Today though we’re bringing you another possibility. [Hendra Kusumah]’s A.I.B. (Another IoT Button) is as its name suggests, a button connected to the Internet. More specifically it’s a button that connects to IFTTT and allows you to trigger your action from there.
Hardware wise, it couldn’t be simpler. A button, a Particle Photon, some wires, and a resistor. Then install the code on the board, and away you go. With a small code change, it also works with an ESP8266. That’s it, it couldn’t be simpler. You might ask where the fun in that lies, but you’d be missing the point. It’s the event that you trigger using the button that matters, so why make creating the button a chore?
We’ve shown you many IoT buttons, just a couple of posts are this ESP8266 button and a look at the second-generation Amazon Dash.
There is a new class of virii in town, specifically targeting Internet of Things (IoT) devices. BrickerBot and its variants do exactly as their name says, turning your smart devices into bricks. Someone out there has gotten tired of all the IoT security flaws and has undertaken extreme (and illegal) measures to fix the problem. Some of the early reports have come in from a security company called Radware, who isolated two variants of the virii in their honeypots.
In a nutshell, BrickerBot gains access to insecure Linux-based systems by using brute force. It tries to telnet in using common default root username/password pairs. Once inside it uses shell commands (often provided by BusyBox) to write random data to any mounted drives. It’s as easy as
dd if=/dev/urandom of=/dev/sda1
With the secondary storage wiped, the device is effectively useless. There is already a name for this: a Permanent Denial-of-Service (PDoS) attack.
Now any card carrying Hackaday reader will know that a system taken down like this can be recovered by re-flashing through USB, JTAG, SD, other methods. However, we’re not BrickerBot’s intended audience. We’ve all changed our devices default passwords, right? RIGHT?
For more IoT security, check out Elliot’s excellent article about botnets earlier this year, and its follow-up.