DedeCMS文件上传漏洞分析

 

目标导读

0x01、前言
0x02、简介
0x03、DedeCMS V5.7 SP2前台文件上传(CVE-2018-20129)
01、漏洞复现
02、漏洞分析
03、遗留问题
04、漏洞修复
05、漏洞总结
0x04、DedeCMS V5.7 SP2后台文件上传(CVE-2019-8362)
01、漏洞复现
02、漏洞分析
03、漏洞修复
04、漏洞总结
0x05、总结

 

前言

前段时间看到有篇文章是关于DedeCMS后台文件上传(CNVD-2022-33420)，是绕过了对上传文件内容的黑名单过滤，碰巧前段时间学习过关于文件上传的知识，所以有了这篇文章，对DedeCMS的两个文件上传漏洞(CVE-2018-20129、CVE-2019-8362)做一个分析。

 

简介

DedeCMS简介
DedeCMS由上海卓卓网络科技有限公司研发的国产PHP网站内容管理系统；具有高效率标签缓存机制；允许对类同的标签进行缓存，在生成 HTML的时候，有利于提高系统反应速度，降低系统消耗的资源。众多的应用支持；为用户提供了各类网站建设的一体化解决方案，在本版本中，增加了分类、书库、黄页、圈子、问答等模块，补充一些用户的特殊要求 。

 

DedeCMS V5.7 SP2前台文件上传(CVE-2018-20129)

漏洞复现

复现环境：phpstudy、DedeCMS V5.7 SP2、php5.6.9
前提条件：会员模块开启、以管理员权限登录。
会员模块默认情况下是不开启的，需要管理员在后台手动。

登录到前台以后找到内容中心，发表一篇文章，点击下面编辑器中找到上传图片按钮，其实这里原本想实现的功能就是一个简单图片上传的功能。

然后使用BurpSuite抓包，把文件名称从1.png改成1.png.p*hp，然后放包上传。

在响应信息中得到上传文件的保存地址，并且文件的后缀也是PHP。

但是当我们尝试去访问这个文件时会发现有的文件是不解析的，这跟我们上传的文件有关系，这个问题我们后面再解释。

上传的脚本文件可以正常利用。

漏洞分析

从抓取的数据包可以看到提交路径是/dedecmsgbk/include/dialog/select_images_post.php，跟进这个文件看一下进行了怎样的处理。

在select_images_post.php文件中的第36行，对文件名称进行了正则替换，正则会匹配回车符、换行符、制表符、*、 % 、/ 、？、<、>、 |、 “、 ：、并至少匹配1次，把匹配到的内容替换成‘ ’（空），因为我们通过抓包把文件名称改成了1.png.p*hp，所以经过替换会变成1.png.php。

紧接着在第38行对文件名称再次验证，文件名中只需要存在jpg、gif、png中任意一个，如果不存在程序就会提示错误信息，但这里有一个非常大的缺陷，就是程序只是验证文件名称中存在jpg、gif、png三个中的任意一个，并不是在验证文件的后缀。所以我们上传的文件名称1.png.php是可以绕过这个限制的。既然这个限制这么轻松就可以绕过，那我们可不可以直接把文件名称改成1.png.php，而不是1.png.p*hp呢？这个问题最后会进行解答。

程序在第44行对上传文件的MIME类型进行验证，这里进行白名单验证，在$sparr数组中定义了六个允许上传的MIME类型，然后把我们上传文件的MIME去除两端空格并转变成小写得到$imgfile_type，然后判断$imgfile_type是否在数组$sparr，如果不存在程序就会提示错误信息。

漏洞的产生还有一个非常重要的原因，从第57行开始分析，用户的UserID拼接上’-‘再拼接上一段随机字符形成$filename_name，$mdir是年(年份后两位)月日，$mdir跟$filename_name拼接形成$filename=$mdir/$filename_name，然后使用explode函数按照’.’分割文件名$imgfile_name，形成数组$fs内容（’1’，’png’，’php’），然后取出数组中的最后一个元素拼接到了$filename_name参数后面组成文件名，而数组的最后一个元素正好是PHP，所以PHP文件就可以上传了。

并且在最后也可以看到完成的路径。

程序的最后就是把上传文件的信息保存到了数据库中。

遗留问题

上面我们留下了两个疑问：1.直接上传PHP文件可不可行，2.为什么部分脚本文件上传失效。接下来我们将解决这两个问题。

1.直接上传PHP文件可不可以

从返回信息中可以看到，不允许我们上传这种类型的文件，在select_images_post.php文件中包含了config.php文件，config.php文件包含了common.inc.php文件，common.inc.php文件包含了uploadsafe.inc.php文件，在uploadsafe.inc.php文件的第33行对文件的后缀进行了验证，定义了一些禁止上传的文件后缀$cfg_not_allowall，所以直接上传PHP文件是不可以的，上传PHP文件要配合 select_images_post.php文件中替换为空的操作进行利用。

这里的提示信息跟上面我们看到的是一样的。并且在这里面也发现了验证MIME类型。

2.为什么部分脚本文件上传不能利用
通过观察我们上传的PHP脚本文件，可以发现脚本文件被二次渲染了。
比如这个：

但是对于PNG图片把恶意代码插入的IDAT数据块的脚本文件可以避免被二次渲染，并且可以成功利用。但是对于PNG图片把恶意代码插入的IDAT数据块的脚本文件可以避免被二次渲染，并且可以成功利用。

并成功执行命令。

漏洞修复

修复方式一

在给文件名拼接后缀时，对后缀进行二次验证。

比如说在select_images_post.php的第60行添加如下代码。

如果再上传1.png.p*hp文件，程序执行到$fs[count($fs)-1]会取出最后一个数组成员php，而$cfg_imgtype是jpg|gif|png，不包含，所以程序提示报错信息，上传失败。

修复方式二

在官方DedeCMS V5.7.93版本中，uploadsafe.inc.php文件中由原先只要文件名中包含$cfg_not_allowall参数定义的这些文件后缀，改成了使用pathinfo()方法获取文件的后缀，然后判断后缀是否存在黑名单中，按照之前的文件名来说的话，这里获取的后缀是p*hp，依然不在黑名单数组中。

因为更新迭代，此时的富文本编辑器中的数据提交到了select_images_post_wangEditor.php文件中，这里的正则匹配特殊字符替换成空，但是这里的文件后缀也采用pathinfo()方法获取文件后缀，之前文件名1.png.p*hp经过特殊字符替换成空，然后pathinfo()方法获取获取到的文件后缀为php，这里的白名单$cfg_imgtype是jpg|gif|png，显然php并不在其中，所以返回提示信息”您所上传的图片类型不在许可列表”。

官方已修复该漏洞，请注意升级。补丁链接：
https://www.dedecms.com/download

漏洞总结

从上面可以知道上传p*hp后缀的原因是在正则替换之前存在着一个黑名单验证，传入p*hp后缀后可以绕过这个黑名单验证然后被正则把*替换为空，而文件后缀获取时会取出最后一个数组成员php，并没有进行二次验证，所以造成了这次文件上传漏洞的产生。

 

DedeCMS V5.7 SP2后台文件上传(CVE-2019-8362)

漏洞复现

复现环境：phpstudy、DedeCMS V5.7 SP2、php5.6.9

首先准备一个压缩包1.zip，压缩包里面的文件名为1.jpg.php，文件内容为：<?php phpinfo();?>

安装完成之后登录到系统后台，默认账号/密码是admin/admin，点击在左侧当导航栏中的核心按钮，然后选中附件管理中的文件式管理器，进入其中的soft目录中。

然后把之前准备好的压缩包上传上去。

然后访问album_add.php文件发布新图集，这里需要提前创建一个图集主栏目，上传方式选择从ZIP压缩包中解压图片，选择之前上传的1.zip。

上传完成之后，我们点击预览文档。

然后就会跳转到前台页面，点击下面的testZip。

当点击testZip，页面跳转，之前压缩包内的1.jpg.php里面的代码会执行。

我们来看一下这里正常上传图片的效果，当压缩包内是图片的话，这个会显示出图片，至于链接的话就是查看图片的链接。

漏洞分析

使用burpSuite抓包，发现提交到了album_add.php文件，在/dede/album_add.php中找到这个文件，跟进程序看到底是怎么处理的。
album_add.php文件的前半部分都是一些验证赋值操作，或者是验证关于相关栏目的信息，但是因为上传的时候选择的是从压缩包中解压图片，所以$formzip参数值为1，这个后面会用到。

因为$formzip参数值为1，所以会解压压缩包中的图片，其实可以发现在程序的173行调用ExtractAll()方法完成解压操作，传入$zipfile和$tmpzipdir两个参数，$zipfile是压缩包的保存路径，$tmpzipdir是创建出来存在解压文件的路径。

跟进到ExtractAll()方法，查看程序的下一步执行。

在程序第309行会调用get_List()方法获取压缩包中的信息。

这里要提一下ReadCentralFileHeaders()方法，在这个方法中会读取到压缩包中的文件名等信息。

然后回到ExtractAll()方法，接着调用Extract()方法解压单个文件，这个方法中也会调用ReadCentralFileHeaders()方法读取到压缩包中的文件名等信息，然后在361行调用ExtractFile()方法，并把获取压缩包中文件信息($header)、压缩包路径($zip)、创建的目录($to)这三个参数一起传入。

ExtractFile()方法中的大致流程就是首先会创建的目录下面创建一个gz文件，文件名称是$header[‘filename’].gz拼接的，也就是1.jpg.php.gz，接下来在创建一个$header[‘filename’]文件，此时这个文件名就是1.jpg.php，再把读取到的内容写入进去，这个过程中并没有对内容进行校验。

从调试中可以看到，写入的内容就是上传压缩包中文件的内容<?php phpinfo();?>，最后删除gz文件。完成解压。

完成解压之后程序回到album_add.php文件中，在程序第176行，程序调用了GetMatchFiles()方法，并且传入了三个参数，分别是$tmpzipdir、jpg|png|gif、$imgs。

在GetMatchFiles()方法中可以看到，其实就是读取$tmpzipdir目录中的文件，在程序第163行会有正则匹配文件名中是否包含jpg|png|gif，如果包含的话才会加到数组中，这也就是为什么要在文件名中加上jpg的原因，此时程序执行结束回到album_add.php文件， 继续跟进分析。

回到album_add.php文件。此时的$imgs就是读取到的文件名，此时会进行循环操作，循环中首先会组成一个保存路径$savepath，是由$cfg_image_dir拼接上年月组成，$iurl是由$savepath进行一系列的拼接组成，最关键的点是在程序的第184行，取出$imgold参数的最后四个字符，$imgold就是GetMatchFiles()方法读取到的文件路径，其中最后四个字符就是.php，然后拼接在$iurl上面，$cfg_basedir跟$iurl组成文件名，所以此时的文件后缀就是php，然后利用copy()方法，把$imgold中的内容复制到$iurl中，并且删除之前创建的ziptmp中的目录，最后就是进行一些图片的尺寸以及数据库的操作。

程序继续向下进行，在第209行，会把$iurl参数参入到数据库中，就是把发表的信息都存入到数据库中。

最后如果选择删除压缩包，会把压缩包删除，再通过RmDirFiles()方法删除对应创建的目录$tmpzipdir。

当前台调用的时候可以发现跳转的链接，点击超链接进入。

当要点击标题链接时，在左下角也会发现同样的URL，这个URL就是我们保存的PHP文件的路径。

并且从代码中我们也可以看见，这个链接是写死在HTML文件中的。

所以点击链接就会跳转到PHP文件，执行文件中的代码。

漏洞修复

我们把/dede/file_class.php中第161行代码修改成：

else if (in_array(pathinfo($filename, PATHINFO_EXTENSION), explode("|", $fileexp),true) === TRUE)

这里之前是验证文件名，现在改成验证文件后缀，后续就会验证文件后缀是否存在$fileexp中了。

最新版中使用pathinfo()方法获取到文件的后缀，然后判断是否后缀是否在白名单数组中。然后再重复一次之前的上传流程，此时在这个断点处可以看到，php后缀并不满足判断条件，所以此时的文件名并不就加入到$filearr中，$filearr数组就是当时作为参数传入的$imgs数组，因为$imgs为空数组，所以接下来的循环复制操作也就不会执行了。

操作完成之后，再看之前的前台操作页面，已经没有之前的跳转链接了。

官方已修复该漏洞，请注意升级。补丁链接：
https://www.dedecms.com/download

漏洞总结

在分析过程中可以看到，对于压缩包中文件的后缀并没有进行验证，文件后缀的获取也没有进行二次验证，而是直接获取文件名称的最后四个字符拼接上去，最终造成了文件上传漏洞的产生。

 

总结

从上面两个实例中可以看到，第一个漏洞有用到黑名单验证，但并不是验证的文件后缀，两个漏洞都用白名单对文件名进行了验证，保存文件时对于文件后缀的获取并没有进行二次验证，而是直接获取拼接，所以才会造成文件上传漏洞的产生，造成系统的Getshell。对于上传文件其实也要对内容进行验证的，并且这两个地方本来都是上传图片的功能，验证上传文件的头部信息，对上传文件进行二次渲染，在保存文件时对后缀进行二次验证，这样就可以极大程度的避免文件上传漏洞的产生。