This section will explain in detail the content related to file reading, as a section in my column "Web Security Principles and Interpretation of Multiple Defense Methods".
This article discusses mainly local file reading related vulnerabilities. The file reading function is a common function in WEB applications, and the usual processing steps are as follows:
- The client initiates a file read request to the server
- The server generally looks for and reads the file
- Send the file to the specified parser for parsing
- Return the parsed content
Vulnerability principle of file reading
Looking at file reading vulnerabilities from the perspective of source code, it is inevitable to avoid the problems of file inclusion, file parsing, and directory traversal mentioned in the previous articles. Different from the previous chapters, file inclusion, file parsing, and directory traversal are more named and classified according to the cause of a class of vulnerabilities. File reading describes the result of a certain type of vulnerability. The three types of vulnerabilities mentioned in the previous article may all lead to the result of file reading. You may think that the vulnerabilities that lead to file reading results also include injection such as command execution, xxe, SQL injection, etc. However, for vulnerabilities such as command execution, compared to file reading, shell establishment is the most concerned type of vulnerability. That is to say, there are many consequences caused by a vulnerability. When describing the consequences of this file, it generally refers to its most common and serious consequences. So back to the cause of file reading, from the perspective of the results, the file reading vulnerability refers to the most serious consequence caused by those vulnerabilities is file reading. From this perspective, we call this type of vulnerability The vulnerability is a file reading vulnerability, of course, the reason may be directory traversal and the like.
There is no clear and unified standard for the classification of web security. The most common classification is based on the cause of the vulnerability, such as file upload, file parsing, file inclusion, directory traversal, etc. mentioned in the previous articles. However, we often hear such vulnerabilities as file reading, which are classified according to the most serious consequences caused by the vulnerabilities. Since there are many such vulnerabilities in history, it is worth discussing them separately. As mentioned earlier, the most serious consequence of command execution is generally not file reading, so this type of vulnerability is generally not considered as the cause of file reading vulnerabilities. In addition, common file reading vulnerabilities The reason is as follows:
Directory Traversal
In the previous article, here , it can be seen that indeed the most common consequence of directory traversal is the reading of arbitrary files. And many of the file reading vulnerabilities are indeed related to directory traversal. But it is worth noting that the most serious consequence of directory traversal is not necessarily arbitrary file reading. The vulnerability CVE-2021-41773 in the previous article can also lead to command execution.
Configuration errors
In order to expand the flexibility of the framework or functions, generally speaking, the software will provide external configurations for developers and users to use flexibly. As the old saying goes, most operation and maintenance personnel and developers do not have security knowledge and offensive and defensive perspectives, and inadvertent configuration may lead to vulnerabilities such as arbitrary file reading. Generally speaking, framework developers use the correct configuration by default, so problems caused by configuration are generally not recognized by framework or software developers, and it is difficult to be included in CVE.
Soft link
If a soft link file can be created on the WEB server, the request for the soft link is actually a request for the real file it is connected to. Imagine such a scenario, upload a soft link file through a file, and then access the soft link file through the normal WEB file access function, then you can read the content of the file it points to. Of course, the actual use will not be so smooth. Even if the file upload location can pass the check of the black and white list such as the file suffix, it is unknown whether the file storage location can have access rights. This article will use the vulnerability CVE-2016-9086 to detail the arbitrary file reading problem caused by soft links later. The most common use of the
XXE XML external entity vulnerability is to read sensitive information such as /etc/passwd, as shown in Figure 1 below: 1 Regarding the vulnerability of XXE, there will be a separate article to introduce it in detail, see here . The SSRF server request is forged, and the access request is initiated through the server. If the request is made using the file:// protocol, it will generally cause the problem of reading any file. Regarding SSRF-related vulnerabilities, there will be a separate article to introduce them in detail, see here .
Example of file read vulnerability
The vulnerabilities described below can also be labeled or classified in other ways, but the most serious consequence is arbitrary file reading, so they can also be classified as file reading vulnerabilities here.
CVE-2018-1999002
The vulnerability is a file reading vulnerability in the jenkins server. The vulnerable version does not have any filtering restrictions on Accept-Language in HTTP requests. Sensitive files in the server can be read by constructing the content of the Accept-Language field, as shown in Figure 2 NVD :
Figure 2
Jenkins service is a key service for enterprises. All enterprises with code development generally use Jenkins as their code construction and release service. Although the vulnerability only resulted in the reading of some files, its impact is on critical assets, so it needs to be taken seriously. The following is a further analysis of the vulnerability based on the public POC and the patch repaired by jenkins. The POC is shown in Figure 3:
Figure 3
Since Jenkins is a global software, its original purpose is to return files in different languages according to the client's Accept-Language. Generally speaking, the Accept-Language field in HTTP is used to indicate the language received by the client. The common form is Accept-Language: zh-cn, where zh indicates that the language is Chinese, and cn indicates that the country is China. But the POC in the figure can see that the vulnerability sets the value of the Accept-Language field to a file path, causing the file to be read.
Compare the vulnerability patch content , as shown in Figure 4 below:
Figure 4
compares the patch and the POC. In the repaired version, the language and country contents in the Accept-Language field are limited in the form of regular expressions. The value of Language can only be a combination of letters of 2-8 digits, and the value of country can only be a combination of letters of 2 digits or a combination of numbers of 3 digits. In this way, the previous POC cannot be exploited successfully because it has special characters.
It can be seen that the composition of the final file name must include at least base, language, and extension. Therefore, the real use needs to set the values of base and ext, so I won’t go into details, and those who are interested can experiment by themselves. From the perspective of exploitation, this vulnerability can also be a directory traversal vulnerability. From the perspective of the final result, the most serious result is the reading of sensitive files, so it can also be called a file reading vulnerability.
CVE-2016-9086
This vulnerability is a file reading vulnerability in gitlab software, and gitlab has the function of exporting and importing projects. Modifying the exported file to a soft link file of the system file with the same name (such as /etc/passwd) will cause an exception to be thrown directly due to background parsing errors during subsequent imports, and the content of the file will be printed at the same time, resulting in arbitrary file reading. This situation is actually a mistake that programmers often make, that is, to directly print the content of the wrong file, as shown in Figure 5 NVD below:
Figure 5
The POC of the vulnerability is as follows Figure 6, 7, 8:
Figure 6
Figure 7
Figure 8
In Figure 6, you can see that after exporting the file from gitlab export, modify the project.json in it to a soft link file as shown in Figure 7, pointing to /etc/passwd. Upload the packaged file after repair, and get the result in Figure 8, and successfully read the content in /etc/passwd. It can be seen that the consequence of this vulnerability is that the file is read, which seems to be caused by the file upload, but in fact, the background does not consider the soft connection when processing the file. The corresponding patch, here , is shown in Figure 9 below.
Figure 9
Figure 9 shows the exploiting POC for this vulnerability. In the repaired version, it is directly judged whether it is a soft link, and if it is a soft link, delete it. In addition, for project.json parsing error and version checking error, the file will not be printed directly to the front end, but a log record will be formed, as shown in Figure 10: The hint given to us from the vulnerability in
Figure 10 is that the programmer needs to
Avoid directly printing the file content in the case of an abnormal error, otherwise it may lead to file reading vulnerabilities.
Potential hazards of file reading
Vulnerabilities such as file reading are mainly classified according to the consequences caused by the vulnerability. Therefore, it can be said that the consequence of arbitrary file reading is that sensitive information such as configuration on the server is obtained. Therefore, the vulnerability of file reading is always used as a means of information collection, including configuration files, key information, program source code, historical commands, etc. These are all files in the server and can be read.
This article is an original article by the youth in the village of CSDN, and may not be reproduced without permission. The blogger links here .