Tag Archives: software

Four Common IoT Security Holes

If you follow the Internet of Things space, not a day passes where you do not see an analyst report or news article talking about IoT security vulnerabilities across every sector: consumer, enterprise, industrial and government/Smart City.

I’ve been working with Internet-connected devices (medical devices, industrial actuators, sensors for environmental, security monitoring, even military systems) for many years. In my job, I am lucky enough to able to work with industrial and enterprise devices daily. At home, I play with them both as a consumer and developer. Time and again, I see the following IoT security holes with alarming frequency:

Security Hole #1: Not Using Strong Encryption

It is amazing that in 2016 people are still not using strong encryption to protect important data. However, I frequently see IoT devices that use no encryption at all: they store and transmit data in the clear. Other devices use homegrown encryption techniques that are are unproven by peer review and relatively easy to hack.

Most of the arguments I have seen against encryption fall into three camps: 1) it is too computationally expensive for low-powered devices, 2) it is too hard to use for IoT protocols, and 3) the device data is too obscure to understand. Let’s look at each:

  1. Yes, encryption is computationally expensive. However, ongoing investments in the space are providing more efficient RSA, AES, and ECC algorithms that work on smaller devices. In addition, Moore’s Law is even allowing penny-sized devices to have enough power to use these.
  2. IoT protocols are also getting better and better at providing strong encryption and secure connections (see Security Hole #2).
  3. Finally, the old “Our-data-is-too-obscure-for-hackers-to-understand Argument” was proven a fallacy years ago, first by the credit card industry’s Cardholder Information Security Program, and later by its replacement: PCI DSS. Any disgruntled employee (or hacker masquerading as a contractor) can bypass the “obscurity protection.”

Not using strong encryption is probably the most egregious security vulnerability. Any 14-year-old can use downloadable packet sniffing programs to capture your data. Solutions that mitigate this risk are readily available. There is no excuse to not encrypting your data.

Security Hole #2: Not Using Secured Sessions

A common error is information/cyber security is forgetting that secure communication consists of two components:

  1. Encryption of data and
  2. Establishment of secured sessions

Secured sessions use protocols to establish mutual authentication and to exchange  shared secret that only the transmitter and receiver have. If you do not establish a secured session you are blindly guessing that the recipient of your data is the correct person. When you do not use secured session you invite a Man-In-The-Middle (MITM) attack where the attacker can intercept and redirect your transmissions.

Many people think they are not likely targets of a MITM attack. Here is simple scenario.

  • A disgruntled employee or hacker-posing-as-contractors first intercepts and copies traffic from your devices.
  • From this data, he learns what devices are attached to items of interest (a patient, your house, etc.). He can then also learn the normal pattern of communication from the device.
  • Next he replaces the data from your device to send his own. This can give the appearance that a patient who is sick is now health (or vice versa) or that your house is not being broken into (allowing his partners to break in). The hacker can even intercept your over-the-air commands and download programmable software or send commands to shut-down devices.

This work is technically hard, but doable with software downloadable on the Internet. If communication between your IoT devices and your secured (and encrypted), the hacker would have to gain enough permissions to get a hold of your SSL certificates and hijack DNS (if he has this, you are in a lot of trouble already). However, if the communication between your IoT devices and servers is not secured, a hacker can conduct this MITM attack from anywhere. By the time you learn about it, the damage will be long done.

Thankfully, there are many solutions available in the IoT domain that provide both strong encryption and secured sessions (plugging Security Holes #1 and #2):

  • If you are using standard “Internet of Servers” protocols, simply installing a full compliment of certificates will enable you to use SSL over TLS for HTTPS and FTPS (but not SFTP).
  • If you are using MQTT (one of my favorites), there are many brokers available that also provide SSL over TLS.
  • If you are using CoAP (which rides over UDP), you can use DTLS.
  • If your devices have edge constellations, you can turn on Bluetooth Security Mode 4 and get SSL with the same Elliptic Curve Diffie-Hellman secret key exchange used by the NSA.
  • You can even download and borrow the wonderful MTproto protocol designed by the folks over at Telegram (it is designed for low-powered, lossy, distributed communication).

None of these solutions are perfect. However, all reduce security risks significantly. Furthermore, all are evolving in the open source community as people find new vulnerabilities. Why more people do not use them is puzzling.

Security Hole #3: Not Protecting Against Buffer Overflow

When a hacker triggers a Buffer Overflow vulnerability, she typically causes a program to do two things: dump critical data and crash.

The first documented cases of Buffer Overview exploits data back to 1972. As more and more computers were connected to the Internet, these attacks became more pervasive. Fifteen years ago, Code Red highlighted to much of the general public what a Buffer Overflow exploit can do.

Over the past few years, application framework libraries have and higher-level languages, have added many defensive programming protection to make these vulnerabilities less prevalent than they were in the past. (As anyone who has encountered an awlful error page that shows you a stack trace error, these defenses are still far-from-perfect). Nevertheless, they have plugged many holes.

However, IoT devices are bringing this vulnerability back into the mainstream again. As most IoT devices operate with far less memory and CPU than expensive devices like your laptop or smartphone, their firmware and applications are primarily written in lower level programing languages. It is much easier to trigger buffer overflows in these languages than more forgiving higher level languages. Exception handling libraries are less robust. More often than not, memory management is handled using good old-fashioned C/C++ programming (there is no Garbage Collector to save you). This significantly raises the risk of buffer overflows in devices.

When buffer overflow crashes occur in the data center there is at least someone around to fix things. When they happen to a remote IoT device in the field, they can literally shut down a security or medical sensor. There is no IT or Ops department nearby to fix it. The device is shut down (at best, or bricked at worst). Essentially device is dead to world. Depending on what is was responsible for, lots real-world physical damage can ensure.

Devices that maintain continuously open Internet connections (like all those connected baby monitors) are especially prone to buffer flow attacks as remote hackers can discover them using port-scanning software. However, even industrial IoT devices that only pull commands and programs down over-the-air are vulnerable to MITM attacks that can shut them down by flooding data to the device (this reinforces the need to plug Security Holes #1 and #2 discussed above).

The fix to this problem is fairly clear:  implement defensive programming and test it aggressively. Today’s automation technologies for continuous integration and delivery make this a much easier and trustworthy process than it was even a decade ago.

Security Hole #4: Weak Systems Engineering

The fourth big security hole I commonly see spans the intersection of technical design, system processes, and human behavior. It essentially boils down to this: if you use flawless technology in ways that it is not intended, you can create big vulnerabilities. If I design perfectly secure medical device but put it on the wrong patient (accidentally or maliciously), I will prevent capture of data about that sensor. If someone who installs the security sensors in my house sets my account up to call their cell phone (and not mine), they can break in while I am gone and I trick the company into thinking it is a false alarm.

The way around this is to design IoT devices that work when things (humans, the network, servers, etc.) fail.

  • Build in redundancy (devices, network paths and servers) to mitigate technical failures
  • Build in positive and negative feedback looks to mitigate human failures. For example, I should not just be notified if my home security sensor goes off. I should should be notified if my smartphone and my security companies servers both cannot communicate with my home security IoT devices.

Plugging this systems engineering IoT security hole takes a combination of technology engineering and business process design.  This is a natural fit to the enterprise, where IoT can be used as a component of business transformation. In the consumer segment the answer is usually an ecosystem solution. Amazon’s and Google’s solutions stand out regarding robustness and security.


The Internet of Things offers great potential to transform how we work and live by removing many tedious tasks from our day-to-day activities. Making this a reality requires a secure Internet of Things. We will never make security perfect. However, we have the tools to make it trustworthy. What is needed is just the discipline to include them as we build new IoT devices, systems and processes.

Building a Native Mobile App Experience—Without the App

Note: This post was adapted from the more developer-oriented “Piggybacking on backbone.js for performant mobile web”, originally published on Sawdust Software.

Native mobile apps are great. They provide a rich user interface (UI). They can easily access other core applications (e.g., camera, calendar, message center) on your smartphone to create stickier, more immersive experiences. They routinely provide a much faster user experience (UX) in terms of menu traversal and screen-to-screen navigation.

However these benefits come at a cost. They require lots of work: learning, developing, and testing on an entirely different tech stack (most likely iOS or Android). They bind you to navigate a proprietary app store release and submission process (one far slower than the ability to release software on your own web farms). Worse, these are not one-time costs. They can double the cost of adding new features (as you have to develop these for web and native mobile). The also introduce a new mobile OS compliance cost: keeping your app up-to-date with new mobile OS releases—while supporting users on older mobile OS versions—can routinely add 30% to your costs of mobile development and testing.

In some situations, the benefits of using a native mobile app far outweigh the costs; in others they do not. Luckily, there are many technologies and approaches available when you want to create a mobile web experience and do not require (or want to) development of a native mobile app:

Create mobile web-optimized templates

The responsive web design (RWD) movement has gained much traction in the design and development community. While it is appealing to create universal web templates that can detect and respond to the size of the browser screen, this is not always ideal for mobile web. More often than not, universal web templates can have quite large file sizes. Downloading these over a 3G connection can be quite slow. Worse, they can burn battery life on your customer’s phones, leading them to not use your site on mobile.

When considering functionality for mobile pay attention to size of the pages you need users to download. If the desktop (or ever increasingly Tablet-plus-WiFi) versions of your HTML templates are large, create mobile-only templates that are smaller and optimized for download and display on smartphones. If you are on a standard web framework, you have a range of plug-ins you can add to easily detect then customers are accessing your site with a mobile device and serve these templates (e.g., Django Mobile, User Agent (for Rails), Spring Mobile Device Module). You can even use these to serve up a different experience for mobile tablet (vs. mobile smartphone) users.

Use HTML5 and jQuery Mobile to emulate native mobile UIs

Thanks to the rise of mobile and responsive web design, there are now many libraries available to develop lightweight (i.e., small file size) touch-responsive web interfaces using HTML5. Some great examples include: JQuery mobile (if you are a jQuery purist), jQT (if you have a Sass shop), and Zepto (if your really want super fast performance).

When you combine these with mobile browser detection (see above), you can serve up HTML interfaces that use widgets that are virtually indistinguishable from their native mobile counterparts to 80% of your customers:

Entirely HTML5, Sass and jQuery mobile web--with emulated iOS widgets (www.custommade.com)
Entirely HTML5, Sass and jQuery mobile web–with emulated iOS widgets (www.custommade.com)

It is worth pointing out that using these libraries not only lets you emulate a mobile app experience, using them also keeps your teams on a single technology stack. Developers building web UIs can easily switch over and develop mobile web equivalents (or vice versa). This makes life much more interesting for developers (they can do more, more easily) and management (people can do more and switch to whatever is most important more easily).

Use backbone.js to load navigation control into the browser

One of the reasons that native mobile apps are able to navigate (between menus and moving from screen to screen) so quickly is that they embed a model-view-controller (MVC) architecture directly into the app installed on the mobile device. In an MVC architecture, the Controller directs what Views (screens, menu elements) to display when a user touches (or clicks) on something. On native mobile apps, the Controller is located on the device itself (an is accessible virtually instantly). This is very different than “traditional” browser based web-applications, where the View Controller is hundreds (or thousands) of miles away on a web server—something made even worse when a smartphone is trying to ping a server over a 3G (or worse) mobile connection.

However, over the past 2-3 years, several JavaScript (JS) frameworks have been developed that solve this problem. All of these frameworks were created to simplify development of Single-page browser Applications (SPAs): rich web applications that approximate the interactivity of traditional “thick client” applications. They do this by loading MVC (or MVC-like) frameworks into the browser. This not allows browser-based apps to display updates without action by the end user; it also provides the secondary (and critical) benefit for mobile web apps of moving the View Controller from a remote server into mobile device in the hands of your customer:

Adding a SPA-oriented JS framework like Angular, Backbone or Knockout embeds a MVC architecture in the hands of your customer, just like a native mobile app does.
Adding a SPA-oriented JS framework like Angular, Backbone or Knockout embeds a MVC architecture in the hands of your customer, just like a native mobile app does.

As result web apps on a smartphone, tablet or desktop can be just as fast as native mobile OS apps. Several JS frameworks are available to achieve this. Google first developed Angular.js in 2009. Steve Sanderson of Microsoft developed Knockout.js a year later. Jeremy Ashkenas also developed Backbone.js—a favorite of many eCommerce and consumer web companies—in 2010.


This technology stack does not allow for completely offline operation, something that is possible to achieve with a native mobile application. If you need to support offline operation (for extended periods of time) without losing any data, you will still need to build a native mobile app with an embedded SQLite database. However, that is not the use case more the vast majority of mobile apps.

Credits & Disclaimer

This author of this post used to lead technology at CustomMade Ventures where we have used HTML5, Sass, jQuery Mobile, Backbone.js and Django Mobile to create a mobile web experience for ideation and collaboration for our two-sided marketplace. Translation of this architecture into reality is the work of two great members of our Engineering team: Brendan Smith and Mike Manning.