A traceability event where a webshell was uploaded

Category: Tag:

In the morning, I was suddenly informed by the customer that the server he deployed on the cloud platform was detected by the webshell, which had been checked and killed, and the cloud platform detected that the IP belongs to my company’s address, thinking it was caused by our company’s testing. How do I upload the webshell, I was also confused at the time, I remember very clearly that this is my project, I personally tested it, there will be no missing upload points, and then I started to investigate hidden dangers.

First of all, I understand that what I have to do is not to find where the uploaded location appears. I should log on to the server to scan and kill the webshel, conduct inspections, and find out whether it has been invaded by others, whether there is a backdoor, etc. Although the ip address of our company is reported, if a few webshells are missed and uploaded successfully by others but not detected, how can the server be hacked? So I went up to inspect the server, uploaded this webshell anti-virus tool for anti-virus, used netstat -anpt and iptables -L to determine whether there is a backdoor to establish, check whether there is a mining program occupying the CPU, etc., not detailed here . Fortunately, the server was not compromised, and then I started thinking about what happened to this upload point.

File upload vulnerability review
First of all, I consulted the R&D personnel I was connecting with for the server’s open address. After asking for the address, I opened it and found that the one I was familiar with was not the one I tested recently? At this point, I felt a little bit confused, and confronted the developer with the rectification information. After the last test, I found that the uploading place used whitelist restrictions, and only allowed to upload jpeg, png and other image formats. At that time, I also found out that although the upload was subject to a whitelist restriction, a random number was added to the uploaded file name, and the time rule was matched, I still found the upload path and file name in the return package. It is proposed to carry out rectification, otherwise this will cause this file to contain loopholes. He and I reported that this has indeed been rectified and did not return to this path.

File suffix encoding bypass
After discussing and reviewing the problems of the last rectification, we clarified our 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 package, after using the repeater replay package, I found that the returned package did not return the file upload path, and then I tried various detours. However, the result is not working. In the end, thinking hard to get no results, and then ask the cloud platform what is the reason for the warning provided to them. Looking at the results of the cloud platform feedback, the image code was found. This problem is not big. The uploaded file has no execution permission, and the file path is not returned. Random changes to the file name are also made, but why this JSP upload is successful Now, it makes me puzzled.

When I found the webshel ​​data provided by the cloud platform carefully, I carefully observed that the file name uses base64 encoding. I was puzzled about this. I did the random function and did the encoding. I didn’t do it in the last test. Coded. I suddenly thought of the key to the problem, and then I 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, and it was not this upload failure feedback 500 status code error. Up.

Therefore, the problem is that during the rectification process, the R&D staff used base64 encoding for the file name, which caused the file name to be decoded by base64 in the storage process, and when I uploaded the file, I did this with the suffix .jsp. Encoded in base64, .jsp was successfully decoded during the storage process, and R&D did not impose a whitelist restriction on decoding. In fact, this kind of coding change is unnecessary. After all, the file name has been changed with random numbers, and coding is a bit superfluous. This is why the program bug changes cause more bugs.


There are no reviews yet.

Be the first to review “A traceability event where a webshell was uploaded”

Your email address will not be published. Required fields are marked *