Wordfence对其中的代码进行了分析，发现了其中的一个漏洞。攻击者利用该漏洞就能够在api.wordpress.org上执行任意代码，并且获得api.wordpress.org的访问权。实际上也就是远程代码执行漏洞了。
来自GitHub的请求抵达api.wordpress.org，那么webhook会通过共享的hashing算法来确认，的确是GitHub发出的请求。整个过程是GitHub发出JSON数据，它会将数据和共享秘值进行混合，哈希后将哈希值与JSON数据一同发给api.wordpress.org。
api.wordpress.org收到请求之后，也将JSON数据和共享秘值进行混合，然后算哈希。最终结果如果和GitHub发来的匹配，也就证明了来源是没问题的，是GitHub发来的请求。
GitHub采用SHA1来生成哈希，并且在header: X-Hub-Signature: sha1={hash}的位置给出签名。webhook提取算法和哈希来确认签名。漏洞也就在于：代码会使用客户端提供的哈希函数，这里的客户端通常情况下当然就是GitHub了。在这个过程中，如果能够绕过webhook认证机制，攻击者将能够向shell_exec直接传送POST参数，从而执行远程代码并顺利入侵api.wordpress.org更新服务器。
当然整个过程需要让webhook认为，攻击者是知道共享秘值的。不过webhook能够让攻击者选择哈希算法，PHP提供了各种算法。找个足够弱的哈希算法，暴力攻破webhook，发出一系列哈希，猜出共享秘值和发送数据的哈希值，直到猜对为止，api.wordpress.org就会响应请求。
整个过程的详情可以参见文末Wordfence的原文链接。
问题根源没有解决?
Wordfence是在今年9月份将该漏洞上报给Automattic(WordPress母公司)的，Automattic与9月7日向代码库推了fix(有关补丁详情，可以点击这里)。不过Wordfence表示api.wordpress.org仍然是部署WordPress核心、插件和主题升级的单点故障根源所在。
Wordfence表示曾经试图与Automattic安全团队就有关自动升级系统的安全问题展开对话，但没有得到任何回应。大约在3年前，就有相关WordPress服务器部署认证机制的探讨，目前都还没有任何进展。
标签：WordPress
相关阅读 >>
wordpress中is_sticky()判断文章是否置顶的参数与用法
在centos系统上从零开始搭建wordpress博客的全流程记录
wordpress全局变量$wpdb初始化并声明为全局变量的方法
更多相关阅读请进入《wordpress》频道 >>
