IoT devices in the news have been proliferating at an ever-increasing rate. Both hardware manufacturers and news agencies are trying to capture the attention of the general public with the next killer device and/or application combinations.

More recent IoT news items included analysis on the Mirai botnet [0] and its effect on the internet as a whole, and a more jokingly unintended consequence of IoT device implementations, the news about “Alexa, buy me a dollhouse” broadcast on national television in the US, triggering various orders for all the station’s Alexa-device owning viewers (with follow up stories about the original triggering even more orders).


The Mirai malware (“command and control centre was written in Go (1197 lines of code) and its botnet agent was programmed in C (5732 lines of code)” [1]) effectively uses default usernames and passwords, of 60 common factory defaults, to log into and infect devices to further spread itself. Leaving users unaware as to the infection, the devices keep functioning normally, except for the increased use in bandwidth. Although a simple fix is possible, device owners can simply reset the devices as the malware is not persistent in its initial implementation, devices were however typically reinfected within minutes of the reset. The malware, that seemingly does not play well with others of its kind, uses a technique called memory scraping to clear other possible botnet processes (read: competitors) from memory, and also included a “don’t mess with” list, showing the developer(s)’ “concerns for drawing attention to their activities”. [1]

Akamai’s post-mortem [3] on the DDoS event mentions traffic of up to 620 Gbps or “nearly double that of the previous peak attack” on their platform, for the blog of the security Blog Krebs on Security. Akamai aims to provide DDoS protection. The end effect of this particular event lead to the creation of Google’s project Shield to aid journalists from DDoS attacks, as Akamai bowed out on its pro bono support of the victimized security journalist Brian Krebs [2].

According to Flashpoint researchers [4] at least one attack was initiated from the Mirai Command and Control server although they do not consider the attackers to be either politically motivated or a nation state actor. What is however interesting is the leveraging of a malware platform for modification and future configuration of the botnet, in order to ensure longer term persistence amidst possible mitigations effected by security professionals. Claiming ownership and making the initial source-code available for review purposes, Anna-senpai (user on hackerforums [5]) posted a write up on the functioning of the system as well as sources.

The question then becomes, how something as basic as default username and password combinations can affect basic infrastructure with such a massive amount of traffic leading to service interruption, and more importantly, how could one go ahead in preventing this in future?

Standardization and governing body pressure

In the US, the Federal Trade Commission launched both a $25k prize competition [6], that “challenges the public to create a solution (“tool”) that consumers can use to guard against security vulnerabilities in software found on the Internet of Things (IoT) devices in their homes”, and a complaint against Taiwanese manufacturer D-Link [7] for putting customers at risk with their internet routers and web cameras.

In Europe focus is also shifting towards enforced security standards and best practices for IoT vendors, by the European Commission. “That’s really a problem in the internet of things. It’s not enough to just look at one component. You need to look at the network, the cloud. You need a governance framework to get certification,” Thibault Kleiner – deputy head of cabinet (4 October 2016) [7]

Secure development and the OWASP angle

OWASP’s IoT attack surface areas document is still in draft form and covers the following areas of concern: ecosystem access control, device memory, device physical interfaces, device web interface, device firmware, device network services, admin interfaces, local data storage, third-party APIs, mobile application, vendor backed APIs, ecosystem communication and network communication.

The OWASP list shows clearly the plethora of considerations both security operations personnel have to consider when introducing IoT devices into their information technology ecosystem, and IoT hardware and software developers / integrators when planning and designing these devices.

Compass IoT challenge for European Cyberstorm

Here at Compass we wanted something to physically put in the hands of conference attendees at the European Cyberstorm of 2016. The low-cost ESP8266 WiFi chip, with full TCP/IP stack and micro controller unit looked interesting (for those hardware interested amongst you, look out for the follow up ESP32 chip) and Reto Schädler (see his more comprehensive post here) designed a bIOTech (pun intended) device with the chip that could monitor the moisture levels of potted plants and communicate this back to the plant owner with an email update, below given trigger levels of moisture.

Some intentionally built-in vulnerabilities allows for further fun (we didn’t want those receiving the device to just pot it and run) and a related Cyberstorm jeopardy (non attack/defense related) hardware challenge that required teams to hack the device was also created. The intentional vulnerability is that the firmware does not verify the integrity of certificates and can therefore also be used to demonstrate how a faulty security implementation leads to the possibility of man-in-the-middle attacks, to potential customers.

For the European Cyberstorm Challenge (ECSC) of 2016, this bIOTech device was supplied to the respective teams one day in advance with the standard firmware (Cyberstorm device setup), in order to get the team familiar with the modes of operation of the device (configuration mode – for AP setup, programming mode – for UART software loading, and operational mode – standard measurement and communication mode). On the day of the challenge, the same hardware was supplied to teams but with different firmware (CTF device setup). The EEPROM contained the new (non-standard) configuration data including access point, password, device identifier and unique identifier. Teams were required to first write their own software to dump the EEPROM information, then load their custom software to the devices in programming mode and finally read out the memory in order to be able to complete the challenge by reading out the memory, access point password and unique device ID.

Reto Schädler shared the caveats whilst designing conceptualization and mentioned that encryption is costly on this particular device, and therefore leeches battery power fast. The follow up chip (ESP32) has more features that include amongst others Bluetooth support and also hardware-accelerated support for AES, SHA2, EC and RSA-4096.

So what do you need to consider, to go from

Schema Compass bIOTech v1.0



Versuchsaufbau Compass bIOTech v1.0


to source code to


ready device


What to consider when designing IoT devices

First offered in 2016 the 2-day Compass Security developed IoT course already had several successful iterations with updated content related to hardware and software IoT protocols and technologies:


Those motivated to develop secure devices from conception to deployment can expect hands-on know-how training with lab exercises, run through challenges in the Hacking Lab infrastructure. Participants will also be given extended access to the challenges in order to hone their skills after the on-site training is completed.

Target audience: IoT hardware and software developers, security personnel responsible for IoT deployment and integration, IoT interested people.

The course will be held on the 14 and 15th of February in Bern, 9 and 10th of May in Berlin, and 29 and 30th of August in Zürich. For more information check the Compass IoT course page, or the Compass course calendar.