3.2.2.7 Lab – Compromise IoT Device Firmware (Instructor Version)
Objectives
- Part 1: Performing Threat Modeling Activities to Evaluate IoT Device Firmware
- Part 2: Reflection and Discussion of Threats to IoT Device Firmware
Background / Scenario
IoT devices are susceptible to attacks like many other Internet connected devices running an operating system. In the past, hackers have taken over smart home devices including security cameras, refrigerators, ovens, air conditioners, and even vehicles while they were driving. IoT devices with cameras can potentially be used as spying devices within one’s home. Many popular IoT devices run Linux as their OS.
Vulnerabilities with device firmware include, but are not limited to: key handling vulnerabilities, hard coded passwords, default username/passwords, clear text password transmission through WiFi, buffer overflow attacks, distributed denial of service attacks, and firmware modification attacks.
This lab will require students to download a device firmware binary file and decompress/decode it to its file system and kernel components. Students will be required to analyze the firmware and investigate how vulnerabilities can be exploited.
In this particular lab, we will be exploring an IoT device’s firmware file by using a wide variety of tools/commands on a Kali Linux virtual image.
Required Resources
- Laptop or PC running Oracle Virtual Box with a virtual image of Kali Linux loaded
- Internet connection
Part 1: Performing Threat Modeling Activities to Evaluate IoT Device Firmware
Step 1: Set up the environment and open a terminal window.
a. Start the IoTSec Kali VM and log in using username root and password toor.
Note: If the Kali Linux machine has not been installed, please refer to a previous lab in this course.
b. Open up a terminal window.
Step 2: Crack root password using john.
a. Issue the strings command on the rootfs.ext2 file system and search for “root” to see if there are any password entries. This file is essentially an image file that could be written directly to a drive and booted up using the appropriate hardware. We will look for “root:$” which is how a typical entry would appear in the shadow file, and then save it to a temporary file in the /tmp directory. However, when we filter for “root:$” using the ‘grep’ command, we have to delimit the “$” with two backslashes (\\) because the $ has a special meaning in the command.
Note: The Linux prompts in the examples of this lab have been shortened to just #, indicating that you have root access.
# pwd # cd /root/lab_support_files/emulated/mips32 # strings rootfs.ext2 | grep root:\\$ > /tmp/passwd # more /tmp/passwd
b. Run john on the file /tmp/passwd to crack the password.
# john /tmp/passwd Created directory: /root/.john Warning: detected hash type "md5crypt", but the string is also recognized as "aixsmd5" Use the "--format=aix-smd5" option to force loading these as that type instead <some output omitted> Use the "--show" option to display all of the cracked passwords reliably Session completed
You could also use the show option to display the cracked passwords.
# john --show /tmp/passwd
What is the root password? ________________________________________________________
Step 3: Extract the IoT device firmware binary file into a new directory.
a. Change directories to the IoT device firmware file:
# cd /root/lab_support_files/firmware
b. List the content of the folder and obtain the name of the firmware file:
# ls -l
c. The following command will extract the file system from the firmware and will allow you to navigate and explore anything that can be targeted as a potential vulnerability:
# binwalk -e iotdev_firmware.bin
What is the file system type? _____________________________________________________
Step 4: Examine the output of the binwalk command.
a. What is the significance of this file system type? Do a web search to find more information.
________________________________________________________
squashfs is a compressed file system for Linux where low overhead is needed.
b. Verify what new subdirectory was added:
# ls -l
What was the name of the new directory that was added?
_________________________________________________________
_iotdev_firmware.bin.extracted
c. Change into this new directory:
# cd _iotdev_firmware.bin.extracted
What is the name of the new directory within this subdirectory? What command did you use to determine that?
__________________________________________________________
squashfs-root, ls -l
Step 5: Navigate and explore this extracted file system
a. Verify the directory you are in and list the content of the directory:
# pwd # ls -l
b. Move into the new squashfs-root directory:
# cd squashfs-root
What are some of the subdirectories in this directory? What command did you use?
__________________________________________________________
sbin, ls –
c. The readelf command can be used to determine what architecture a binary file was originally compiled to be run on. Use readelf to determine what architecture the chkntfs binary file (located in sbin) is supposed to be run on. This command will help us determine which qemu binary to run in the next step.
# readelf -h sbin/route
What is the Machine architecture listed?
___________________________________________________________
MIPS architecture (MIPS R30ch 00)
Step 6: Use the QEMU open source machine emulator and virtualizer
QEMU will allow you to emulate binaries for other architectures different from what your Kali Linux image is currently running on. QEMU supports the MIPS architecture.
All of the binaries in the squashfs-root directory that were decompiled/decompressed from the IoT device’s firmware file were compiled for the MIPS architecture. They will not run on this Kali Virtual Image because it is on a different architecture. In order to run these binaries, we will need to use QEMU.
Instructor Note: QEMU should already be installed on the Kali Linux virtual image.
a. The QEMU binary that we will be using needs to be copied to the squash-fs-root directory. Before we copy it, we need to know where it is located:
# which qemu-mips-static
Where is this binary file located? _____________________________________________
/usr/bin/qemu-mips-static
b. Copy this file to the current working directory which should be squash-fs-root:
# cp /usr/bin/qemu-mips-static .
c. Try running bin/busybox and other binaries without QEMU and notice that they will not be successful:
# bin/busybox # bin/ping 127.0.0.1
These commands did not work since the QEMU emulator is required to run binaries originally compiled on different architectures.
d. The following uses the chroot command. The chroot command changes the root directory to the current directory as identified with the . (dot)
Enter the commands below to demonstrate that we can run MIPS binaries on the Kali Linux OS:
# chroot . ./qemu-mips-static bin/busybox date # chroot . ./qemu-mips-static bin/ping –c 3 127.0.0.1
e. Start a new shell within the squashfs-root directory with the following command:
# chroot . ./qemu-mips-static bin/sh
How did the prompt change? _______________________________
It is now displaying the path as ‘/’ followed by the # for the root prompt
f. Verify that new shell is using the current path as the root directory.
# pwd
What is the current path? ______________________________________________________________ /
Look at other programs/binaries in the bin and sbin directories. Try running at least 3 other programs and
document their results. Type ‘exit’ when you have completed exploration to leave the shell.
____________________________________________________________
Answers will vary.
Step 7: Explore and look at other important files on this decompiled/extracted file system
a. Verify you are currently within the squashfs-root directory:
# pwd
b. Use the following commands to explore and look for possible vulnerabilities:
# ls -l usr # ls -l usr/bin # ls -l bin/ # ls -l usr/sbin # ls –l etc/ # cat etc/passwd # cat etc/shadow # cat etc/ssh/ssh_host_rsa_key
c. What other commands did you use to explore and look for possible vulnerabilities?
_____________________________________________________________
Answers will vary. Example: The mount command could allow access to other filesystems and import malicious files or export files, such as /etc/shadow.
Part 2: Reflection and Discussion of Threats to IoT Device Firmware
Part 1 of this lab demonstrates how to decompile/disassemble a binary firmware file and navigate the file system for vulnerabilities. Hackers are able to use widely available tools to modify the firmware with backdoors or Trojan horses and repackage the firmware into a new firmware image.
Reflection
1. What kinds of threats or vulnerabilities are IoT device firmware susceptible to?
___________________________________________________________
IoT devices might be vulnerable to attacks such as Buffer Overflow attacks, DoS attacks, firmware modification, distributed denial of service, and key handling vulnerabilities.
2. Describe one type of IoT device firmware attack and what measures could be used to help prevent this type of attack.
___________________________________________________________
A backdoor could be added to an existing script within the device firmware. If a hacker repackages the firmware into a new downloadable binary file, an unsuspecting user could potentially install this infected firmware on their IoT device. A hash could be used to verify that firmware binary files have not be modified.
3. Describe another type of IoT device firmware attack and what measures could be used to help prevent this type of attack.
____________________________________________________________
IoT devices with default usernames could be logged into remotely. Fix includes: changing the default username/passwords.
In addition: Passwords can be cracked or modified, and certificates can be modified.
4. What is the name of the program that hackers could use to modify firmware with a backdoor and repackage it back into another firmware binary? Does this program exist on the Kali Linux operating system that you are using? Hint: Use Google to find the answer.
____________________________________________________________
firmware-mod-kit
Yes.