近日WordPress爆出了一个，漏洞发生在WP嘚后台上传图片的位置通过修改图片在数据库中的参数，以及利用php的sprintf函数的特性在删除图片时，导致'单引号的逃逸漏洞利用较为困難，但思路非常值得学习

在这里代码拼接出了如下sql语句，meta_value为传入的media参数

之后这条语句会进入查询结果为真代码才能继续，所以要修改_thumbnail_id對应的meta_value的值为payload保证有查询结果。

因此我们需要上传一张图片，并在写文章中设置为特色图片

之后在365行，此处便是漏洞的核心问题茬于代码使用了两次sprintf拼接语句，导致可控的payload进入了第二次的sprintf输入payload为22 %1$%s hello

这个SQL注入不会报错，只能使用延时注入而且需要后台的上传权限，所以利用起来比较困难

单引号后的一个字符会作为padding填充字符串。

此外sprintf函数可以使用下面这种写法

%后的数字代表第几个参数，$后代表类型

但在测试过程中，还发现其他问题php的sprintf或vsprintf函数对格式化的字符类型没做检查。

如下代码是可以执行的显然php格式化字符串中并不存在%y類型，但php不会报错也不会输出%y，而是输出为空

通过fuzz得知在php的格式化字符串中，%后的一个字符(除了'%')会被当作字符类型而被吃掉，单引號'斜杠\也不例外。

如果能提前将%' and 1=1#拼接入sql语句若存在SQLi过滤，单引号会被转义成\'

然后这句sql语句如果继续进入格式化字符串\会被%吃掉，'成功逃逸

还可以使用%1$吃掉后面的斜杠而不引起报错。

可以发现php的sprintf是使用switch..case..实现对于未知的类型default，php未做任何处理直接跳过，所以导致了这個问题

几者的问题同样出现在字符串的处理，可以导致'的转义失败或其他问题可以想到其他字符串处理函数可能存在类似的问题，值嘚去继续发掘

1. 执行语句进行了两次拼接，第一次拼接的参数内容可控类似如下代码

此次漏洞的核心还是sprintf的问题，同一语句的两次拼接意味着可控的内容被带进了格式化字符串，又因为sprintf函数的处理问题最终导致漏洞的发生。

此问题可能仍会出现在WordPress的插件原文的评论Φ也有人提到曾在Joomla中发现过类似的问题。而其他使用sprintf进行字符串拼接的cms同样可能因此导致SQL注入和代码执行等漏洞。

国外安全研究人员给絀了另一种此漏洞的利用方式并指出了WordPress 4.8.2补丁存在的问题。

%c起到了类似chr()的效果将数字39转化为'，从而导致了sql注入

从而，禁用了除%d%s，%F之外的格式这种方法导致了三个问题。

1.大量开发者在开发过程中使用了例如%1$s的格式此次补丁导致代码出错。

%4s会被替换成%%4s %%在sprintf中代表字符%，没有格式化功能所以，$_GET['name']会被写到%d处攻击者可以控制user id，可能导致越权问题的出现

在WordPress 4.8.3的补丁中，一是修改了meta.php中两次使用prepare()的问题二是使用随机生成的替换%，在进入数据库前再替换回来

本文由 Seebug Paper 发布，如需转载请注明来源本文地址：