File Parsing Vulnerability Summary-apache

I am most familiar with is Apache, first to study its file parsing vulnerability. Baidu for a long time, and Google some, finally found that the Apache on file resolution, there seems to be only three kinds of "loopholes." The reason why I quote is because I think these three "vulnerabilities" are not Apache vulnerabilities, but its characteristics, and many programmers do not understand this feature, so write the code of the problem, this is to hackers can take advantage of the machine, resulting in loopholes. But everyone called it the Apache file parsing loophole, and I had to go with the crowd. 1. Multiple suffix name

First of all, a feature: multiple suffix names. This is a little-known feature of how it is. It turns out that, Apache believes that a file can have multiple suffixes, such as: Werner.txt.png.mp3. This file, put in Windows, no doubt, is a MP3 file, Windows only recognize the last "." And then the character "MP3", that the file suffix is ". mp3", which is also the majority of operating systems, application software processing, is a normal habit. In Apache, it may be different, and if necessary, Apache will identify the suffix from the back (right) forward (left). When it's necessary. When Apache does not know a suffix, it is necessary. If a file name is: Werner.mp3.html.qwe.arex,apache in processing, read the last suffix, for ". Arex", a look, this thing ah, do not know, continue to read the next suffix ". Qwe", look, yes, what is this, or do not know, Read on to the next suffix ". html", a look, oh, this is a Hypertext Markup Language file, commonly known as Web files, this time to recognize, also do not continue to read the next suffix. If all the suffixes are finished, no one knows what to do. The file is processed as the default type and, in general, the default type is Text/plain. It is said that searching for "DefaultType" in the Apache configuration file can see a clear definition of the default type, but I do not know why, I did not find it.

Which suffixes Apache knows, which do not know. There is a file called Mime.types, which records the suffix of Apache's acquaintance. Under Ubuntu, the file is located in/etc/mime.types, under Windows, where the file is located in C:/apache/conf/mime.types (like this, note the Apache installation path). The file is a One-to-many mapping table that defines a file type, corresponding to several suffixes. In addition to this file, in the Apache configuration file, you can also add mappings using the Addcharset statement, such as:

  Addcharset us-ascii   . ASCII. Us-ascii
  addcharset iso-2022-cn. ISO2022-CN. CIS

Mime.types is a very long document, probably looked at, the suffix that Apache knows more than me. The excerpt section looks like this:

  Application/java-archive          jar
  application/m3g                         m3g
  APPLICATION/JAVA-VM                   class
  Application/javascript                JS
  application/json                    JSON
  text/html                             html htm shtml
  text/ X-diff                             diff patch
  video/x-flv                             flv
  video/x-la-asf                          lsf                             lsx video/x-mng mng
  video/x-ms-asf                          asf ASX
  VIDEO/X-MS-WM                         WM

What is the problem with this feature? The website often has the function which uploads the file, but certainly does not want the user to upload the program, because this may endanger the website security, therefore will check uploads the file suffix name, if. PHP, then refuses to upload (assuming this is a PHP station). At this point, users simply upload file evildoer.php.qwe, if the programmer does not understand the characteristics of Apache, the program is written to check the suffix only see ". Qwe", but that this is not a program file, allow upload, then the user successfully bypassed the upload when the security, upload the PHP program files. The last suffix of the file ". Qwe" is not known to Apache, so Apache will be the penultimate suffix ". php" as the first, the file as a php file, parsing execution.

Does it always work? Logically, because this is an attribute rather than a vulnerability, it applies to all versions of Apache. This strange feature, perhaps, is the pride of Apache. However, in my test, I found that a similar aaa.php.xxx file is not executed as a PHP program, but rather as a text file, returned to the browser, in the browser can see the PHP source code, rather than execution results. The test environment is UBUNTU14.04+APACHE2.4.7+PHP5.

What's going on. is not the first hundreds of words are nonsense, said is wrong. Let's do an experiment. Prepare a file that is arbitrary, named Test.jpg.aaa, placed in Apache, and then accessed in the browser, as shown in the following figure:

The visible browser handles the file as a picture. Why do browsers think TEST.JPG.AAA is a picture? AAA is not a suffix of picture files. This is because the server's response to the HTTP header in the Content-type field value is Image/jpeg, the browser see Image/jpeg, you know this is a picture file. This means that the server (here, Apache) is the test.jpg.aaa as a picture, also shows that the previous analysis of the Apache multiple suffix processing is not wrong.

So why is aaa.php.xxx not being executed as PHP code? I guess this is, of course, only my guess, it is not to find the relevant information, had to guess. Apache See file Aaa.php.xxx, according to the resolution rules of multiple suffix name, that the file is a PHP program file, the file as a PHP program file processing. How to deal with it. To the PHP interpreter, Apache itself does not know PHP. And the PHP interpreter has a different suffix with Apache resolution rules, may only recognize the last suffix, so that aaa.php.xxx is not a PHP program file, refused to execute. In my test environment, PHP works in modular (module) mode under the leadership of Apache. This mode of PHP to accept the leadership of Apache assigned task--aaa.php.xxx, a look, not PHP program files, can not execute, but also did not complain, but returned the contents of the file itself. PHP can also work in fastcgi mode in Apache, in which case PHP encounters a file similar to aaa.php.xxx, which is not a PHP program, triggers 500 errors.

How does PHP identify files in its own right? I found the php5.conf in the configuration file of the Apache module, which reads as follows:

  <filesmatch ". +\.ph (p[345]?| t|tml) $ "> SetHandler application/x-httpd-php </FilesMatch> <filesmatch". +\.phps$ "> Sethand  Ler Application/x-httpd-php-source # Deny access to raw PHP sources by default # to re-enable it ' s recommended To enable access to the files # specific virtual host or directory Deny,allow Deny from a ll </FilesMatch> # Deny access to files without filename (e.g. '. php ') <filesmatch "^\.ph (p[345]?| T|TML|PS) $ "> order Deny,allow Deny to all </FilesMatch> # Running PHP scripts in user director  IES is disabled by default # to re-enable PHP in user directories comment The following lines # (from <ifmodule ...> to </ifmodule>.)
  Do not set it to in as it # prevents. htaccess files from disabling it. <ifmodule mod_userdir.c> <Directory/home/*/public_html> Php_admin_flag engine off </
Directory>  </IfModule> 

Reading the profile shows that the file name that is executed as a PHP program conforms to the regular expression: ". +\.ph (p[345]?| t|tml) ", where the" "symbol matches the end of the regular, it is known that PHP itself is really only looking at the last suffix. Even if Apache use a file as a PHP program, PHP itself does not recognize it, it is useless.

Further experimentation, replace the "$" of the regular expression just mentioned in the php5.conf file with "\.", that is:

  ". +\.ph (p[345]?| t|tml) \. "

Then restart Apache to make the configuration file effective, and then access to aaa.php.xxx in the browser, this time, Aaa.php.xxx was executed as a PHP program, in the browser, see the program execution results rather than source code. This is also verified from the side, my guess is correct. After the test, you must remember to change back. 2. Rare suffix

The computer world has been free and colorful since the beginning of time. Do you remember Mime.types file. Search for the three letters "PHP" in this file, and the results are as follows:

  werner@yasser:~$ Cat/etc/mime.types | grep php
  #application/x-httpd-php          phtml pht php
  #application/x-httpd-php-source           Phps
  # Application/x-httpd-php3         php3
  #application/x-httpd-php3-preprocessed        php3p
  #application/ X-HTTPD-PHP4         php4
  #application/x-httpd-php5         php5

Remember the regular expression ". +\.ph (p[345]?| t|tml) $ ", the regular expression matches not only PHP, but PhP3, PhP4, PHP5, PHT, and phtml.

Well, it turns out that not only PHP, but even phtml, PHT, PhP3, PHP4 and php5 are the file suffixes of Apache and PHP-approved PHP programs. I had only known ". php", really eye-opening. This is like not only is py a python program file suffix, but also pyc and PYO. The programmer who writes the rules of uploading and filtering is knowledgeable and knowledgeable, and knows it. I think, probably not know. Using these "rare" suffix names may also bypass security checks and do "bad things".

I tested in ubuntu14.04+apache2.4.7, first preparing the file text.php, which is the classic Hello World:

  <?php Echo ' HELLO world ';?>

Then open it in the browser to successfully display "HELLO World". Then modify the file suffix to a variety of suffixes for testing. The test result is that with PHP, phtml, PHT, PhP3, PhP4 and php5 as suffixes, you can successfully see "HELLO World", with the Phps suffix, will report 403 errors, Forbidden, php3p as the suffix, will see the source in the browser. 3. Magical uses. htaccess

Htaccess is another feature of Apache. Generally speaking, the scope of the configuration file is global, but Apache provides a convenient configuration file that can be used for the current directory and its subdirectories ——. htaccess (Distributed configuration file).

For the. htaccess file to take effect, you need two conditions, one written in the Apache configuration file:

  AllowOverride All

If you write this, htaccess will not take effect:

  AllowOverride None

The second is Apache to load the Mod_rewrite module. Loading the module requires that it be written in the Apache configuration file:

  LoadModule rewrite_module/usr/lib/apache2/modules/mod_rewrite.so

In Ubuntu, you might also need to execute a command:

  sudo a2enmod rewrite

You need to restart Apache after configuration.

You need to be aware that Apache may have more than one configuration file, and the configuration file that is loaded will overwrite the configuration in the first loaded configuration file. So setting allowoverride to all in a configuration file is no use if the allowoverride setting in one of the later loaded configuration files is none. In general, load the httpd.conf first, then load the configuration file in conf.d/, and finally load the configuration file in sites-enabled/.

This means that. htaccess is not always effective. And unfortunately, in my test environment. htaccess default is invalid. Well, in order to test, I had to change it to be effective. The following discussions are conducted under the premise that. htaccess is valid.

The. htaccess file can be configured with a number of things, such as whether to open the site's picture cache, customize the error page, customize the default document, set the WWW domain redirection, set the page redirection, set the picture anti-theft chain and access rights control. But we only care about one effect of the. htaccess file--mime type modification. As written in the. htaccess file:

  AddType application/x-httpd-php XXX

The file with the suffix of. XXX in the directory where the. htaccess file resides and its subdirectories is successfully used as a PHP file by Apache. Another way to do this is to:

  <filesmatch "Shell.jpg" >
    sethandler application/x-httpd-php
  </FilesMatch>

This statement will allow Apache to parse the shell.jpg file into PHP files.

The following is a test that has already turned on Apache support for. htaccess files before testing. In the site root directory, prepare the following file tree:

  │
  ├──htaccess_test/
  │   ├──.htaccess
  │   ├──shell.jpg │
  ├──type.xxx │   └──test/
  │       ├──shell.jpg
  │       └──type.xxx
  ├──shell.jpg
  └──type.xxx

Among them, the contents of the file. Htaccess are:

  AddType application/x-httpd-php xxx

  <filesmatch "shell.jpg" >
  sethandler application/x-httpd-php
  </FilesMatch>

The contents of the file Shell.jpg and type.xxx are the same:

  <?php Echo ' HELLO world ';?>

The files are then accessed in the browser, as shown in the following table: Access path Access results/type.xxx <?php echo ' HELLO world ';?>/shell.jpg load failed picture/htaccess_test/type.xxx he Llo world/htaccess_test/shell.jpg Hello world/htaccess_test/test/type.xxx Hello world/htaccess_test/test/shell.jpg HELLO World

The test results are in line with expectations.

But, according to the previous guesses, even if Apache thinks type.xxx is a php file, PHP does not think so, is not able to execute it. How can it be carried out this time, very strange. But anyway, we already know that when. htaccess files are valid, the. htaccess file is a good way to set the resolution of the file suffix.