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.
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. 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 can include authentication credentials, session identifiers and other tokens, 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 IoT devices. NFC, RFID, Zigbee, 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 Interface
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.
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. To help enterprises secure against the known and the unknown IoT attack vectors out there we have come up with a Tipsheet that can help gauge the current state of security for their IoT devices better.
Be Sure to Check Out All of Our Resources on Our Website Too: