Security Testing the Internet of Things: Dynamic testing (Fuzzing) for IoT security

What is the Internet of Things (IoT)?

The Internet of Things (IoT) encompasses any and all products that are connected to the internet or to each other. Any product which requires connection to a home, car or office network to deliver its complete set of features falls under this broad term. In fact cars themselves are now a component of the IoT as they now exchange data with the manufacturer routinely if not continuously.

All things IoT, collect data during use and often share that info with their manufacturers without the users being aware that it is being collected. In many cases product functions are dependent upon connection to the internet and may be controlled to a great degree by the manufacturer. This concept of making all components of our increasingly complicated lives communicate with each other, with us, and with internal and external software applications, is what IoT is all about.

Why Do We Need IoT Security?

Manufacturers of every kind of electronic or electrical device are rushing to add features which require connection to the internet. In their rush to market these companies many of which have no prior experience with networked devices are bound to overlook the complications of hardware and software security design and construction in the haste to get the newest, coolest function working at lowest cost.

It is nearly a rule that the makers of products that test these new frontiers will apply the same guidelines to their selection of processing hardware as they do for any other product components they purchase. The oldest chips whose designs were long ago paid off and are now dirt cheap are attractive building blocks for device designs that need only limited capabilities or capacities.

Security Comes Last.

Testing of the software that is written for a household appliance or child’s toy has only one goal – confirm that it works and will be easy to set up (with lots of default selections even passwords). Security is an afterthought at best.

The hardware (chipset) as used in most new products is very old and often has multiple known vulnerabilities. The software that is included with IoT devices and which rarely gets any in-depth security testing almost always has its own set of security issues. The result is that tens of thousands and soon hundreds of millions of appliances, devices and toys being installed into home and business networks are ripe for hacking. And once a vulnerability is discovered in a widely distributed product line there will be thousands or potentially hundreds of thousands of homes and businesses that will be open to having their IoT devices hijacked and potentially opening their entire network to view and attack.

What are the Different IoT Applications?

On the consumer front, IoT is everywhere.

At home 

In the smart home, Internet-connected objects such as televisions, thermostats, lights, door locks and even refrigerators are becoming common. They offer homeowners control of home services and functions without actually being home. Smart refrigerators can monitor the amount of milk left and automatically reorder from a preferred store. Washers and dryer’s ring your phone when they are done.

On person

Health and fitness-oriented wearable devices that offer biometric measurements such as heart rate, perspiration levels, and even complex measurements like oxygen levels in the bloodstream are some of the examples of wearable IoT-connected devices. In medicine, surgically implanted devices report back to the doctor regarding health status and in some cases accept instruction from medical staff to take action. And all of this data goes back to a central database owned by the manufacturer and provides a stream of data that is potentially hackable.

On the move 

Transportation systems and now cars utilize a large number of sensors, often working in combination with GPS to best get from point A to point B in a safe and efficient manner. Beyond that, cars are getting even smarter. On board navigation systems, diagnostic systems that alert you (and the manufacturer) about everything from faulty lights to tire pressure.

IoT for Businesses

• RFID tags within anti-theft tags that help retailers in monitoring inventory.
• Driverless trucks operate 24×7, increasing production levels.
• Critical infrastructure systems such as power generation and delivery systems, water systems, transportation systems are bringing in more IoT devices to improve their accuracy of data and control.
• Farms use connected sensors to keep a check on crops and herds to optimise distribution of and pesticides, fertilizer and food.
• IoT-connected devices alert shop floor managers about faulty or malfunctioning equipment.
• Entire Supply chains that span multiple companies and even continents are integrating their production systems to enable better management of machines and people through monitoring and control of their actions or their locations.

IoT generates and shares loads of data and as such the individual devices are susceptible to malicious attacks, data misuse and forced data breaches thus making a strong case for dynamic testing, code, logic and vulnerability assessment at the product development phase itself.

What are the Most Vulnerable IoT Devices?

According to Gartner, the number of Internet-connected devices is expected to reach 50 billion by 2020. While IoT is going to improve life for many, the number of security risks that consumers and businesses are prone to face will increase exponentially.

Stakeholders in the IoT domain face privacy issues, most of the time being unaware of the situation. As such, IoT devices have come under increasing levels of scrutiny in recent months over poor security controls and numerous vulnerabilities. Some of the common problems which have come up due to the spread of IoT include the following:

Personal Data

IoT users give their approval for collection and storage of data without having adequate information or technical knowledge. Data collected and shared with or lost to third parties will eventually produce a detailed picture of our personal lives that users would never consider sharing with any stranger they met on the street.

Anonymity has been a constant issue in the world of IoT, where IoT platforms barely give any importance to user anonymity in the process of sharing data.

Spying

Cyber attacks are likely to become an increasingly physical (rather than simply virtual) threat. Many Internet-connected appliances, such as cameras, televisions sets, and kitchen appliances are already enabled to spy on people in their own homes. Such devices accumulate a lot of personal data, which gets shared with other devices or are held in databases by organisations, and they are prone to being misused.

Automotive Vulnerabilities

Computer-controlled automobile devices such as horns, brakes, engine, dashboard, and locks are at risk from hackers who may get access to the on-board network and manipulate at will, for fun, mischief or personal gain.

Health-related Data

The concept of layered security and redundancy to manage IoT-related risks is still in a nascent stage. For instance, the readings of smart health devices to monitor a patient’s condition may be altered, which again when connected to another device for prescribing medicines post analysis, will be compromised, and will adversely affect the patient’s diagnosis or treatment.

There is a high probability of failure to get access to a particular website or database when multiple IoT-based devices try connecting to it, resulting in customer dissatisfaction and a drop in revenue.

Static and dynamic testing for IoT-connected devices

As IoT-connected devices become an integral part of our daily lives, it is crucial that these devices undergo thorough testing, and establish minimum baseline for security.

If any testing is done at all, static testing is the most frequently implemented process. But static testing is not intended or designed to find vulnerabilities that exist in the ‘off the shelf’ components such as processors and memory into which the application will be installed.

Dynamic testing, on the other hand, is capable of exposing both code weaknesses and any underlying defects or vulnerabilities introduced by hardware and which may not be visible to static analysis. Also dynamic testing often turns out to be a more pragmatic way of testing the IoT devices and plays a pivotal role in finding out vulnerabilities that are created when new code is used on old processors. As such, manufacturers who purchase hardware and software from others must do dynamic testing to ensure the items are secure.

QA testing for networked hardware and web applications

Developers produce applications that to a greater or lesser degree exchange information by adhering to a protocol as closely as possible. QA then tests application functionality against that protocol in the perfect world of the testing laboratory. Given the numerous ways programmers can make mistakes, looking for security vulnerabilities in a piece of software should be an integral part of the development process. Strangely, that is not always the case as testing the security of a particular product can be an expensive proposition and developers often weigh expense against cost of other factors involved in releasing the product to its customers. Because of this, even software developed in an environment stringently cognizant of security risks is most likely released without full testing.

Naturally when the application is released, hackers will bash away at it with every possible corrupted form of the protocol to create an error in the application. By pushing at the edges of the envelope of the protocol, they may find a way to trip up the application and create a buffer overflow, the most frequently leveraged design error.

How Do Hackers Use Buffer Overflows?

How are hackers finding buffer overflow opportunities missed during development and standard pre-release QA? A wide range of tools have been developed by the hacker community to enable the rank and file to find new exploits. These tools, fuzzers, work by creating and feeding a wide range of unexpected or corrupted inputs looking for a combination that will break the application. The production of these tools has become a small industry of its own. The QA world has attempted to adapt these rough and ready hacker tools into their test processes with some success, but also with many headaches. Most of these hacker-developed fuzzers are focused on a single type of code weakness or just on a single protocol or even on a single application.

In case of IoT-connected devices, it is important for enterprises to identify traffic patterns and differentiate between the legitimate and malicious ones. For instance, an employee may download some apparently genuine app on a smartphone given to him by his employer, without knowing that the app has some malware. In such cases, the organisation must be prepared with the right set of processes to ensure ample security promptly.

Default Credentials in IoT Vulnerability

Most IoT devices come with default credentials when used for the first time, which means known administrator IDs and passwords. Also some devices come with a built-in Web server. This helps admins to log in and manage the device remotely. This massive vulnerability can easily encourage hackers to misuse available confidential data.To avoid any data leakage, enterprises must develop a strict assigning process, where the initial settings of the device can be tested, verified to find out any kind of vulnerabilities that may exist, validated flaws that may have been identified should be closed, and a “good-to-go” certification from the compliance team should be issued before the device is brought to the market.

Even after all the QA testing being done, buffer overflow error tests, protocol breach tests, and black-box testing should be done to further reduce the scope of adding vulnerabilities to the devices.

Translation of Requirements Cause Vulnerabilities

Translation of requirements during application development is the first cause of most programming errors. For instance, during the development of a smart fridge application, a project manager translates the requirements from the desired end to the programming team, which members translate to individual programming assignments. The programmers then translate the assignment into a proper syntax for the programming language written by someone else, which a programming language interpreter translates into the corresponding machine code. All these translations are sources of potential programming errors during the design stage.

Off-by-one errors, programming language use errors, integer overflows are all examples of errors generated by a programmer while translating a concept to a proper algorithm. For example, to hold ‘n’ items that are each ‘m’ bytes long, the programmer may tell the program to allocate n*m bytes. If m*n is larger than the biggest number that can be represented, less memory will be allocated than intended. This may lead to a buffer overflow. In another instance, if a programmer assumes that a variable contains only positive integers, but if the integer in question is actually a signed integer, arithmetic operations can cause an overwrite of the leftmost bit and make the result a negative number, possibly leading to an exploitable behavior.

What is IoT Exploitation?

Not all programming errors are created equally. Some allow attackers to gain something or to get an ability they didn’t already have. They may be able to deny other users’ access to the program by crashing it, or access information they shouldn’t be able to. In some cases, they may be able to cause the program to execute any command they tell it. These errors are vulnerabilities. Other errors, while they may have the same causes, won’t give attackers any access they didn’t already have. So, the first task for a vulnerability researcher is to determine if the programming error is merely a bug or if it can lead to exploitation. If a bug can lead to exploitation, either by itself or when used in concert with other bugs, it is indeed vulnerability.

Buffer overflows and vulnerabilities caused by the application not checking space availability before copying un-trusted data into the pre-allocated space in the system memory, end up overwriting contents of memory outside the buffer. As a result, next time the program looks at that memory space, it sees data from the overflow instead of the original data. If the program tries to use values from that area, it will most likely not see what it expects, the consequences of which can range from a crash of the program to other more potentially dangerous actions like DoS or worse, execution of a new malicious code planted by someone. A stack-based buffer overflow can allow attackers to execute code on the victim’s computer, as it overwrites memory addresses that will be used later, while a “stack overflow” typically results in a DoS, as it tries to write to memory that isn’t available.