WordPress 5.0 RCE 详细分析
2月20号，RIPS团队在官网公开了一篇WordPress 5.0.0 Remote Code Execution，CVE编号CVE-2019-6977，文章中主要提到在author权限账号下，可以通过修改Post Meta变量覆盖、目录穿越写文件、模板包含3个漏洞构成一个RCE漏洞。
但在原文中，作者只大致描述了漏洞原理，其中大量的漏洞细节被省略，甚至部分的利用和后端服务器也有相对应的关系，所以在复现的过程中遇到了各种问题，我们花了大量的时间分析代码，最终终于完全还原了该漏洞，其中部分关键利用点用了和原文有些许差异的利用方式（原文说的太含糊其辞，无法复现）。在下面的分析中，我会尽量按照复现过程中的思考方式及流程，以便读者理解。
感谢在复现、分析过程中一起的小伙伴@Badcode，帮助我修改了很多错误的@Venenof7、@sysorem,给我提供了很多帮助:>
漏洞要求
在反复斟酌漏洞条件之后，我们最终把漏洞要求约束为
WordPress commit
拥有一个author权限的账号
影响包括windows、linux、mac在内的服务端，后端图片处理库为gd/imagick都受到影响，只不过利用难度有所差异。
其中，原文提到只影响release 5.0.0版，但现在官网上可以下载的5.0.0已经修复该漏洞。实际在WordPress 5.1-alpha-44280更新后未更新的4.9.9~5.0.0的WordPress都受到该漏洞影响。
漏洞复现
下面的复现流程包含部分独家利用以及部分与原文不符的利用方式，后面的详情会解释原因。
传图片
改信息
保留该数据包，并添加POST
&meta_input[_wp_attached_file]=2019/02/2-4.jpg#/../../../../themes/twentynineteen/32.jpg
裁剪
同理保留改数据包，并将POST改为下面的操作，其中nonce以及id不变
action=crop-image&_ajax_nonce=8c2f0c9e6b&id=74&cropDetails[x1]=10&cropDetails[y1]=10&cropDetails[width]=10&cropDetails[height]=10&cropDetails[dst_width]=100&cropDetails[dst_height]=100
触发需要的裁剪
图片已经过去了
包含，我们选择上传一个test.txt，然后再次修改信息，如前面
&meta_input[_wp_page_template]=cropped-32.jpg
点击查看附件页面，如果图片被裁剪之后仍保留敏感代码，则命令执行成功。
详细分析
下面我们详细分析一下整个利用过程，以及在各个部分踩的坑。我们可以简单的把漏洞利用链分为4个大部分。
1、通过Post Meta变量覆盖，修改媒体库中图片的_wp_attached_file变量。
这个漏洞是整个利用链的核心点，而WordPress的修复方式也主要是先修复了这个漏洞。WordPress很良心的在所有的release版本中都修复了这个问题（官网下载的5.0.0已经修复了），由于原文中曾提到整个利用链受到4.9.9和5.0.1的另一个安全补丁影响，所以只有5.0.0受影响。在分析还原WordPress的更新commit中，我们寻找到了这个漏洞的修复commit，并获得了受该漏洞影响的最新版本为WordPressWordPress commit
2、通过图片的裁剪功能，将裁剪后的图片写到任意目录下（目录穿越漏洞）
在WordPress的设定中，图片路径可能会收到某个插件的影响而不存在，如果目标图片不在想要的路径下时，WordPress就会把文件路径拼接为形似http://127.0.0.1/wp-content/uploads/2019/02/2.jpg 的url链接，然后从url访问下载原图
如果我们构造?或者#后面跟路径，就能造成获取图片位置和写入图片位置的不一致。。
这部分最大问题在于，前端的裁剪功能并不是存在漏洞的函数，我们只能通过手动构造这个裁剪请求来完成。
action=crop-image&_ajax_nonce=8c2f0c9e6b&id=74&cropDetails[x1]=10&cropDetails[y1]=10&cropDetails[width]=10&cropDetails[height]=10&cropDetails[dst_width]=100&cropDetails[dst_height]=100
ps: 当后端图片库为Imagick时，Imagick的Readimage函数不能读取远程http协议的图片，需要https.
3、通过Post Meta变量覆盖，设置_wp_page_template变量。
这部分在原文中一笔带过，也是整个分析复现过程中最大的问题，现在公开的所有所谓的WordPress RCE分析，都绕开了这部分。其中有两个最重要的点：
如何设置这个变量？
如何触发这个模板引用？
这个部分在下文中会详细解释。
4、如何让图片在被裁剪过之后，保留或者出现包含php敏感代码。
这部分就涉及到了后端图片库的问题，WordPress用到的后端图片处理库有两个，gd和imagick，其中默认优先使用imagick做处理。
2月20号，RIPS团队在官网公开了一篇WordPress 5.0.0 Remote Code Execution，CVE编号CVE-2019-6977，文章中主要提到在author权限账号下，可以通过修改Post Meta变量覆盖、目录穿越写文件、模板包含3个漏洞构成一个RCE漏洞。
但在原文中，作者只大致描述了漏洞原理，其中大量的漏洞细节被省略，甚至部分的利用和后端服务器也有相对应的关系，所以在复现的过程中遇到了各种问题，我们花了大量的时间分析代码，最终终于完全还原了该漏洞，其中部分关键利用点用了和原文有些许差异的利用方式（原文说的太含糊其辞，无法复现）。在下面的分析中，我会尽量按照复现过程中的思考方式及流程，以便读者理解。
感谢在复现、分析过程中一起的小伙伴@Badcode，帮助我修改了很多错误的@Venenof7、@sysorem,给我提供了很多帮助:>
漏洞要求
在反复斟酌漏洞条件之后，我们最终把漏洞要求约束为
WordPress commit
拥有一个author权限的账号
影响包括windows、linux、mac在内的服务端，后端图片处理库为gd/imagick都受到影响，只不过利用难度有所差异。
其中，原文提到只影响release 5.0.0版，但现在官网上可以下载的5.0.0已经修复该漏洞。实际在WordPress 5.1-alpha-44280更新后未更新的4.9.9~5.0.0的WordPress都受到该漏洞影响。 本文来自无奈人生安全网
漏洞复现
下面的复现流程包含部分独家利用以及部分与原文不符的利用方式，后面的详情会解释原因。
传图片
改信息
保留该数据包，并添加POST
&meta_input[_wp_attached_file]=2019/02/2-4.jpg#/../../../../themes/twentynineteen/32.jpg
裁剪
同理保留改数据包，并将POST改为下面的操作，其中nonce以及id不变 内容来自无奈安全网
action=crop-image&_ajax_nonce=8c2f0c9e6b&id=74&cropDetails[x1]=10&cropDetails[y1]=10&cropDetails[width]=10&cropDetails[height]=10&cropDetails[dst_width]=100&cropDetails[dst_height]=100
触发需要的裁剪
图片已经过去了
包含，我们选择上传一个test.txt，然后再次修改信息，如前面
&meta_input[_wp_page_template]=cropped-32.jpg
点击查看附件页面，如果图片被裁剪之后仍保留敏感代码，则命令执行成功。
copyright 无奈人生
详细分析
下面我们详细分析一下整个利用过程，以及在各个部分踩的坑。我们可以简单的把漏洞利用链分为4个大部分。
1、通过Post Meta变量覆盖，修改媒体库中图片的_wp_attached_file变量。
这个漏洞是整个利用链的核心点，而WordPress的修复方式也主要是先修复了这个漏洞。WordPress很良心的在所有的release版本中都修复了这个问题（官网下载的5.0.0已经修复了），由于原文中曾提到整个利用链受到4.9.9和5.0.1的另一个安全补丁影响，所以只有5.0.0受影响。在分析还原WordPress的更新commit中，我们寻找到了这个漏洞的修复commit，并获得了受该漏洞影响的最新版本为WordPressWordPress commit
2、通过图片的裁剪功能，将裁剪后的图片写到任意目录下（目录穿越漏洞）
在WordPress的设定中，图片路径可能会收到某个插件的影响而不存在，如果目标图片不在想要的路径下时，WordPress就会把文件路径拼接为形似http://127.0.0.1/wp-content/uploads/2019/02/2.jpg 的url链接，然后从url访问下载原图
如果我们构造?或者#后面跟路径，就能造成获取图片位置和写入图片位置的不一致。。
这部分最大问题在于，前端的裁剪功能并不是存在漏洞的函数，我们只能通过手动构造这个裁剪请求来完成。
内容来自无奈安全网
action=crop-image&_ajax_nonce=8c2f0c9e6b&id=74&cropDetails[x1]=10&cropDetails[y1]=10&cropDetails[width]=10&cropDetails[height]=10&cropDetails[dst_width]=100&cropDetails[dst_height]=100
ps: 当后端图片库为Imagick时，Imagick的Readimage函数不能读取远程http协议的图片，需要https.
3、通过Post Meta变量覆盖，设置_wp_page_template变量。
这部分在原文中一笔带过，也是整个分析复现过程中最大的问题，现在公开的所有所谓的WordPress RCE分析，都绕开了这部分。其中有两个最重要的点：
如何设置这个变量？
如何触发这个模板引用？
这个部分在下文中会详细解释。
4、如何让图片在被裁剪过之后，保留或者出现包含php敏感代码。
这部分就涉及到了后端图片库的问题，WordPress用到的后端图片处理库有两个，gd和imagick，其中默认优先使用imagick做处理。
www.wnhack.com