Example analysis of webshell uploaded traceability events

Inspection and Killing

First of all, I understand that what I have to do is not to find where the upload location appears. I should log on to the server to perform webshel ​​inspection and inspection, and check to see if Has it been invaded by others, is there a backdoor, etc. Although the IP address reported is our company's IP address, if a few webshells are missed and uploaded successfully by others but not detected, what can we do if the server is invaded? So I went up to inspect the server, uploaded this webshell killing tool for killing, used netstat -anpt and iptables -L to determine whether there was a backdoor established, checked whether there was a mining program occupying the CPU, etc., I will not go into details here. . Fortunately, the server was not compromised, and I started to think about what happened to this upload point.

File Upload Vulnerability Review

First of all, I asked the developer who contacted me about the address of this server that is open to the public. After asking for the address, I opened it and found that what looked familiar was the one I tested recently. Of? At this time, I felt a little confused, and I confronted the developer about the rectification information. After the last test, I found that the upload place used a whitelist restriction, which only allowed the upload of jpeg, png and other image formats. At that time, I also discovered that although the upload was restricted by a whitelist, a random number was added to the uploaded file name, and the time rules were matched, I still found the upload path and file name in the return package. This and others It was suggested that rectification be carried out, otherwise this would cause the file to contain vulnerabilities. He reported to me that the rectification had indeed been carried out and the path was no longer returned.

File suffix encoding bypass

After discussing and reviewing the problems of the last rectification, I clarified my thinking. Then I logged into the website to check the reason. Because the website only has one place to upload pictures, I tried to capture the packet. After using the repeater to replay the package, I found that the returned package did not return the file upload path. Then I tried various detours. But the result is no good. In the end, I couldn't get any results after thinking hard, and then I asked the cloud platform what was the reason for the alarm provided to them. After reading the feedback results from the cloud platform, I found that there is an image code. This is not a big problem. The uploaded file does not have execution permission, and the file path is not returned. The file name was randomly changed, but why is this jsp uploaded successfully? Okay, this makes me puzzled.

When I looked carefully at the webshel ​​data provided by the cloud platform, I carefully observed that the file name uses base64 encoding. I am very confused about this. Why do I need to encode it when I have already made a random function? Last time No coding was done during testing. I suddenly thought of the key to the problem, and then used the decoder module of burpsuite to base64 encode the file name "1.jsp" into "MS5Kc1A=", and then sent a successful feedback status code of 200, instead of this upload failure feedback status code of 500 error .

So, the problem is that during the rectification process, the R&D personnel used base64 encoding for the file name, which caused the file name to be decoded using base64 during the storage process, and when I uploaded the file, I changed the suffix name to .jsp was also base64 encoded, and .jsp was successfully decoded during the storage process. The R&D team did not impose any whitelist restrictions after decoding. In fact, this kind of coding change is unnecessary. After all, the random number has been used to change the file name. Recoding is a bit superfluous. This is why changing a program bug causes more bugs.

The above is the detailed content of Example analysis of webshell uploaded traceability events. For more information, please follow other related articles on the PHP Chinese website!