discuz! x 3.4 arbitrary file deletion vulnerability analysis

Author: lorexxar '@ zhichuangyu 404 laboratory date: September 30, 2017

On September 29, 2017, Discuz! Fixed a security issue to enhance security, which could lead to the vulnerability that the foreground user could cause arbitrary deletion of files.

On September 29, 2017, it was known that Chuangyu 404 laboratory started emergency response. After analysis and confirmation by Chuangyu 404 laboratory, the vulnerability was submitted to wooyunvulnerability platform in June 2014. Seebug vulnerability platform included the vulnerability with vulnerability number of ssvid-93588. The vulnerability causes arbitrary file deletion by configuring property values.

After analysis, it is confirmed that the original utilization mode has been fixed, and the judgment of attribute formtype has been added, but the repair mode is not complete, so it can be bypassed. Other unlink conditions can be entered through simulated file upload to achieve arbitrary file deletion vulnerability.

request

After the modification, the birthplace will change to.. /.. / test.txt

The construction request uploads files to home. PHP? Mod = spacecp & AC = profile & OP = base (just ordinary pictures)

File deleted after request

The core problem is in "upload / source / include / spacecp / spacecp" profile.php

Follow code 70 lines

Enter judgment when submitting profilesubmit, followed by 177 lines

We found that if the type of a certain formtype in the configuration file is file, we can enter the judgment logic. Here, we try to output the configuration

We find that the formtype field is not consistent with the condition, and the logic of the code can no longer go in

Let's look at the changes of this fix. You can see that 228 lines introduce the statement unlink again

Backtracking entry conditions

When the file is uploaded and successfully uploaded, you can enter the unlink statement

Then backtrack the variable $space [$key], and it's not hard to find that this is the user's personal settings.

As long as you find a variable that you can control, here you choose birthpath.

You can bypass the limitation of field content by submitting directly on the settings page.

Successfully deleted any file

After updating the code change and tracking the vulnerability point logic, we gradually found that the vulnerability point was submitted to wooyunplatform by white hat in 2014, vulnerability No. wooyun 2014-065513.

Due to the incomplete code update process of the old version of DZ, there is no way to find the corresponding patch. Back to the 2013 version of DZ3, we found the old vulnerability code

In white hat, we can control the uncontrollable variables by setting personal settings, and put forward one of the ways to use.

The manufacturer only fixed the white hat attack POC, which caused the vulnerability to burst again a few years later, DZ completely deleted this part of the code

During this period, the attitude of manufacturers to solve safety problems is worth rethinking

A kind of

IMCAFS

discuz! x 3.4 arbitrary file deletion vulnerability analysis

The core problem is in "upload / source / include / spacecp / spacecp" profile.php

After updating the code change and tracking the vulnerability point logic, we gradually found that the vulnerability point was submitted to wooyunplatform by white hat in 2014, vulnerability No. wooyun 2014-065513.