Hacking Book | Free Online Hacking Learning

Home

take you to read "internet of things penetration test": firmware analysis and vulnerability utilization

Posted by chiappelli at 2020-04-02
all

Introduction: this book introduces the principle and practical technology of Internet of things penetration test. The main contents include IOT threat modeling, firmware analysis and vulnerability utilization, embedded web application vulnerabilities, IOT mobile application vulnerabilities, IOT device attacks, radio intrusion, firmware security and mobile security best practices, hardware protection and IOT advanced vulnerability utilization and security automation.

Click to view chapter one click to view chapter two

Firmware analysis and vulnerability exploitation this chapter will focus on the following topics:

3.1 introduction

So far, we have introduced all the basic principles in the IOT ecosystem, and determined the corresponding risks of various threats through threat modeling, which are very helpful for us to carry out penetration testing. Although it may be easier to identify some vulnerabilities and threats simply by using the currently widely used vulnerability scanning technology, in this chapter, we will focus on the reverse analysis of firmware, hoping to realize the operation of firmware at runtime through the analysis of firmware content. We need to roll up our sleeves to discuss how to disassemble firmware, how to use common firmware tools to analyze firmware content and firmware architecture, and how to modify firmware for attack. Like other software reverse analysis methods, firmware analysis is an art. Readers will learn that there are many tools that can be used to help them find common vulnerabilities, but the security analysis of firmware binary image still needs a lot of manual analysis. Before we start the firmware analysis, it is important to discuss the general method of firmware extraction, and analyze and outline which data is more important. This content has been discussed in the previous lightweight firmware threat modeling walkthrough, but here we will start with the goal of firmware analysis.

3.2 firmware analysis method

Firmware is the core of controlling IOT devices, which is why we want to start from firmware analysis before analyzing other components of IOT devices. According to the industry of IOT devices, the process of extracting firmware image and disassembling its contents can be very simple. Similarly, for vertical segments of some industries, special protection measures are taken, which may make the reverse analysis process more difficult or time-consuming. However, there are some common patterns in firmware analysis. In general, the most concerned content of the tester in the firmware analysis mainly includes:

In the following chapters, we will also focus on these contents when we conduct firmware analysis. This section will provide the reader with an overview of the firmware forward analysis and reverse analysis methods. The basic methods used in IOT firmware analysis are listed below: 1) firmware extraction. 2) Firmware analysis. 3) File system extraction. 4) File system load. 5) File system analysis. 6) Dynamic analysis based on firmware simulation.

3.3 firmware extraction

Before analyzing the content of firmware, we need to obtain the binary file of firmware. This section will introduce various technologies involved in the firmware extraction of the target device.

3.3.1 preparations

We will use several tools to extract firmware. Since most of the required tools have been installed by default in Kali Linux, Kali Linux system will be mainly used here. Here are the tools you need:

3.3.2 test process

At present, there are many ways to extract firmware from IOT devices. We will cover most of these methods in this section. The acquisition methods of firmware image mainly include:

2. Sometimes the manufacturer's website may not support firmware download when the proxy or mirror device updates. At this time, the reader can choose the second method (that is, during the device firmware update process, when the proxy forwards the device update traffic) or the third method (dump the firmware directly from the device). In order to realize proxy forwarding of firmware update traffic during device update, readers must implement man in the middle (mitm) attack or mirror device traffic during update. Alternatively, the reader can forward the traffic of web or mobile application by proxy, and extract the URL address of firmware download from it. As we all know, the manufacturer will verify the user agent field in the firmware download request, so the reader may also need to adjust the user agent field in the packet header. The following are the basic steps for implementing mitm attacks on IOT devices to monitor device traffic. The tools used include Kali Linux, etercap, Wireshark and sslstrip. Kali Linux has installed all the tools needed in this section. At present, there are many methods and tools to attack the target device with mitm, and then to achieve traffic forwarding. Here is one of the ways to capture device traffic. 1) Enable IP forwarding:

2) Configure iptables to redirect the traffic of the destination port 80 to the port 10000 on which sslstrip listens.

3) Start sslstrip:

4) To start the etercap GUI:

5) Figure 3-6 shows the results of the above operations.

3. Dump firmware directly from the device. If you can't get firmware through the manufacturer's website or traffic agent, you can also try to dump firmware directly through UART, SPI or JTAG interface. To dump firmware directly, you need to get the physical device and disassemble the device to find the flash chip. After finding the flash memory chip, the reader can connect the chip directly through UART interface or use soic8 test clip to dump the firmware, in which the flash ROM tool and the hardware development board supporting SPI, such as shikra, are used. Figure 3-13 shows how to use the SOIC test clamp and shikra to connect the device.

3.3.3 test analysis

In this section, we briefly introduced how to obtain firmware through vendor site, deployment of mitm test environment to capture device traffic, direct firmware dump from device, Google search and other methods. Now, let's explain why we need to obtain firmware through these methods. Isn't it OK to download it directly from the manufacturer's website? When downloading firmware from the manufacturer's website, users can usually download the required firmware through the service link, file sharing or community forum provided by the manufacturer. However, sometimes the manufacturer requires the user to provide a password before downloading the firmware, or packages the firmware into a zip file that requires a password to decompress. If this happens, in order to save time, we can directly use other methods to obtain firmware. Next, we briefly introduced how to use Kali Linux, sslstrip, etercap and Wireshark to build a mitm test environment to capture device traffic during device updates.

3.4 firmware analysis

Once we extract the firmware, the next main work is to analyze the firmware. It involves how to go deep into the firmware and find as many security risks as possible, which is the main work of this section.

3.4.1 preparations

In this section, we will learn how to perform firmware analysis after extracting firmware binaries. In this process, there are a variety of firmware analysis methods for us to choose, to help us find the security risks in the firmware. As mentioned earlier, firmware contains many things that penetration testers are interested in, such as API keys, private certificates, hard coded authentication information, and Backdoors.

3.4.2 test process

4) As you can see in the previous screenshot, we extract the squashfs file system image. The reader can ignore the warnings and errors in Figure 3-16, which is just a hint that we are not running the command with root privileges. Once we extract the file system, we can browse each directory in the file system and analyze each file to find the vulnerability. Figure 3-17 is a screenshot of the entire file system directory.

3.4.3 test analysis

Readers can also manually add more features to binwalk, and then recompile the binwalk source code to realize the recognition of other file systems.

3.4.4 extended learning

As can be seen from the screenshot above, the firmware is not encrypted because the entropy of encrypted firmware image will fluctuate greatly.

3.4.5 extended reading

3.5 file system analysis

Now that we know how to reverse the firmware and extract the file system from it, we will focus on the content of the file system and conduct vulnerability analysis in this section. This part of the content can help readers to understand more deeply how to mine and exploit the vulnerability from the firmware image, and then invade the IOT device.

3.5.1 preparations

There are two methods to analyze the content of file system:

3.5.2 test process

2) After the firm Walker code base is cloned, we run the. / firm-walker.sh script with the extracted file system location as the parameter:

Once we have the report generated by firmwalker, we can look at each of the files listed in the report and analyze them further. In some cases, readers also need to reverse analyze the binary files based on arm and MIPS architecture, so as to better understand the file execution process and find out the vulnerabilities.

3.5.3 test analysis

Analyzing and understanding the file system and its contents depends on the attacker's manual analysis skills. This is the key to find out the loopholes. Even if all kinds of automation tools are used, readers will realize that the analysis process will eventually be transformed into manual analysis and vulnerability mining for binary files.

3.5.4 extended learning

In order to analyze the file system of firmware more deeply, readers can also use technologies such as firmware diffing to compare firmware with previous firmware versions, and then find out the differences between them. Through comparison, readers can understand the security fixes and changes made in the new version, and even find the unpublished security vulnerabilities in the previous version. Another work we can do based on the firmware file system is to check the library files and components used by the system, and determine whether these components are the early versions with vulnerabilities.

3.5.5 extended reading

When analyzing the contents of firmware file system, it is better to know more about binary analysis and reverse analysis, and be familiar with Linux binary analysis, debugging and disassembly technology for arm and MIPS platforms.

3.6 dynamic analysis based on firmware simulation

Generally, the analysis of IOT devices is limited in one way or another, one of which is that it is difficult for us to carry out a large number of tests and exploit vulnerabilities without physical devices. But in this section, we will discuss the firmware simulation method. Readers can interact with the simulation device just as they interact with the physical device in the network.

3.6.1 preparations

3.6.2 test process

3.6.3 test analysis

The previous simulation experiments are mainly based on QEMU and NVRAM simulators. NVRAM is a non-volatile random access memory, which firmware can access to obtain device information. However, because there is no physical device, when the firmware needs to access the memory, it will cause the service to run in error or crash, which is where the NVRAM emulator works. Firmware can also be modified using the firmadyne toolset to allow users to access the console interface for debugging. Here's what fat scripts can do: 1) extract the file system from the firmware. 2) Get the firmware schema. 3) Make the required image. 4) Network settings. 5) Mirror simulation. All of the above operations can be done manually, but using scripts like fat can help us complete the operations quickly.

3.6.4 extended learning

3.7 introduction to binary analysis based on arm and MIPS

Now we know how to carry out firmware simulation and carry out basic analysis, but readers will find that in real work often encounter binary files of different architectures, which needs further analysis. Because it is difficult for us to cover all the architectures used by embedded devices in one book, here we focus on two popular architectures - arm and MIPs. However, here we will only introduce the vulnerability exploitation under MIPS architecture and the binary reverse analysis under arm architecture. From the perspective of vulnerability utilization, arm architecture is very similar to MIPS architecture, as long as analyzing one architecture can also help readers understand other architectures.

3.7.1 preparations

Now let's start our binary analysis tour. First, let's start with the basic analysis and see how to find the back door from the D-Link firmware. The back door was first discovered by Pierre Kim. In order to verify the existence of this backdoor, readers are required to have a certain foundation for the binary file reverse analysis based on ARM architecture. Although we won't go deep into registers and architectures (as we'll cover in MIPS Architecture), this section will help you understand the binary analysis process and how to find simpler vulnerabilities. The firmware we will use in this example is the firmware DWR 932b of the D-Link device. After extracting the firmware using binwalk, you can notice that it contains a binary file named appmgr, which is exactly the file we are interested in. During the analysis, we can use all the disassembly tools familiar to readers, such as radare2, IDA, hopper, etc. In this case, we use hopper to reverse analyze the binary appmgr, which is a small endian binary based on ARM architecture.

3.7.2 test process

As we can see from the previous screenshot, the program calls the strncmp function with the string helodbg. As we know, the strncmp function is used for string comparison. In this example, it is used to check the input string of binary file before running telnet. The above operations are marked in the form of highlighted box in Figure 3-35. Therefore, we can be sure that there is a backdoor in the appmgr file. The program looks up the string helodbg. Once it receives the string, it will use the bin / sh shell to start the telnet service. The above content is the analysis of binary files under the arm architecture, and the method adopted is also the basic method to analyze binary files to find sensitive information, exploit vulnerabilities and Backdoors.

3.7.3 extended learning

Now that the reader has known the basic method of analyzing arm architecture binary files, we suggest a deeper understanding of arm assembly language and architecture. The understanding of the assembly instructions and the underlying architecture can help readers better understand the disassembly code, and can carry out binary analysis even without the aid of pseudo code.

3.8 vulnerability exploitation under MIPS framework

Now that we have mastered the basic methods of reverse binaries, it's time to learn more about how to exploit vulnerabilities in the main platform architecture adopted by IOT devices. Because the content of this section is only to help readers understand the basic knowledge of binary file vulnerability exploitation, we only focus on MIPS architecture here, but we strongly recommend that readers use the same method to carry out vulnerability exploitation exercises for arm based architecture.

3.8.1 preparations

In order to exploit the vulnerability under MIPS architecture, here we mainly use QEMU emulator and chroot command, which we have briefly introduced at the beginning of this chapter. Now we will study how to exploit buffer overflow vulnerability in MIPS binaries, and change the execution process of the program to jump to the content we want to execute, rather than the code that the program should have executed. In order to simplify the vulnerability exploitation process, we will not involve such contents as return oriented programming (ROP) here, which can make the exploitation process as simple as possible.

3.8.2 test process

The following tools are needed in this exercise:

5) At this time, copy the QEMU binary files for the small end MIPS (mipsel) architecture to the squashfs root folder:

It is not difficult to find out from the source code that the buffer of variable buf in the stack is vulnerable to buffer overflow attack, and the purpose of the overflow attack is to modify the program execution process to point to the address of dat_shell, so we can use the vulnerability to obtain the shell. 9) Now start debugging the program, run QEMU and chroot commands, and attach the debugger GDB to the process with the parameter - G when running chroot command:

As you can see in figure 3-51, the binary file now executes the Dat? Shell function we want to execute. The above content is how to exploit stack overflow vulnerability in MIPs.

3.8.3 test analysis

The basic idea of buffer overflow vulnerability is to put a string longer than the expected length of the program in the buffer, so that the registers in the stack can be controlled. After controlling the registers in the stack, you can jump to the location of shellcode or libc Library of the system to execute other loads.

3.8.4 extended learning

Although we have successfully exploited the vulnerability of binary files in the experimental environment, the scenarios we usually encounter in the real situation are more complex. In one case, the function we want to use does not exist in the real binary file. At this time, the attacker needs to jump to the system function to execute bin / sh, or create the ROP chain to execute his own shellcode.

3.9 using firmware mod Kit (fmk) to add backdoor to firmware

In the process of vulnerability exploitation, one of the methods that often needs to be used is to tamper with firmware. That is, extract the file system from the firmware, modify its contents, and then repackage it into a new firmware. Then the attacker can brush the newly packaged firmware into the device.

3.9.1 preparations

3.9.2 test process

xt-align:center"

3) As we can see from figure 3-53, the firmware is based on the MIPs small end architecture. This means that we need to develop a back door that conforms to the MIPs small end architecture and compile it. Here is the source code of the back door we will use, which was developed and written by osanda malith:

After the code is written, we can use the Buildroot for the MIPSEL architecture and use the cross compiler built by the Buildroot to compile the code. The process of installing and configuring builderoot is not introduced here too much, because this process is very simple, and has been described in detail in the document of builderoot. 4) After creating a cross compiler for mipsel architecture, we will compile bindshell. C as a binary file that can be implanted into the file system

According to the execution results, we can see that we have modified the firmware and successfully implanted the back door, so we have successfully obtained the shell with root permission in the device at this time. After obtaining the shell with root permission, users can modify other configurations of the device, or use it as a springboard to remotely access other devices implanted with malicious firmware.

3.9.3 test analysis

The function of firmware tampering is powerful, which is a dream target for attackers. This is because if the firmware can be tampered with, the attacker can bypass the protection mechanism, remove the security measures and other operations. By using fmk and other tools introduced in this chapter, attackers can easily embed their own malicious software or backdoor into any IOT device firmware, so that attackers can access IOT devices through backdoor anywhere in the world. It is precisely because firmware tampering has such a powerful power in the attacker's hands, so if the firmware can be signed and verified, it will be of great significance to prevent malicious firmware modification attacks.