近期，两个WordPress插件InfiniteWP Client和WP Time Capsule曝出高危的授权绕过漏洞（逻辑漏洞），可让攻击者在不知道密码的情况下访问网站的后端。根据WordPress插件库的统计，大约有30万个网站使用了存在漏洞的InfiniteWP Client插件，2万个网站使用了存在漏洞的WP Time Capsule插件。
开发人员对这些漏洞很快做出了反应，并在报告的第二天就发布了补丁。不管怎样，漏洞修复速度总是越快越好。
防火墙可能无法提供保护
由于身份验证绕过漏洞通常是代码中的逻辑缺陷，实际上并不涉及高度敏感的payload，很难立刻确定问题来自何处。
在这种情况下，很难用一般的防火墙规则来防御漏洞攻击，与这两个插件的合法请求相比，恶意请求不会有太大的不同。
为此，我们特意在WebARX防火墙中添加了一个新模块进行防御，因为两个插件都没有像预期的那样连接到WordPress核心。我们也观察到其他WordPress安全公司遵循了相同的方法。或许在将来我们可以扩展一个新的防御功能来阻止类似的问题。
当然，由于该漏洞的性质，基于云的防火墙可能也无法区分恶意或合法的流量，难以提供有效的防护。
因此，使用第三方防火墙产品的用户也应该及时更新插件，保护网站安全。
InfiniteWP Client < 1.9.4.5
为了能触发存在漏洞的代码，我们必须使用JSON编码payload，然后再使用base64，最后通过POST请求将其发送到目标站点。
攻击者唯一需要知道的信息是网站管理员的用户名。在发送恶意请求后，将自动登录网站。
这个缺陷存在于函数iwp_mmb_set_request中，位于init.php文件。这个函数会检查IWP_MMB_Core类的request_params变量是否为空，只有payload在满足某些条件时才会填充该变量。
在这个漏洞中，前置条件是payload的iwp_action参数必须等于readd_site或add_site，因为它们是少数无需授权验证的操作，这也是漏洞的根本原因所在。
一旦payload满足此条件，将使用请求所提供的username参数作为登录身份，而且不执行任何身份验证，代码如下所示。
POST / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xm l,application/xm l;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
Content-Type: text/plain
Content-Length: 93
_IWP_JSON_PREFIX_eyJpd3BfYWN0aW9uIjoiYWRkX3NpdGUiLCJwYXJhbXMiOnsidXNlcm5hbWUiOiJhZG1pbiJ9fQ==
修复后的代码差异也可以在这里找到。
如上所述，他们所做的唯一更改是add_site和readd_site操作将不再能填充request_params变量，而是直接返回false。
基于WordPress插件库，InfiniteWP客户端插件被30多万个网站使用。InfiniteWP网站则声称有513520个网站正在使用。
WP Time Capsule < 1.21.16
针对WP Time Capsule插件的攻击不需要复杂的payload，只要在原始POST请求的正文中包含特定的字符串即可。
这个问题位于wptc-cron-functions.php文件的第12行，和请求解析有关。parse_request函数会调用decode_server_request_wptc函数，去检查原始POST的payload中是否包含字符串IWP_JSON_PREFIX。
如果包含此字符串，则调用wptc_login_as_admin（它获取所有可用的管理员帐户，并使用列表中的第一个帐户），很快用户便以管理员身份登录，如下所示。
修复后的代码差异可以在这里找到。开发人员直接删除了对几个对wptc_login_as_admin函数的调用，修复了身份验证流程。
基于WordPress插件库的数据，WP Time Capsule在20000多个网站上都很活跃。
时间线
2020年1月7日：向开发人员报告了漏洞。
2020年1月7日：向所有WebARX客户发布了对应保护模块。
2020年1月8日：开发者发布了修复后新版本。
2020年1月14日：安全公告发布。