OWASP FSTM, stage 1: Information gathering and reconnaissance

Starting an analysis of a device from scratch is difficult, especially if it is carried out using a black box approach. Depending on the nature of the application under study and the existing attack surface, it can seem like a daunting task, but thanks to the OWASP FSTM methodology, the analysis process is greatly simplified.

Understanding what to look for, where and why makes the difference between a good and a bad audit. However, due to the abundance of information available today on the Internet, it’s necessary to narrow down the information to be obtained and to measure the time required. It is just as bad to have too little as too much information on the objective of the analysis if it is not well organized.

In an IoT device security audits, reconnaissance and information search is the most delicate stage and is often one of the most important to improve the investigator’s success rate.

Generally, the information search will help to familiarize with the technology, while allowing the recognition of the different parts of the embedded system subject of the security study.

A vulnerable device can be identified from many points of view: perhaps one of the technologies used is vulnerable (failure of a standard), there may be a configuration flaw that exposes critical data, possibly it uses vulnerable third-party software…. Therefore, the more information we can collect, the better.

OWASP FSTM methodology sources

Some of the most common sources of information are listed below.

• Manufacturer’s website. The amount of information about our device can vary a lot between brands. Almost all manufacturers list technical features, modes of use and usage, applications to interact with the devices and possibly links to other resources. If lucky, the manufacturer will also shares datasheets, firmware, schematics and even pictures of the inside of the device…
• Manufacturer’s websites in different regions of the world. Some manufacturers have different websites for different regions of the world. These websites may be subject to different regulations. Thus, in some countries, the manufacturer will be required to share more information about your device than in other regions.
• Websites of other manufacturers. Some products analyzed are designs made by third parties to which the company that markets it only contributes a brand image. Others are products that have been jointly developed between companies to achieve sales volumes by unifying markets in different regions. Sometimes, company mergers or acquisitions result in the inheritance of technologies that are used under several brand names.

In all these cases, multiple manufacturers may expose information on products that are internally very similar or even the same. Different manufacturers have different policies regarding their documentation, are subject to different laws, or will share different documents for services that have been contracted to different companies.

• Certification registries. There are countless entities and companies responsible for certifying that a device complies with a technical standard. Their reports usually document in detail the procedures and materials used to ensure compliance with the standard. These reports can contain very useful information for a safety assessment.

Among the possibilities are photos of the inside of the device, information about the hardware used, photos of possible prototypes or test hardware and possible documents from other manufacturers or suppliers… Some of these entities can be the FCC and PTCRB in the USA, IC and PTCRB in Canada, CE, GCF and RoHS in Europe and TELEC in Japan among many others.

• Code repositories. Many of the devices employed daily use software subject to open-source licenses. These licenses imposes manufacturers to publish parts of their software openly or to provide mechanisms to access this source code. There are many pages to which users or manufacturers upload this source code. Among others, it is interesting to search Github, Gitlab, BitBucket, Sourceforge…

The manufacturer may have its own repositories or sometimes FTP servers. If the manufacturer has an open-source license note and does not provide the corresponding source code, it is possible to claim to the manufacturer to make it public and there are organizations that can force this right.

• Specific forums. In addition to the manufacturer’s official sources, it is interesting to take note of the information that other users have collected. Searching specific forums is an important task but requires a more exhaustive filtering of information.

From a technical point of view, the critical points to gather information on are the overall firmware composition and the underlying technology.

It is recommended to know the supported CPU architecture, operating system platform, boot loader configuration, hardware schematics, component datasheets or estimated lines of code (LoC). Also, locate source code repositories, third-party components, change logs, compliance logs, design diagrams and data flows, previous penetration test reports and bug tracking reports.

Note: It is important to emphasize that the effort dedicated to the analysis of each of the items listed above will depend largely on the application and the nature of the embedded system being analyzed at any given time.

The following are some of the points of interest to be documented and their impact on subsequent analysis.

Supported CPU architecture

One of the main tasks sought in this step of the analysis is to know which CPU architecture is used.

While it is true that the distinction between a high or low performance CPU does not have a direct impact on the security of the device, it is good to know what features and capabilities it has in addition to knowing its architecture.

This will allow us in the future to simplify reversing and emulation processes as well as giving us an overview of the possible security mechanisms that we may face. Possible peripherals of interest could be cryptographic modules, TPMs, trusted execution zones… These modules could be used for the storage of secrets or for the encryption of part of the platform.

Operating system platform

Once the CPU architecture has been identified, it is important to know the operating system platform which device is running. Theoretically, the choice of platform should be transparent from a security point of view if it is properly maintained and corrected the vulnerabilities that shall appear over time.

Open-source systems tend to have more vulnerabilities, but they are fixed more quickly and periodically. Closed source systems, on the other hand, generally take longer to fix bugs.

Sometimes, platforms such as AWS IoT (Amazon Web Services), GCP IoT (Google Cloud Platform), Azure IoT and Zephyr OS (for example) facilitate the processes of testing, updating vulnerabilities in the base system and even the update (OTA) of the embedded devices themselves…

In other cases, we will find Linux distributions for embedded devices with customized processes for updating and maintenance.

Disk/Bootloader setup

System booters are an entry point to bypass system security layers. On some devices the recovery mode of the disk loader, which is not protected, allows to back up the operating system with keys and certificates for secure access to the platforms where the device can access. There are many alternatives such as:

• Uboot
• Libreboot
• Android bootloader
• CFE

Hardware schematics

Another very relevant source of information for further study is the electronic design schematics of the device. These can be obtained from official sources (e.g., a manufacturer’s repository) or by reverse engineering.

The purpose of this information is to help the auditor to expand the attack surface. To do this, buses must be identified where information that could be read in raw format, unencrypted and, in the best case, manipulated to inject spoofed information. This type of action could give access to options that in any other case should not be available (for example, to a hidden menu or something similar).

Component datasheets

After knowing the schematics of the device, it is important to identify the components present on the electronic board to get a clear design idea of the device. It is not necessary to identify all the components, only those which are more interesting such as the rom memories (SPI Flash and e-MMC) and the encryption chips. This information will be especially relevant in later stages of the OWASP FSTM methodology as it significantly increases the attack surface of the device.

Source lines of code (SLOC)

When the above steps have been performed correctly, it is possible to approximate the amount of memory available for the operating system or firmware. This helps to know the code length of a device. Doing this estimation exercise is important to select which tools and techniques to use later.

An example of this would be the possibility of using reversing or fuzzing techniques. When faced with a binary of very small size, the reversing technique might make sense since it would initially have a relatively small investment of hours compared to the fuzzing technique with which a priori it would not be possible to judge whether it would be effective.

If we are faced with a very large binary, the investment of hours in reversing could be exceptionally high, while setting up a fuzzing setup may require little time and waiting for it to produce results in a limited amount of time could be sensible since, the larger the amount of code, the greater the probability of finding a failure.

Change Logs/Records

Reviewing hardware and software change logs is a very reliable source of information that helps to discover past bugs or vulnerabilities. There are many devices on the market that do not implement OTA (over-the-air updates) policies, so the bugs found persist over time until a new version is released (leaving the device in a continuous vulnerable state).

It’s important to note that hardware bugs (unlike software bugs) can only be fixed with a new version of the product.

Examples of such bugs are the use of obsolete SSH libraries that allow unauthenticated access to the user shell (software design bug) or having debug ports accessible as JTAG (hardware design bug).

Design and dataflow diagrams

Other important information to consider is the design and/or data flow that exists in the device under analysis to understand how the data is organized, sent, and manipulated. Obtaining this type of information can be obtained from the manufacturer’s website, executive presentations…

Note: In case of not being able to retrieve this information from official channels, it will be necessary to perform an approximation of the operation of the device to quickly and efficiently identify the most relevant input vectors to breach the device.

Reports of previous penetration tests

Knowing the history of previous penetration audits helps to rule out paths already explored and to contemplate new intrusion paths. In this sense, it is always advisable to study previous vulnerabilities to rule them out quickly or to study them in depth. It is best to try to be fair over time for each attack vector (at least at this stage of the investigation).

Tracking error tickets

In several version control platforms, bug tickets or enhancements added by analysts or external developers can be located. If the device’s system is equipped with a previous version, the bug ticket can be studied to see what kind of defect it produces and if it is possible to exploit it…

In many cases the code base used for the evaluated firmware already has free automatic security tests. It’s recommended to download the hardware manufacturers’ repositories to study the auto-generated code statically and dynamically. It is usually robust code, but you never know where you will find a loophole.

Conclusions about OWASP FSTM

This entry has presented the first stage of the OWASP FSTM methodology and has highlighted the importance of performing a detailed study of the information available for the target device. It is recommended to use open-source intelligence tools and techniques such as OSINT to perform the initial information gathering tasks.

In conclusion, the Tarlogic Innovation team strongly recommends spending time and effort to document and collect as much information as possible about the device in order to obtain a clear picture of the device and to facilitate the subsequent stages of the analysis.

References:

https://github.com/scriptingxss/owasp-fstm

https://cdn.worldvectorlogo.com/logos/gitlab.svg