The IoT is a vision, rather than an actual network. It’s the notion that with increasingly more devices empowered by communication facilities, those devices inevitably end up as entities in a network scheme.
Radio waves and cables have both been used to connect household devices (smart fridges, smartphone-controlled thermostats), animals (GPS trackers on pets, smart aquariums) and
other autonomous technology (wind turbines, forest fire detection sensors).
Rarely are these devices connected only inside their own encapsulated conversation. Often, the engineering behind them has provisioned for control or monitoring coming from the world-wide web. There is even an HTML protocol for connecting with a coffee pot!
The merits of having trivial devices connected to each other and the web are numerous, including: devices could coordinate with each other for better efficiency, they could be controlled, monitored or diagnosed remotely, they could have their firmware updated OTA (over the air) and et cetera.
Among the disadvantages, we can assume that whenever there’s a door, there’s a backdoor.
With the added complexity of such devices introducing bugs to previously never debugged operations such as “boil water” or “report that we are short on milk”, some exploitation of
those immature communication protocols is possible.
As a matter of fact, it has already happened.
Truly capable IoT devices usually employ the ARM CPU architecture. Until now, the peculiarity of ARM has kept cyber criminals at bay, with each ARM implementation relying on a bespoke
operating system.
However, with the increased usage of ARM devices (ARM being the most sold architecture during 2014) and the standardization efforts by virtually all the main hardware and software players, the
ground has become fertile for DDoS attackers to develop their impact capacity.
Not only that IoT devices are themselves a target for attackers, a more dangerous breach exists that allows them to be recruited into the botnet that DDoS attackers accumulate to do their bidding.
Spike is a DDoS toolkit comprising of a command center and infectious binaries. The command center is agnostic as to the type of binaries that report to it. The binaries themselves started as badly implemented, run of the mill, DDoS attacks (e.g., SYN floods). What makes it interesting is that it was “ported” from Linux to Windows and also ARM.
An infection would install the binaries inside the IoT device, then, they call back to the command center (the interface of which is in Chinese) and the operator can, from there, commandeer the device, telling it to send different DDoS attacks.
With Billions of ARM devices currently in operation, the motivation of the developers of Spike are obvious – build up a botnet that can dwarf PC-based botnets by sheer numbers.
Additionally, as IoT devices are often autonomous and rarely involve the user in a conversational transaction, when they go out of line, the user is not around to notice something’s wrong and the attack may proceed unnoticed for an extended amount of time. Spike-driven attacks have been known to reach hundreds of Gbps, requiring real heavy artillery to clean up the communication and prevent down time.
There are already security measures made available to the prudent administrator of IoT devices. Some of them are high-level but all are worth googling the forums for precise instructions on how to implement in a particular system:
1. ACL – Access Control List. If the manufacturer has forgotten by default to specify which user is allowed to do what on each file or folder on the device, the owner has due diligence to make sure that the root and system file structures are extremely picky as to whom they allow read/write permissions. This will ensure that the attacker can’t lodge in the zombifying code.
2. SNORT – for the layer-7 Get flood, an open source program such as Snort can be utilized with a rule in place that will exclude – and inform about – Get requests that fit the Spike signature.
3. System hardening – for ARM and IoT in general, have in mind the following top 10.
4. YARA rule – Is a format that allows identification – and sharing – of information inside the files. For Spike, this would the the payload files, which include a “Mr. Black” string inside the files, probably referring to the engineer’s name.
To put things in scale, the IoT platforms, as launching pads for DDoS attacks still do not represent a large amount of the threat landscape. Only several attacks have been conducted via Spike, albeit that some of them were quite significant, while the rest is done via regular x86 architecture botnets.
Apparently, the addition of embedded devices into the attack vectors is not a shift towards these devices being used exclusively instead of the traditional zombie computers. It is simply one more formidable weapon in the arsenal of Internet perpetrators, contributing to their total attack capacity and explaining at least some of the steep increase in the Gbps that attackers deliver on each assault.