I. Summary

The Luci system is an open-source system written in lua language, mainly introducing some auditing techniques for it. Let's talk about the tool usage in the preparation phase first, and then discuss some ideas from code auditing. I hope that the readers who finish reading this article can gain something from it.

II. Preparation Phase

Code auditing is an indispensable process for vulnerability挖掘, unless black-box testing. This code is not limited to the lua language we will talk about below, but also includes php, java, and even python, as well as the pseudo-C code that often gives binary hands a headache in daily CTF. Through code auditing, we can understand the logic of the entire program development and the process of interface calls, etc., and then find the defects of the program. These defects can cause Denial of Service at a light level, and direct Remote Code Execution (RCE) at a serious level.

Tool usage

The saying goes, 'Sharpen the blade before cutting wood; a good auditing tool is crucial for code auditing. Using the tool well can often make us handle things with ease. The tool I recommend here is VS Code, which I believe is not unfamiliar to everyone reading this. Visual Studio Code (abbreviated as VS Code) is a free code editor developed by Microsoft that supports various operating systems such as Windows, Linux, and macOS. Its strength mainly lies in the numerous powerful plugins it offers. Here, I mainly introduce two, namely vscode-lua-format and lua.

2.1.1 vscode-lua-format

We found that some firmware extracted from the file system has lua code in the lua files that are all garbled and ugly, which undoubtedly brings great difficulties to our code audit work. This plugin can beautify the code, making it look clearer and more impressive!

Analysis of Vulnerability Mining in LuCI System

2.1.2 lua

If the code formatting plugin is called the cornerstone, then this plugin can be called the auxiliary. This plugin allows you to view the calling relationships between various functions, making it easier to understand the basic logic of the program.

Extract the file system

Firstly, try to obtain the firmware, which can be downloaded from some official websites or can be purchased to extract flash from the device. After obtaining the firmware, you can directly extract the file system with binwalk, or if you encounter an ubi file system, you can use the ubireader_extract_images tool to extract it.

3. Code Audit

Find the attack surface

There are generally two main ideas: one is to find vulnerabilities from the positive angle, which is to first find the interfaces of various functions of the website, and then according to the interface names, find the corresponding logic code for audit. The advantage of this method is that it covers more comprehensively, but the drawback is also obvious, as the interfaces of a website may be very large, making it麻烦 to audit, and it is also impossible to find hidden interfaces.

There is also another approach from the reverse angle to find vulnerabilities, which is to first find dangerous functions in the code, and then globally search for which interface called it, thereby finding the corresponding code to audit. The only drawback of this method is that it is not comprehensive enough, and sometimes it may miss some interfaces with logical vulnerabilities. However, the biggest advantage is that it targets the problem directly, finding the vulnerable points. Therefore, we mainly introduce this method here.

Understand the logic of interface calls

To find code vulnerabilities in the corresponding interface, it is first necessary to understand the code logic of the interface call, then to audit the corresponding code. After we clarify the logic, we can find some hidden interfaces. These are interfaces that exist in the background with corresponding code, but developers have deleted the interface code on the front-end for some reasons. Such hidden interfaces exist. This is the powerful aspect of code audit, which cannot be matched by black-box testing.

For example, let's take a router from a certain manufacturer.

From the above, we can see that the value of the method parameter in the JSON data of the post package can be add, set, or del, which correspond to the three functions in the code. Next, ipgroup corresponds to the first parameter of the register_keyword_set_data function, the value of table corresponds to the second parameter, and the third parameter is the function to be executed for registration, and the first parameter passed to the function corresponds to the following string of JSON data.

Search for dangerous functions

After we have clarified the interface call logic, we can now reverse search for vulnerable points. First, let's find his dangerous functions. Unlike auditing pseudo C code, he does not need to consider stack vulnerabilities.

3.3.1 Search for Command Execution Functions

This is the most common method we use to find command injection vulnerabilities, which is to find the command execution functions. In Lua, command execution functions include os.execute, io.popen, etc. The execute function is equivalent to the system() function in C language. The function has a default parameter command, which is to parse the command and then call the system through the parsed result. Popen starts a program prog in an additional process and returns the file handle for prog. In simple terms, this function can call a command (program) and return a file descriptor related to the program, which is generally the output result of the called function.

In the luci framework, in addition to these library functions, there are other wrapping functions in the sys.lua file such as call(), fork_cal()l, exec() etc.

3.3.2 Global Search

By using global search, we can find where these dangerous functions are called, and then specifically audit the code

Search for the file upload interface

In openwrt, there is a luci.http.setfilehandler function used for file upload. Let's look at an example of it

The setfilehandler function calls a callback function. If the formvalue function is not called, the setfilehandler function will not be executed, and at least one formvalue function is outside the setfilehandler function. This may be used to find vulnerabilities such as command injection and arbitrary file upload.

Searching for vulnerabilities in binary programs

When auditing the code, in addition to the vulnerabilities in the code itself, we can sometimes find vulnerabilities in the binary programs called by it, such as:

This code calls isp_route.sh, and its parameter isp_route_restore_database is something we can control. Let's take a look at the content of the sh script

This script calls a binary program called isp_route_db, and at this point, we can continue to use ida to analyze this program

At this point, we can audit the program as usual to see if there are binary vulnerabilities such as command injection and stack overflow.

Looking for front-end vulnerabilities

There are many interfaces on the back-end, so they are relatively easy to exploit. However, in most cases, vulnerabilities on the back-end are not very significant. If we want to expand the harm of the vulnerability, naturally, we need to look for vulnerabilities that do not require login authentication. At this point, we need to audit vulnerabilities in the front-end. Unfortunately, the front-end of general routers usually only has one login interface. We can find and audit this interface:

We found that in the process of searching for the login interface, we also found other front-end interfaces

4. Summary

In summary, we take a router from a certain manufacturer as an example to introduce the vulnerability挖掘 techniques of the luci system, and explain from the perspective of code audit how to dig some interface vulnerabilities, and please correct me if there is anything wrong in the explanation.