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

This article will explain in detail how to use the file upload function to construct a RCE loophole for the back-end verification mechanism. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Aiming at the target Web application of authentication function, this paper makes use of its file upload function point, bypasses its client verification mode, takes the back-end file verifier of Web application as the target, constructs the file that uploads executable Payload, and realizes remote code execution (RCE) with XSS Hunter. This kind of vulnerability test posture is common, but how can a bypass move become a high-risk RCE? Let's take a look at the test ideas.

Analysis target

Before participating in the manufacturer's public test project, I will first understand some of the running data of the project, such as the scope of the reward and the duration of the project, if you think this is unnecessary, then blind participation may miss some good projects. My participation in this project is an example. I received a test invitation around May 2019, and the project has been running since 2016, with a total of more than 150 valid vulnerabilities submitted. But I got to know it anyway. After that, I saw from its project update on HackerOne that some new servers were added to the testing scope one after another, and the testing strategy (Policy) specifically described which vulnerabilities the manufacturer was interested in.

Lesson 1: there are always loopholes. Early test targets may have as many vulnerabilities as new test targets.

Understand the goal

It can be seen from the project update strategy on HackerOne that manufacturers are more concerned about the vulnerability of a subdomain site of partner.program.com, a third-party partner Web application site. After visiting the subdomain site, I found that it is a Web application that allows users to register as vendor partners or affiliates. Usually I like to pay attention to the access authorization function of the Web app, and I usually register at least two accounts in the Web app for testing. Because two accounts can be easily tested for ultra vires (IDOR) After registering and logging in, I found one of the interesting things: authentication file upload.

This is the first step in using the Web application. Since the target manufacturer is a trading company, partners and users need to pass authentication by uploading their * * / * * certificates before they can start using Web applications. Finally met the opponent, I like to tamper with the file upload function very much.

Lesson 2: don't ignore some seemingly normal functions. For example, there may be some "fatal" XSS or SQL injection vulnerabilities in the search bar, which 1337 white hats will ignore.

Loophole discovery

In the past, I have found some loopholes in the file upload function, to sum up: we need to carefully analyze its specific upload mechanism, such as what its restrictive attributes are, what the format of the uploaded file is, and so on. Because this is a function point for uploading identity certificates, there are usually two certification file verification mechanisms: either the background has an automatic program to verify the certificate files uploaded by the user, or the back end has an actual staff member to check the user's identity through the user uploading the certificate file. The upload features are as follows:

The figure above shows that the Web application backend only receives files in PNG, JPG, PDF, or BMP format, so I tried to upload some files in non-acceptable format to see how the back-end service reacted. Unfortunately, the back-end service is completely unresponsive. Even from Burp's request history, I didn't find any file restriction response messages or corresponding request records. I was a little confused. However, if a valid JPG file (foobar.jpg) is uploaded, the following upload request will be generated:

What does this mean?

This seems to indicate that there is also a client-side verification measure. If you use Burp to intercept upload requests and change the package, it is easy to bypass this client-side check. For example, we intercept the upload request, and then modify the request as follows, where the name of the uploaded JPG file is changed to foorbar.foo:

After executing such a request, the backend responds to the request successfully, and the server successfully creates the "201 Created" status code of the file, and returns the upper body id that responded to the file:

{"file_id": 16xxxxx1}

This looks very good. But where are the files we uploaded? When we go back to the Web application, there is a problem:

However, after refreshing the file upload page, there is a surprise. The file you just uploaded appears in the file area to be uploaded, as shown below:

Except that it is a file with a suffix of .foo and a file name of a string of hashes: 34beduc... .3dfed.foo . If you upload the same file again, its hash value as the file name will change again to fd33d3f. 38338999dee.foo is like this. That is, the file suffix will not change, but the file name will be hashed to a new value each time, so it may be difficult to find and execute the uploaded file in the back-end server. So how do we exploit it? What would you do?

Vulnerability verification

I think that for the back-end environment of the target Web application, you must construct and upload a file that can be executed. If the back end of the Web application is a staff member to check the uploaded files, then there will be a variety of situations, does he use Linux, Windows, or Mac systems? Different systems may affect the Payload in the uploaded file. If the back end of the Web application is an automatic validator, at least I need it to respond and return some messages before I can determine whether the uploaded file has been executed. So, from this point of view, there is still some trouble.

After that, I thought of XSS Hunter.

If you have not used XSS Hunter, please visit its home page to learn, it is a Blind XSS weapon, can achieve some covert XSS test discovery, feedback response and monitoring management. The way to use it is to first register a XSS Hunter account, register the xss.ht domain name to form your own short domain yoursubdomain.xss.ht, use it to identify and host the Payload, and then construct a XSS Payload such as "> insert the target application to be clicked by the victim. If the Payload is effectively executed, the related requests for its built-in domain name yoursubdomain.xss.ht will be detected by XSS Hunter, and then XSS Hunter will give you a feedback reminder through your XSS Hunter registration reservation email.

In the above backend verification environment I envisioned, HTML files should be the easiest to execute, so I came up with the idea of using Burp to grab packets and construct Payload with XSS Hunter to try to trigger the execution of uploading HTML files. The purpose of this test is to detect whether there are code executable vulnerabilities such as XSS in the file verification mechanism of the Web application back-end. The request I finally constructed is as follows: upload the file as HTML content, first name it as .png image format. After uploading, grab and change the package through Burp, and then modify it to the executable .html format:

After changing the package, the files displayed in the file upload area are as follows:

Then perform the upload, which is a typical client-side verification bypass posture.

The good thing is, two days later, I received a feedback reminder from XSS Hunter that our Payload was successfully triggered and executed three times:

It seems that the Payload file of our HTML has been clicked and executed by the file verifier at the back end of the target Web application. The report returned from XSS Hunter can see some basic system information such as IP and User Agent of the victim.

On how to use the file upload function to build RCE loopholes for back-end verification mechanism to share here, I hope the above content can be of some help to you, you can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.