原文链接：https://medium.com/@0xInfection/fingerprinting-waf-rules-via-timing-based-side-channel-attacks-cd29c48fb56

今天在这篇文章中，我将详细介绍我最近的Web应用防火墙（WAF）实验，重点关注特定类型的侧信道攻击，即时间。

在我看来，这个领域还没有得到深入的研究，结果可能比你期望的更致命。这篇文章写的时间已经很久了，所以让我们马上开始阅读吧。

侧信道攻击

维基百科将侧信道攻击定义为：
基于从计算机系统的实现获得信息的攻击，而不是实现的算法本身的弱点。

现在，我们正在提取/学习敏感信息，这些信息的发掘不是现有众人所熟知的侧信道攻击技术所能实现的。这通常是由于一些容易受到这种枚举攻击的错误业务逻辑而导致的信息泄露。

我们今天要谈的攻击是基于时间的。定时攻击的重点是运行系统或算法的硬件上的CPU/内存中的数据流入和输出，只需观察CPU分析数据所用时间的时间变化，就可以从系统中枚举内部敏感信息。

Web应用程序防火墙

众所周知，Web应用程序防火墙用于检测和阻止对易受攻击的Web应用程序的攻击，除了阻止恶意请求之外，WAF通常用于“隐藏”包含敏感信息（如错误消息或堆栈跟踪）的传出响应，
WAF通常通过一组称为过滤规则的正则表达式来区分正常请求和恶意请求。

采用的指纹识别规则

我们的目标是找到WAF规则集中的漏洞，因此，基本上通过指纹识别WAF的规则，实际上能够检测出正在使用哪种过滤策略，并且可以以避开WAF的方式调整攻击方法。一旦制定了WAF的特定绕过方式，攻击者就可以进一步利用Web应用程序中的现有漏洞。

在本文中，我使用了一种常见的规则指纹识别方法，称为正则表达式反转，它通常依赖于检查请求的每个单独组件，以了解请求的哪个部分不可以绕过。

了解WAF安装程序

通常，WAF部署在以下4种网络拓扑中：

1. 反向代理：WAF位于客户端和服务器之间，拦截请求。客户端直接连接到WAF，然后WAF将查询（如果正常）传递给服务器。如果请求被阻止，则查询永远不会到达服务器。

2. Server-Resident：这是在WAF通常安装在它正在保护的服务器上时的设置。这可以进一步分为2种拓扑，第一种是将WAF作为插件安装，而第二种是将WAF作为编程库安装。

1. Out-of-Band：在这种情况下，WAF通常通过网络设备上的监控端口获取流量的副本。这种实现方式限制了WAF阻止请求的能力，并且只有在检测到恶意查询时才能发送TCP重置数据包以中断流量。

1. 云部署：此设置包括在提供商的网络云内运行的WAF。工作类似于反向代理设置，但服务器的每个请求都必须通过网络云。

在我的实验中，我采用了两种最常用的WAF实现，即反向代理和基于插件的服务器驻留设置。

WAF指纹识别的常规方法

通常，通过唯一Headers，Cookie，Responses（如状态代码，响应短语/原因和页面内容）来识别任何WAF。有很多很棒的WAF指纹/bypassing工具，例如:WAFW00F，WAFNinja等。

他们通常利用存储侧通道在WAF内指纹规则（无论请求是否被阻止或接受）并进一步绕过它们。所有这些工具都可以观察到：

WAF阻止消息：表示WAF已标记并将请求阻止为恶意请求。通常，阻止的响应页面或标头定义请求已被阻止。有时，响应状态代码（403 Forbidden）也表示阻止请求。

Web-App错误消息：表示Web应用程序在请求时出错。但是，错误消息会被WAF的自定义阻止页面隐藏。在这种情况下，WAF不会阻止请求，而只是隐藏Web应用程序的错误消息，以防止通过堆栈跟踪等敏感信息泄露。

正常响应：表示请求已明确通过WAF传递到Web服务器。但是，在将请求传递到服务器之前，WAF仍有可能拦截请求并删除了请求的恶意部分。

主要缺点

正如你可能刚刚注意到的那样，仅仅通过观察响应，人们无法明确区分传递和阻止的请求（第1和第2点），因为在两种被拒绝的情况下都可以观察到WAF阻止页面请求以及内部Web应用程序错误消息（由WAF隐藏）。

什么是时间攻击？

上述缺点的解决方案是基于时间攻击的这种新方法。通过利用时间攻击，可以判断请求是否导致某个响应，即被阻止或被传递;

对于web-app错误消息，由于响应时间远远大于传递的请求，因此它被忽略。我的实验结果统计表明，我们可以精确地指纹阻止并传递请求，准确率超过95％。

攻击的想法

原理

这种攻击技术的主要原则是被阻止的恶意请求比响应的正常请求花费更少的时间（以毫秒为单位）。被拒绝的请求比正常传递的请求更早完成，因为丢弃的请求永远不会被服务器处理。

因此，阻塞请求和传递请求之间的时序差等于应用逻辑的处理时间。

假设：这里唯一的假设是我们的WAF阻止请求并在检测到恶意请求后立即返回错误消息。剥离请求的恶意部分并将已清理的请求转发到服务器的其他WAF变体不被考虑在内。

检测方法

为了区分被阻止和被传递的请求，我们需要两种不同类型的请求，一个正常的请求，它将毫无困难地通过WAF传递。第二种类型是包含payload字符串的恶意类型<script>alert()</script>，可以很容易地检测到它。

我们最初解决这个问题的方法是首先将攻击分为两个阶段：

1. 学习阶段：在此阶段，我们测量并了解在我们的攻击阶段中阻塞和传递的请求可能的响应时间以供进一步参考。

1. 攻击阶段：在此阶段，我们执行实际测试，即发送恶意请求以获得最终结果并进行进一步的统计分析。

现在，来计算方法。在学习阶段，首先，我们测量的响应时间：〈Tₙ = t₁, t₂, … tₙ 〉，的n被禁止的请求 ，并定义一个“标记阈值”。在确定请求是通过还是被阻止时，此标记阈值将作为将来的参考。它可以表示为：

类似地，我们通过获取n个传递的请求来定义“传递阈值”，其中可以通过获取超过未检测到的WAF的请求的所有响应时间的最小值来定义边界。此阈值可表示为：

在两种情况下，δ表示由于可能的网络延迟或噪声，实际的通过/阻塞边界可能略小于测量值的边界。

所以现在理论上，我们的标记和通过边界的时间应该作为阻塞和传递请求的阈值，而实际上由于网络中明显的噪声，这是不可复制的。因此，我们采用阻塞和传递边界的均值来获得绝对边界，该绝对边界可以给出关于被阻塞和被传递的请求的响应时间的实际阈值。

显然，对于请求的任何时序测量 t ≥ tᵦ 是一个传递的请求而 t < tᵦ是被阻止的请求。但是，响应时间接近边界的任何请求tᵦ

可以表示低噪声的通过请求或具有高噪声的阻塞请求。为了排除这一点，攻击者需要放大这个攻击向量。我们将详细讨论这个问题，继续阅读。

进行实验

安装程序

为了实现上述理论，我采用了两种最常用的WAF设置拓扑，即基于反向代理和基于服务器驻留（插件类型）的拓扑。

我在我自己的服务器上托管了这些设置，并完全按照它们在现实生活中实现的方式进行。为了测试这种方法，我选择了Shadow Daemon，因为它的开源，低规则维护性质。此外，它很容易设置，因此移植代码作为插件工作并不是太困难。

学习阶段

我写了一个小的python脚本，它从学习阶段开始，一个接一个地重复发送正常和恶意请求，每次请求之间的时间延迟为2秒。

共使用了200个请求，其中一百个包含正常请求，另一半包含恶意字符串。学习阶段非常清楚地表明了这种方法的有效性。

传递和阻止/拒绝请求的一些示例是：

你可能会注意到，在请求被阻止的情况下，某些请求越过了标记边界。这可能是由于互联网连接遭受数据包丢失或网络拥塞。但是，可以清楚地注意到，任何一方都没有跨越绝对边界的请求。

攻击阶段

实际测试的时间。在此阶段，将收集一组最常见的恶意payload，以便针对目标进行测试。现在，这里的想法是通过逐渐将不同的混淆案例添加到各种上下文的查询字符串来生成多态payload的序列。

多态payload的工作完全相同的方式相同恶意payload（语义相同），但语法不同/混淆以便防火墙正则表达式无法检测到它。我们将在另一篇文章中讨论有关此主题的更多内容，但现在让我们举一个小例子：

现在，一系列此类请求将发送到托管WAF的服务器，并记录响应时间。为了进一步验证实验的声明，记录了响应状态代码和块页面。正确识别的恶意请求将导致403状态以及作为响应内容的阻止。

在反向代理设置上，结果非常符合预期。标记和传递的请求之间的最小时间间隔为53.2 ms。结果表明，在96.4％的案例中，我们能够正确区分被阻止和被传递的请求。因此，我们可以有把握地说，我们的这种拓扑方法的准确性和可靠性足够高，可以断言任何攻击者只需要几次重复即可达到完美的测量条件。

在服务器驻留设置（基于插件）的情况下，我实际上并不期望结果具有如此独特的结果，但是我惊讶地发现该方法在反向代理拓扑的情况下工作得很好。

我在这个设置中注意到值得注意的是，阻塞和传递请求（58.8 ms）之间的总体时序差异大于先前的拓扑（53.2 ms）。此拓扑获得的结果可视化如下：

因此，我们可以有把握地说，我们的定时攻击在95％以上的案例中明确区分了被阻止和通过的请求。我的实验的简短摘要如下：

方法的缺点

这种方法的主要缺点是任何攻击者都需要发送大量请求来查找WAF规则集中的漏洞。除此之外，我们还将网络噪声/抖动问题作为一个重大障碍，导致测量结果不稳定。

我们可以添加到此列表中的另一个因素是服务器负载，它可以是加法或乘法，具体取决于服务器处理请求的性质。

现代精心布置的WAF通常实现一种安全机制，当WAF在请求中检测到恶意字符串时，客户端的IP无限地/在有限时间内被阻止。这极大地限制了这种方法的能力。

我们可以。但是我们可以用另一种技术解决这个问题。

解决方案

这种问题的显而易见的解决方案是在合理的时间内执行越来越多的测试，直到我们获得平均结果，从而排除具有大响应时间的剩余查询。

此外，由于网络噪声严格来说是非负的，这实际上是由于我们的攻击向量的性质，即测试布尔值。在WAF阻止客户端的IP地址的情况下，IP轮换攻击以及跨站点定时攻击非常有效地绕过了阻止IP的丑陋场景。在许多情况下，在连续请求之间设置时间延迟也会有所帮助。

放大攻击

那么我们怎么能放大这个攻击向量呢？让我们来看看：

1.选择更长的URL路径：当从服务器查询资源时，它由服务器CPU处理，不同的组件一起累积（例如图像，CSS等），然后通过响应提供给我们。

因此，我们可以选择一个URL路径，其响应内容是所有其他URL路径中最长的（例如，对于博客站点，我们可以选择具有最大图像数量的文章），从而导致服务器CPU上的更多负载。服务器处理请求所花费的时间越多，攻击的有效性就越大。

2.拒绝服务攻击：其次，我们可以将该过程与各种拒绝服务攻击相结合，例如提交具有大量查询的搜索框，发送具有大内容的POST请求，哈希冲突攻击（HashDoS）等。指纹识别所花费的时间越长，噪声的影响就越小。

3.跨站点规则指纹识别： 最后，我们可以通过跨站点请求伪造（CSRF）攻击来链接我们的指纹识别过程，这需要攻击者将用户引诱到他可以嵌入一些HTML和JavaScript来为用户进行测量并为他记录结果的站点。例子如下：

<html>
<body>
<img id="test" style="display: none">
<script>
  var test = document.getElementById(’test’);
  var start = new Date();
  test.onerror = function() {
var end = new Date();
alert("Total time: " + (end - start));
  }
test.src = "http://sitename.tld/path?" + parameter + "=" + payload;
</script>
</body>
</html>

在上面显示的代码中，我们创建了一个不可见的img标记。就在我们将payload复制到图像的URI之前，我们开始记录时间。由于图像无效，浏览器将触发onerror事件处理程序，并且当时间记录停止时将执行相关功能，并且将弹出具有记录时间的警报框。

这种方法有三个主要优点：

1. 首先，攻击者的身份仍然隐藏起来。由于多个用户将使用WAF向服务器发送请求，因此几乎无法区分谁是这背后的实际角色。

1. 这种方法绝对超越了阻止IP地址的WAF作为计数器安全措施的影响。

1. 此外，特别重要的是声明该方法仅在基于时间的攻击时可靠地工作。有时SOP（同源策略）可能会限制从其他来源读取页面内容。因此，在这种情况下，可能无法使用存储侧通道观察阻塞并指纹WAF。

结论

所以我们总结一下。此攻击媒介突出了基于时间的侧通道攻击在网络上的有效性，以及WAF开发人员编写防弹规则集的重要性。

在我的这个小小的努力中，我在ShadowD WAF规则集中发现了几个绕道和漏洞，在我的下一篇文章中，我将写到我发现的bypassing!