What You Should Know —Now

According to a recent Gartner report, it is estimated that 20.4 billion connected “things” will be in use worldwide by 2020. There are already twice as many devices connected to the internet than there are people on our planet.

The concept of IoT and IoT security is no longer new. I am sure, terms like "Hardware Security," "Machine-to-Machine Security," "Connected Device Security," and "Embedded Device Security" ring a bell. While they all have slightly different connotations, these terms all refer to the same concept of an embedded device that is network enabled and part of the growing Internet of things, connected world. IoT forms the basis for some of the most prevalent devices we use in our day-to-day life — smart watches, virtual assistant services, smart home devices, and many more.

There are 2 primary components of any IoT system:

• Hardware Devices that users use (the "Things"). The main purpose of the device is to provide the user with an interface that they can interact with.
• Back-End Components that the devices communicate with and perform the lionshare of data aggregation and processes.

There are various attack vectors that can be used to compromise an IoT device:

Firmware Running on The Device

As device manufacturers grapple with time to market pressures, vulnerabilities will not be discovered until after release. Most organizations do not have a proper patch management process in place. If the firmware updates are not cryptographically signed and sent over a secure channel, there is no way of identifying if the firmware was modified before being flashed on to the device. Similar attacks would be valid for an insecurely configured boot loader or if the checks are not performed at every stage of the boot sequence.

Device Hardware

IoT hardware components need to communicate with each other and other devices over standard protocols like I2C or SPI.

Leveraging tools like Bus Pirate (http://dangerousprototypes.com/docs/Bus_Pirate), Shikra (https://int3.cc/products/the-shikra), or Logic Analyzers (https://www.saleae.com/), an attacker with physical access to the device can sniff the data sent over the communication channel and dump the contents of the chips that are storing the data.

In addition to the communication protocol, the physical boards normally have ports like JTAG and UART that are used for debugging purposes. The JTAG port also allows for reading/writing to the firmware post production. If these ports are active in production devices, an attacker can use tools like Jtagulator (https://www.grandideastudio.com/jtagulator/) to extract the existing firmware, reverse engineer its functionality, or to flash a newly modified firmware.

Device Radio and Network Communication

Wi-Fi and Bluetooth configurations present major security challenge when trying to secure IoT devices. The attacks could be based off weak configurations or discovery modes. Lack of Transport Encryption exposes data in transit to tampering by parties that can execute Man-in-the- Middle (MitM) attacks.

For IoT systems, such data, they can include authentication credentials, session identifiers, and private user information. The attacker might also be able to tamper with unencrypted communications in order to alter device behavior, for example, changing the temperature on a networked thermostat.

Radio interface has also become an increasingly common attack surface on many IoTdevices. NFC, RFID, Zigbee, and Z-Wave are some well-known examples. Though relatively newer, an attacker can use a variety of tools to sniff, intercept, and modify these radio protocols.

Mobile, Web, and Other Back-End Interfaces

The back-end interface is often the most exposed and vulnerable component of an IoT solution. Attackers can use the same tools and techniques to attack them as they have been using to attack other web applications. Weak local encryption, hardcoding of passwords, and a lack of secure password policy is far too common and a very lucrative attack vector.

Authentication/Authorization

Strong authentication and authorization are absolute essentials for securing an application domain, especially the Internet of Things. It is a common authorization error to assume that methods on the IoT devices that do not have a calling UI element will not be accessible by that user. Under this false assumption, users may be able to access sensitive information or secure functionality once it is discovered. This can be done by means of tools like Burp Suite (https://portswigger.net/burp) or Mallory (https://github.com/intrepidusgroup/mallory).

The IoT device is only as secure as the hardware and software components that it is made up of. We hope this post will help enterprises secure against the known and the unknown IoT attack vectors out there.