Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to break through the JFinal blacklist mechanism to achieve arbitrary file upload, many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can gain something according to this article.

JFinal is an excellent domestic web framework, short and powerful, easy to use. Recently, a small partner in the team (LuoKe) reported a very metaphysical arbitrary file upload during the security test. The author followed up the problem code with the attitude that he must know why, and found that the problem system used the JFinal framework when dealing with the file upload function, so he went to audit the code of the framework where the file was uploaded. Found the risk of being bypassed by the blacklist mechanism of JFinal uploaded files. At present, the vulnerability has been reported to the manufacturer and fixed. The following is intended to share with you the principle and discovery process of the vulnerability.

Key function

IsSafeFile (UploadFileuploadFile) / / jfinal blacklist detection function, which is responsible for filtering jsp and jspx files

Com.oreilly.servlet.MultipartRequest (request, uploadPath, maxPostSize, encoding,fileRenamePolicy) / / jfinal handles the file upload request class and handles the files and parameters in the upload request

Loophole discovery

Note: the vulnerability discovery scenario is simulated by the test environment built on my side, which is not the actual scenario in which vulnerabilities were exposed at that time. If there are any omissions, please forgive me.

One afternoon, the LuoKe students of the security test group in the team shared an interesting arbitrary file upload, roughly as follows.

1. Upload a file of txt type, indicating that the upload is successful.

2. Upload the jsp file, indicating that the upload failed.

3. Submit the following data packet to show that the upload failed, but if you give it to the upload directory, you can find that the upload is successful.

Just saw this situation, still quite confused, because but compared with the three packets, you can immediately understand a problem, the third packet is incomplete, its last line is lack of split boundary, in order to verify this idea, I tried the following form of packet

Sure enough, the upload failed, which shows that the bypass of the blacklist must have something to do with the error report of the program. Then the next step is to follow up the system code and confirm our conjecture.

Loophole analysis

When following the code, it is found that the code in the system to handle uploaded files is in the following form:

UploadFile file = getFile ("file", "test")

After taking a look at lib, I found that this function is a function of the JFinal framework to handle uploading files. Does that mean that this way of use is universal in the JFinal framework, so I directly set up a local JFinal framework to look at the code for uploading files.

First of all, take a look at the blacklist handler.

Upload/MultipartRequest.class 100107

IsSafeFile (UploadFile uploadFile) {String fileName = uploadFile.getFileName () .trim () .toLowerCase (); (! fileName.endsWith () & &! fileName.endsWith ()) {;} {uploadFile.getFile () .delete ();;}}

You can find that when dealing with files with suffixes of jsp and jspx types, you will delete "uploadFile.getFile (). Delete ();". When I see this step, I basically feel like a mirror. Does deleting operation in this place represent that the code does not care about anything when dealing with uploaded files, and then delete the problematic files after the upload is completed.

Let's first follow the code for uploading the file.

Servlet/MultipartRequest.class 84-108

((part = parser.readNextPart ())!) {String name = part.getName (); (name = =) {IOException ();} String fileName; (part.isParam ()) {ParamPart paramPart = (ParamPart) part; fileName = paramPart.getStringValue (); existingValues = (Vector) .parameters.get (name); (existingValues = =) {existingValues = Vector () .parameters.put (name, existingValues);} existingValues.addElement (fileName);} (part.isFile ()) {FilePart filePart = (FilePart) part; fileName = filePart.getFileName (); (fileName! =) {filePart.setRenamePolicy (policy); filePart.writeTo (dir) .files.put (name, UploadedFile (dir.toString (), filePart.getFileName (), fileName, filePart.getContentType ());}

You can see that the code will poll each parameter uploaded during upload, and once it is a file, it will upload it directly to the given dir.

Now we have made it clear that any type of file will be uploaded, but the jsp and jspx files will be deleted after reaching the blacklist function, so the next question we need to think about is:

How to make the code execute after uploading the file without executing the blacklist processing code.

To sum up our analysis in the test phase, it is a good practice to find a way to get the program to report an error before executing the blacklist function, so that the code will stop executing the blacklist function. Then let's take a look at the code.

Upload/MultipartRequest.class 76-87

.multipartRequest = com.oreilly.servlet.MultipartRequest (request, uploadPath, maxPostSize, encoding, fileRenamePolicy); Enumeration files = .multipartRequest.getFileNames (); (files.hasMoreElements ()) {String name = (String) files.nextElement (); String filesystemName = .multipartRequest.getFilesystemName (name); (filesystemName! =) {String originalFileName = .multipartRequest.getOriginalFileName (name); String contentType = .multipartRequest.getContentType (name); UploadFile uploadFile = UploadFile (name, uploadPath, filesystemName, originalFileName, contentType) (.isSafeFile (uploadFile)) {.uploadFiles.add (uploadFile);}

From uploading files

This.multipartRequest = new com.oreilly.servlet.MultipartRequest (request,uploadPath, maxPostSize, encoding, fileRenamePolicy)

To delete the blacklist file

This.isSafeFile (uploadFile)

We still have a lot to do between this piece of code.

The idea on my side is to first ensure that the parameters of the uploaded file are normal, and then give a parameter that the API does not exist after the file parameters, so when polling for upload parameters, the first parameter is the file, which will be directly uploaded to the server. When polling for the second parameter, the system will "report that the parameter does not exist" exception, thus stopping the execution of the program and bypassing the blacklist mechanism.

If you see these codes, you can see that in the first version, LuoKe students succeeded in bypassing the blacklist because the second parameter submitted lacked the error caused by splitting boundary. The idea is also feasible.

The following figure shows the poc:

Take a look at the exception thrown at the backend:

1. In fact, I guess there are other possible ways to exploit this vulnerability, such as resource competition that we often mention (write a jsp to write a Trojan file, and crazily access the upload path before uploading colleagues, so it is possible to access the jsp file before deleting the file, and write to the Trojan successfully).

2. In the final analysis, the vulnerability is still a matter of development consciousness. in any case, when dealing with uploading files, you should keep in mind that you should check before uploading.

After reading the above, do you have any further understanding of how to break through the JFinal blacklist mechanism to upload arbitrary files? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.