WordPress 5.1 CSRF to RCE 漏洞详解

直接弹框

但是超级管理员在提交评论表单时，wordpress需要校验其Nonce值

想理解这个漏洞，首先要了解下wordpress的Nonce ( number used once )防御机制

Wordpress的Nonce ( number used once ) 机制，是用来防止CSRF而引进的。WordPress会为一些请求提供一个随机数进行校验，以防止未授权的请求的发生。

来看下wordpress的Nonce机制是如何使用的:

1、使用wp_create_nonce生成 nonce值：

可见，其实nonce值与$i、$action、$uid、$token有关

这里的$i 是nonce创建的时间相关变量，由wp_nonce_tick()生成，其余的$action、$uid、$token很好理解。

由这里我们可以看出，nonce的生成，与其操作也是有关系的

2、将生成的 nonce传递给需要提交时验证的前端模板

3、需要验证的表单被提交后，验证其中nonce，例如下图中，本次漏洞点

Nonce讲解完毕，言归正传，分析本次漏洞

漏洞分析

理论上，如果没法通过Nonce验证，后续的操作会直接被终止，而且在csrf攻击中，攻击者是没有办法伪造管理员实时的Nonce值。

但从本次漏洞处来看，如下图

这里虽然没有通过Nonce的验证（wp_verify_nonce）,但是并未终止操作。Wordpress在这里使用了两个过滤方法对后续的数据进行过滤。

至于为什么没有终止，而采用了如下的过滤逻辑，据说是因为WordPress其中有一些特殊的功能例如trackbacks and pingbacks会受到该值的影响，笔者没有进一步考究，感兴趣的同学可以自己分析下。

到目前为止，我们虽然没有合法的nonce值，但我们的payload仍然幸存，

接下来，看看逻辑里的 kses_init_filters()这个方法

超级管理员&非法Nonce情况:

我们用超级管理员身份提交一个评论，但是改包，把&_wp_unfiltered_html_comment改为空，使其通过不了Nonce校验，如下图

果然进入下图断点

紧接着，进入如下断点

使用wp_filter_post_kses对输入的数据进行过滤

普通用户情况：

此时用普通用户进行评论

直接调用wp_filter_kses进行过滤

以上思路以及明朗了

超级管理员&合法nonce ->不做任何过滤

超级管理员&不合法nonce ->wp_filter_post_kses

普通用户 –>wp_filter_kses

先来看看普通用户提交和超级管理员无nonce提交时调用的过滤函数有什么区别

普通用户提交过滤函数：

超级管理员无nonce提交过滤函数：

可以看出只是wp_kses中第二个参数不同，一个是current_filter()，一个是’post’

这里不同的，对应wp_kses中，应该是allowed_html参数值

这里举个普通用户评论的例子，普通用户提交评论，current_filter()方法返回的值是pre_comment_content，也就是说allowed_html参数值为pre_comment_content。可见下图动态调试结果

对应的，超级管理员无nonce提交时，这里的allowed_html参数值为”post”

那么allowed_html值不同，到底会有什么区别呢？

$allowed_html被传入wp_kses_split方法

进一步看wp_kses_split

注意到这里$pass_allowed_html = $allowed_html;

现在$allowed_html传给了$pass_allowed_html

我们要看看这两个不同的$allowed_html最终传递到哪里被用到

跟进_wp_kses_split_callback，$allowed_html传给了wp_kses_split2

跟进wp_kses_split2，$allowed_html被传给了wp_kses_attr

跟进wp_kses_attr，$allowed_html被传给了wp_kses_allowed_html

跟进wp_kses_allowed_html

一路跟踪，到了这里，$allowed_html终于有作用了

回顾一下，

超级管理员无nonce提交时，这里的allowed_html参数值为”post”

普通用户提交评论时， allowed_html参数值为”pre_comment_content”。

首先看超级管理员无nonce提交吗，allowed_html参数值为”post”，进入post分支

可以看到这里有一个wp_kses_allowed_html方法，跟进去看看

相当于一个白名单机制，再看看白名单上都有什么，看看$allowedposttags

这里’a’标签运行’rel’属性

再看看普通用户提交评论时， allowed_html参数值为”pre_comment_content”情况。

这里白名单是$allowedtags

只允许’href’与’title’

看到这里，明白wp_filter_post_kses 、wp_filter_ kses两个过滤函数有什么区别了吗？

可以用’rel’属性与不可以用’rel’,有什么区别呢？如何造成这次的csrf呢？看下图

wp-includesformatting.php

可以看到属性值在没有被转义处理的情况下就再次拼接在一起，

在a标签最终被拼接时，title的属性会被封装到双引号中，这样我们就可以构造数据使其闭合，从而执行js

Payload：

被双引号包裹后

 

单鼠标放置时，js执行

 

但是这个wp_rel_nofollow_callback哪里来的呢？

 

看一下wordpress对comment_content都采用了哪些默认的过滤器

 

wp-includesdefault-filters.php

 

 

上图三个分别是：

wp_rel_nofollow

convert_invalid_entities

balanceTags

 

看下wp_rel_nofollow

 

wp_rel_nofollow_callback是在这里被加载并使用的

 

结语

最后，整理下流程

 

此次漏洞的流程是：

(超级管理员&不合法nonce) ->(wp_filter_post_kses)->(’rel’属性在白名单中逃逸)->(wordpress加载默认评论内容过滤器wp_rel_nofollow)->(加载wp_rel_nofollow_callback) ->(未过滤并用双引号包裹title值)->(js执行)->(RCE