By Ryat
Http://www.wolvez.org
2008-2-22
Reference:
The local file inclusion vulnerability is a common vulnerability in PHP, as shown in the following code:
Include (inc/. $ _ GET [a]./global. php );
This is a typical File Inclusion Vulnerability, but to include any file, you need to introduce the/global after the NULL character truncation. php, but when gpc is on, null will be escaped, this often becomes the constraint of local File Inclusion Vulnerability exploitation (in some specific situations, you can also use other methods to truncate the code behind, see: html "> http://www.wolvez.org/forum/thread-55-1-1.html)
In fact, there are two types of files: include () and require (). First, let's take a look at the descriptions of the differences between the two methods in the manual:
These two structures are identical except for how to handle failures. Include () generates a warning and require () causes a fatal error. In other words, if you want to stop processing the page when a file is lost, use require (). Include () is not the case, the script will continue to run
The difference between the two methods is clearly stated in the Manual, while include () this handling method of inclusion failure sometimes provides us with some other ideas on using the local file inclusion vulnerability. Let's look at the following code snippet:
...
If (! Empty ($ _ COOKIE ["userlanguage"]) & file_exists ("lang /". basename ($ _ COOKIE ["userlanguage"]). "/global. php ") $ language = $ _ COOKIE [" userlanguage "];
...
Include_once ("lang/$ language/index. php ");
...
$ Template = preg_replace ("/{langs + (. + ?)} /Ies "," languagevar (\ 1) ", $ template );
...
Fwrite ($ fp, $ template );
...
Function compute agevar ($ var ){
If (isset ($ GLOBALS [lang] [$ var]) {
Return $ GLOBALS [lang] [$ var];
} Else {
Return "! $ Var! ";
}
}
...
Briefly describe the code processing process. The program writes the corresponding $ lang into the template cache based on the language selected by the browser, and directly accesses the template cache when the browser accesses it.
Here, you can use $ _ COOKIE ["userlanguage"] to trigger the local File Inclusion Vulnerability and submit it as follows:
.../../[File] [null char]/eng
Return eng through basename (), while/lang/eng/global. php exists. It bypasses the file_exists () Check and successfully triggers the local file inclusion vulnerability. However, the GPC must be OFF here because NULL characters are introduced to intercept the subsequent strings. It seems that it is very difficult to use it, but we can switch to another idea. If include_once () is correctly included, it will contain a language file. $ lang is defined in the language file, which is the key here, we only need to submit $ _ COOKIE ["userlanguage"] at will, so that include_once () cannot be correctly included, and even if the include () mentioned above fails to be included, the script will still be executed downward, in this case, $ lang is not initialized, so when register_globals is on or extract () is used, we can submit $ lang by ourselves, then, the cached file is written through fwrite :)
In fact, this idea is to convert the include () local file inclusion vulnerability into other vulnerabilities, which is a typical secondary attack :)