Binary Ninja is an easy-to-use binary analysis platform that provides rich API interfaces to help security researchers perform automated analysis.
Recently I am doing security research work on various IoT devices, these are mainly routers, NAS, NVR, IP cameras and other products. Normally, I will first try to download the firmware of these products on the Internet, and then use binwalk to unpack and analyze them. Most of them are Linux embedded systems. After obtaining their rootfs, the ELF program inside will be statically processed.
Based on experience, I will focus on the code written by the manufacturer when implementing some specific protocols, such as http, cgi, upnp, netatalk, sslvpn, etc. I have listed some vulnerability prototypes that I will audit during static analysis below. Although the dangerous functions listed below need to be banned in modern software development, due to historical reasons, many IoT devices still have these ancient codes left behind, and there are opportunities to be exploited by attackers.
After sorting out what needs to be done, the work of vulnerability hunting becomes more repetitive. The most time-consuming task is to audit the context when each function is referenced, and then check:
- Whether the current function call is safe (especially check whether there is the possibility of buffer overflow)
- Can the attacker's input reach this path
If the above two conditions are met, it is likely that this is a exploitable vulnerability. However, when an ELF is more complex, the call relationship of these high-risk functions will become abnormally many, and it will become quite laborious to rely on human audit. For example, developers of manufacturers especially like to directly call the system
function in CGI to realize some tasks, such as restarting the machine, checking updates, etc. Most of the parameters of the system
function are beyond the control of the attacker. How we can quickly find the vulnerability that can be controlled by the attacker for command injection?
This obviously involves the category of static analysis. I can conduct a relatively complete analysis of the whole program according to the control flow and data flow, but it requires huge computational power, which is likely to lead to an exponential increase in analysis time. As a vulnerability digger, I am more concerned about how to find exploitable vulnerabilities than absolutely relying on computers to find bugs automatically. I can accept the false alarm generated by automatic analysis. As long as it is more convenient than pressing the X key in IDA for human flesh scanning, it can be regarded as automatic analysis. As for how to reduce its false positive rate, we can make this thing first and then consider this problem.
After investigation, I tried to use angr, IDApython and Ghrida for analysis, but the results were not satisfactory (maybe I was not familiar with the use of these software). Finally, I used binary Ninja to complete a simple automatic analysis tool
1 | from binaryninja import * |
The main logic of the above code is in the check_system function. I just filter out the calls whose parameters are not constants when calling system, and finally output all the results. This greatly reduces the number of system calls I need to check. Similarly, I can also check whether there is a risk of buffer out-of-bounds in the call to sprintf through Binary Ninja's API.
1 | def check_sprintf(bv,symbol = "sprintf"): |
The false positive rate of the above vulnerability analysis will still be relatively high, based on experience, I often add some additional constraints that do not seem to be particularly correct:
-
strcpy strcat
Require the dst parameter to be stack space (more likely to appear stackoverflow) -
system
Require calls to snprintf or sprintf at the same time as system is called (command injection is more likely) -
sscanf
It is required to call sscanf without calling fopen (the developer will use sscanf to read the information in the configuration file)
Through the above constraints, the results of the automatic analysis output can generally be used as a reference for static analysis, but if you want to perform batch firmware analysis, further optimization is required. At present, I am researching how to use Binary Ninja's intermediate language to conduct a relatively complete data flow analysis to further reduce the false positive rate. If there are other updates, I will synchronize them here. Interested students are also welcome to contact me.
References