Code audit Case 1-penetration into a CMS official demo site

Code audit Case 1-penetration into a CMS official demo site

An earlier vulnerability that has been overwhelmed by me does not need to be covered. When the injection is handed over to the dark clouds and the review is too busy for testing, the vulnerability will be returned. I have always wanted to write a detailed record, but I didn't write the result after I had no time. I went up and saw no chicken hair in the past two days. I have completely completed the makeup, and the shell is also lost, and I cannot enter the background ......

Think about it. Fortunately, I have the habit of taking notes and share it with me.

Below are the notes.

Today, we have dug up fanwe O2O's local living system for a while. This system is not open-source, and occasionally gets the source code of a version, so it has a journey of digging holes.

First, an injection is taken and the administrator password is taken down. In fact, the demo site has provided a demo/demo for an administrator account with low permissions.

Log on to the background:

0x01 chicken ribs File Inclusion Vulnerability

There are not many functions, and the demo administrator has no permissions for many sensitive functions (such as SQL operations.

Generally, the background security is poor, and the most common cause is the File Inclusion Vulnerability. I quickly found a chicken rib file in the source code. /Admin/Lib/Action/ApiLoginAction. class. php

Default

public function install(){    $class_name = $_REQUEST['class_name'];    $directory = APP_ROOT_PATH."system/api_login/";    $read_modules = true;        $file = $directory.$class_name."_api.php";    if(file_exists($file))    {        $module = require_once($file);        $rs = M("ApiLogin")->where("class_name = '".$class_name."'")->count();        if($rs > 0)        {            $this->error(l("API_INSTALLED"));        }    }    else    {        $this->error(l("INVALID_OPERATION"));    }

It is called chicken ribs because it needs to be truncated: $ directory. $ class_name. "_ api. php ";

But I think php on the demo site is 5.3.3. I remember that the truncation problem was solved after 5.3.4. Moreover, fanwe does not have addslashes globally and does not affect truncation.

So I tried it ...... The result cannot be truncated:

It may be another reason. It cannot be truncated. This chicken rib vulnerability is useless. Continue to the source code.

0x02 file upload vulnerability caused by decompression

/Admin/Lib/Action/FileAction. class. php, a file management controller. (The smell is also important during auditing. When I see the file name FileAction, I feel that there is a problem here, because it is a file operation)

In fact, it is not as bad as I think. This is the upload controller. The uploading area is strictly filtered and PHP files cannot be uploaded directly.

However, there is a function to upload the compressed package and decompress it:

Default

/*** Upload icon */public function do_upload_icon () {require_once APP_ROOT_PATH. "system/utils/zip. php "; $ archive = new PHPZip (); $ font_dir = APP_ROOT_PATH. "public/iconfont"; $ result = $ archive-> unZip ($ _ FILES ['file'] ['tmp _ name'], $ font_dir ); if (empty ($ result) | $ result =-1) {ajax_return (array ("status" => false, "info" => "An error occurred while updating the icon library, manually decompress the package and upload the file ". $ font_dir);} if ($ dir = opendir ($ font_dir. "/") {while ($ file = Readdir ($ dir) {$ check = is_dir ($ font_dir. "/". $ file); if (! $ Check) {@ unlink ($ font_dir. "/". $ file) ;}}$ result = $ archive-> unZip ($ _ FILES ['file'] ['tmp _ name'], $ font_dir ); // clear the original file foreach ($ result as $ k => $ v) {$ file = APP_ROOT_PATH. "public/iconfont /". $ k; $ file_arr = explode ("/", $ file); foreach ($ file_arr as $ f) {if ($ f = "iconfont.css" | $ f = "iconfont. eot "| $ f =" iconfont. svg "| $ f =" iconfont. ttf "| $ f =" iconfont. woff ") {// echo APP_ROOT_PATH. "public/iconfont /". $ f; @ rename ($ file, APP_ROOT_PATH. "public/iconfont /". $ f) ;}} foreach ($ result as $ k =>$ v) {$ file = APP_ROOT_PATH. "public/iconfont /". $ k; @ unlink ($ file);} foreach ($ result as $ k => $ v) {$ file = APP_ROOT_PATH. "public/iconfont /". $ k; @ rmdir ($ file);} ajax_return (array ("status" => true, "info" => ""));}

I have read an article I wrote last year: https://www.leavesongs.com/PENETRATION/after-phpcms-upload-vul.html students should remember the new, decompression this operation has a lot of ways to pass shell.

The same is true here, although all original files are deleted after decompression. However, after extracting the zip file, it determines whether it is successful. If it is unsuccessful, it exits directly:

Default

If (empty ($ result) | $ result =-1) {ajax_return (array ("status" => false, "info" => "An error occurred while updating the icon library, manually decompress the package and upload the file ". $ font_dir ));}

Then I can construct a compressed package that can be decompressed in half, decompress some PHP files, and then make an error. In this way, the code "delete" cannot be executed.

Another method is to change the file name to "../xxxx. php" during decompression so that the php file can be decompressed to the upper-level directory and the fate of deletion can be avoided.

The second method is simpler.

So I constructed a compressed package and first wrote a webshell named aaaaaaaaaaaaaaaaaaaa. php. Edit with editplus after compression:

Replace the first four "a" with "/../" to ensure the length of the entire file remains unchanged.

Create a local upload page:

Default
 

Select and upload it. Result access 403:

I tried to change the file name again, or 403. I tried the. php file that does not exist, or 403. This is basically the rule: All. php files in the public directory are 403.

The txt file can be uploaded, indicating that the public directory has the write permission:

In addition, I tried to upload the file to other directories, such as the root directory and admin directory. In result 404, I should not have the write permission.

So now this hole is quite tragic: only the public directory has the write permission, but php cannot be executed under the public directory.

0x03 combination of vulnerabilities miracle

This was a sudden thought: isn't the chicken rib file that was dug just in use?

In the previous File Inclusion Vulnerability, the chicken ribs only contain PHP files. In general, if we can write PHP files, it will actually be getshell.

But here is different. I decompress xxxx_api.php. Although it cannot be executed in the public directory, it can be executed by using the file inclusion method.

Change the file name to aaaaaaaaaaaa_api.php.

The file is included directly after the upload. Successful:

Kitchen Knife connection:

0x04 Method 2: apache resolution vulnerability counterattack

Apache is rarely used at ordinary times. I always think that apache's parsing vulnerability is only available in a very old version. But this time I met him.

After using the previous getshell vulnerability, you can come back and think about other methods.

In this case, I should think differently. If I am an O & M engineer, how do I disable the PHP file in a directory?

Probably a regular: ^/public/. * \. php $. As long as the HTTP request matches this regular, 403 is returned.

I once wrote an article: Workshop.

The method bypassed in this article is actually the regular expression:

In this way, it is not reliable to disable execution by using the suffix. In this article, I bypassed this regular expression through pathinfo (xxx. php/xxx.

Here I also tried to use pathinfo. Unfortunately, 403 is returned. For this regular expression: "^/public/. * \. php $", is there really no way?

The idea is: whether there are other suffixes that can be parsed. If there are other suffixes, you can bypass this regular expression.

I tried phtml and php3/4/5, but none of them can be parsed. At this time, I think of the apache Parsing Vulnerability: When apache does not recognize the last suffix, it will look forward until it finds a recognizable suffix.

Change the name to xxx. php. phi:

The upload result can be parsed:

A resolution vulnerability attack.

0x05 reflection after obtaining shell

Restrict the execution of this problem and look at the configuration file. As I thought, it restricts the Suffixes in the public directory and does not allow execution:

Default

<Directory "/fanwe/www/o2odemo/public">    <FilesMatch ".(php|asp|jsp)$">     Deny from all    </FilesMatch></Directory><code>

You can view the permissions of the entire web directory. The web directory owner is root, only public is 777, and all other files are 755 and 644. It seems that my intuition is getting more and more accurate now, haha ~ (End)