CVE-2022-27047: mogu_blog_v5.2 backend Management System has an vulnerability of uploading arbitrary files · Issue #62 · moxi624/mogu_blog_v2

1.Black box pentesting

Using mogu2021:mogu2021 to log in the mogu_blog_v5.2 backend Management System.

Find the Blog Management - Blog Management - Local-file Upload feature .

Click this blue button to select a local image for uploading, and then click the green button to put the image to server side

At this point, use the burp suite to capture the request packet.

and then forward it to the Repeater module.

Try to send a request to upload a normal image and you can see that the image was uploaded successfully.

And the response packet returns the address information of the image.

Splice the address in the response packet with the url to try to access the image we just uploaded .

The whole url :
http://23.224.61.136:8600//blog/admin/png/2022/3/8/1646708813850.png

You can see the successful access to the uploaded image.

Back in the burp suite, try changing the contents of the file in the request package to xss payload，as well as trying to change the file name to an html suffix.

You can see the successful upload and the file path in the response package.

Splice the file path to the url and open a new browser (without admin cookies/session/token) to try to access it.

The whole url :
http://23.224.61.136:8600///blog/admin/html/2022/3/8/1646709195222.html

You can see that the xss payload was successfully executed and that there is an arbitrary file to upload.

Try again to modify the request package and found that arbitrary file uploads were possible while the feature was intended to allow only image format files to be uploaded.

jsp:

php:

cpp:

2.White box pentest

Based on the url of the image upload request
(/mogu-picture/file/pictures), we can tell that the class that handles the image upload function is located in the /mogu-picture subproject

According to the request url (mogu-picture/file/pictures) continue to locate the FileRestApi.java class

mogu_blog/mogu_blog_v2/mogu_picture/src/main/java/com/moxi/mogublog/picture/restapi/FileRestApi.java

With @RequestMapping(“/file”) you can see that all requests for the /file path will be processed by this class

And requests for the /file/pictures path are handled by the uploadPics() method of this class

This method first obtains the system configuration file, and this step does not perform any checks on the suffix name, format, or file content of the uploaded file

This method then calls the batchUploadFile() method of the FileServiceImpl class instance object

Follow up in the batchUploadFile() method of the FileServiceImpl class to see its source code

The first part of the code is to get some files and system base information, none of which is file-checked

Continuing to follow up to the code for file uploads,

You can see that there is no strict verification of the uploaded file extension, file content, or file format

The next code execution reaches the try /catch {} block, which involves the uploadFile() method of the QiniuServiceImpl class

Going deeper into this method leads to the uploadSingleFile() method.

You can see that the file suffix, file format and file content are still not strictly verified.

Back in the batchUploadFile() method of the FileServiceImpl class,

After checking the code after , not only the code for uploading the QiNiu server did not have strict file verification, but also the code for uploading Minio server and the code for uploading to the local server was not strictly verified.

Finally, in the batchUploadFile() method of the FileServiceImpl class, the following code will be executed.

Set the information of the uploaded file to some settings.

Then save and upload feedback to the client response file.

The entire code execution process does not strictly check the suffix name, file format, and file content of the uploaded files.

This allows attackers to use the file upload interface to upload arbitrary files and even insert xss payloads.