Wordpress SQL注入漏洞(CVE-2022-21661)分析

产品介绍

WordPress是一个以PHP和MySQL为平台的自由开源的博客软件和内容管理系统。WordPress具有插件架构和模板系统。截至2018年4月,排名前1000万的网站中超过30.6%使用WordPress。WordPress是最受欢迎的网站内容管理系统。全球有大约40%的网站(7亿5000个)都是使用WordPress架设网站的。WordPress是目前因特网上最流行的博客系统。WordPress在最著名的网络发布阶段中脱颖而出。如今,它被使用在超过7000万个站点上。

wordpress的结构

1
2
3
4
5
6
7
8
9
10
├─wp-admin
├─wp-content
│ ├─languages
│ ├─plugins
│ ├─themes
├─wp-includes
├─index.php
├─wp-login.php
├─wp-config.php
├─...
  • wp-admin 为后台管理文件夹
  • wp-content 中包含主题配置文件、插件、上传的文件、升级临时文件,该目录为易受攻击的地方
  • wp-includes 则是一些核心代码,包括前台代码也在这里
  • wp-config.php 这个文件告诉WordPress如何去连接数据库
  • wp-login.php 登陆文件

漏洞简介

通过该文章https://www.zerodayinitiative.com/blog/2022/1/18/cve-2021-21661-exposing-database-info-via-wordpress-sql-injection ,我大概对该漏洞情况进行了一些了解。

该版本的wordpress于WP_Query处存在SQL注入漏洞。WP_Query是wordpress定义的一个类,允许开发者编写自定义查询和使用不同的参数展示文章,并可以直接查询wordpress数据库,在核心框架和插件以及主题中广泛使用。需要注意的是,一般情况下普通的用户输入无法触发该漏洞,该漏洞存在于部分调用了该WP_Query类的wordpress插件中。通过控制该类的输入参数,可以达到SQL注入的目的。

补丁分析

我们在github搜索历史发行版本,在tag中找到5.8.2和5.8.3版本进行commit的比对。

我们可以发现,原来对于terms数组的处理仅仅是将其去重,尔后这些数据会被拼接至SQL查询语句中。该clean_query方法的实际作用是在进行SQL查询之前对输入数据进行一个合法性校验。但在<5.8.3的版本时这个函数并不能很好的做到合法性校验。如果将taxonomy参数置空、同时field参数值等于字符串’term_taxonomy_id’,则使得该clean_query方法无法对terms的合法性进行校验。

通过观察补丁,我们发现,已经无法通过设置field参数值绕过对terms合法性的校验,因为在此处会检查field的值是否满足等于’name’或者’slug’,如果故意设置成这样则无法绕过clean_query方法前面对field的检查。否则,将会对terms用wp_parse_id_list方法进行过滤。这个后面分析

漏洞调试环境搭建

在wordpress官网下载5.8.2的wordpress环境。

电脑已经有现成的wampserver+vscode的调试环境,首先在MYSQL新建wordpress数据库,将wordpress初始化好,链接好数据库。打开wp-config.php,将debug字段设置为true,即可开始单步调试wordpress。

漏洞代码分析

搭建好环境后,首先是尝试利用exp进行调试,查看该clean_query方法的利用链。我首先是修改admin-ajax.php的内容手动加入对于WP_Query类的实例化并控制传入的参数进行调试。

后续还需要整理出该函数的利用链。

武器化利用

思路

由于该漏洞主要存在于插件中,普通的wordpress站点一般不存在可直接调用WP_Query类的地方,我的想法是检查待检测的项目源码是否存在new WP_Query的调用语句,同时wordpress版本<5.8.2。

参考资料

https://zh.wikipedia.org/wiki/WordPress

https://juejin.cn/post/6844903506520850446

https://developer.wordpress.org/

https://xz.aliyun.com/t/10841