利用 JSON 语法绕过 WAF 对 SQL 注入攻击的检测

JSON 语法自 2012 年开始作为新特性被各类 SQL 数据库支持，目前所有主流数据库都已支持 JSON 语法，但目前的主流 WAF 并没有做相应跟进，从而可以被绕过。

Team82开发了一种通用的绕过行业领先的web应用程序防火墙(WAF)的方法。 攻击技术包括将JSON语法附加到WAF无法解析的SQL注入有效负载。

主要的WAF供应商在他们的产品中缺乏JSON支持，尽管大多数数据库引擎已经支持了十年。 大多数WAF可以很容易地检测到SQLi攻击，但是将JSON前置SQL语法使WAF无法检测到这些攻击。

使用这种技术的攻击者将能够绕过WAF的保护，并使用其他漏洞来窃取数据。

简介

Web应用防火墙(WAF)旨在保护基于Web的应用程序和API免受恶意外部HTTPs流量的影响，尤其是跨站脚本和SQL注入攻击，这些攻击危险似乎还未解除。

WAF的引入在很大程度上是为了应对这些编码错误。WAF现在是保护存储在数据库中的组织信息的关键防线，这些信息可以通过web应用程序访问。WAF也越来越多地用于保护基于云的管理平台，这些管理平台监督连接的嵌入式设备，如路由器和接入点。

能够绕过WAF的流量扫描和拦截功能的攻击者通常可以直接访问敏感的业务和客户信息。值得庆幸的是，这样的绕过并不常见，而且针对特定供应商的实现是一次性的。

目前，Team82引入了一种攻击技术，它是业界领先供应商销售的多个web应用程序防火墙的第一个通用绕过。该绕过适用于五个主要供应商销售的WAF: Palo Alto, F5, Amazon Web Services, Cloudflare和Imperva。目前，所有受影响的供应商都承认Team82的披露，并实施了修复，将JSON语法支持添加到其产品的SQL检查过程中。

Team82的技术首先依赖于理解WAF如何识别和标记恶意SQL语法，然后找到WAF看不到的SQL语法。这是JSON。JSON是一种标准的文件和数据交换格式，通常用于将数据从服务器发送到web应用程序。

在SQL数据库中引入JSON支持可以追溯到大约10年前。现在的数据库引擎默认支持JSON语法、基本搜索和修改，以及一系列JSON函数和操作符。虽然JSON支持是数据库引擎的标准，但WAF却并非如此。供应商在添加JSON支持方面一直进展缓慢，这使得Team82能够创建新的SQL注入有效负载，其中包括绕过WAF提供的安全性的JSON。

使用这种新技术的攻击者可以访问后端数据库，并使用额外的漏洞，通过直接访问服务器或通过云窃取信息。

这对于已经转向基于云的管理和监控系统的运行和物联网平台尤为重要。WAF提供了来自云的额外安全性的承诺，能够绕过这些保护的攻击者可以广泛地访问系统。

Team82在去年开发了这项技术，当时他们正在对Cambium Networks的无线设备管理平台进行不相关的研究，包括其内部或云端销售的cnMaestro无线网络管理器。

Cambium Networks无线接入点

Cambium的cnMaestro云架构允许用户从云端远程配置和控制他们的AP Wi-Fi设备

为了了解平台是如何构建的，以及它的许多内部API和路由，Team82从Cambium的网站下载了cnMaestro内部部署的开放虚拟化格式虚拟机。

Team82了解到cnMaestro是由许多不同的NodeJS后端服务构建的，这些服务处理用户对特定路由的请求。这些服务都有轻微的混淆，使得研究平台变得困难。为了将每个请求代理到正确的服务，Nginx被用来通过所请求的URL来传递请求。

cnMaestro提供了两种不同的部署类型:

本地部署：创建一个由用户托管和管理的专用cnMaestro服务器。

云部署：位于Cambium Networks云基础设施上的cnMaestro服务器，cnMaestro的所有此类实例都以多租户架构托管在Cambium组织下的Amazon AWS云上。 

云部署

托管在亚马逊AWS上的cnMaestro云部署包括一个cnMaestro的主要实例(托管在https://cloud.cambiumnetworks.com上)，它处理登录、设备部署，并将大部分平台数据保存在主数据库中。

任何注册到cnMaestro Cloud应用程序的用户都会获得一个个人Amazon AWS实例，其中包含个人URL (Cambium主云的子域)和组织标识符。这有助于在多租户设计中分离不同的用户。为了访问你的cnMaestro实例，将按照以下方案生成一个唯一的URL：https://us-e1-sXX-XXXXXXXXXX.cloud.cambiumnetworks.com

在Team82对Cambium cnMaestro的研究结束时，他们发现了7个不同的漏洞，可以在这里和Team82的披露仪表板上看到。然而，一个特别的漏洞让Team82陷入了一个巨大的兔子洞，导致Team82发现并开发了这项新技术。

很难利用的零日漏洞 

Team82发现的一个特殊的Cambium漏洞被证明更难利用：CVE-2022-1361。该漏洞的核心是一个简单的SQL注入漏洞，但实际的开发过程需要Team82跳出思维定式，创建一个全新的SQL技术。利用这个漏洞，Team82能够窃取用户的会话、SSH密钥、密码哈希、令牌和验证码。

此漏洞的核心问题是，在这种特殊情况下，开发人员没有使用准备好的语句将用户提供的数据附加到查询中。他们没有使用将用户参数附加到SQL查询并清除输入的安全方法，而是直接将其附加到查询中。

Team82在CVE-2022-1361中滥用的SQL注入汇点

正如我们在上面的汇点中看到的，应用程序接受用户提供的数据（在本例中为a.serialNo或a.mac），并将其附加到SQL查询中。我们使用此漏洞的目的是过滤存储在数据库中的敏感数据。然而，虽然这看起来很简单，但在快速分析了该漏洞后，我们意识到它有三个关键漏洞/限制：

Team82只能检索作为返回行的整数 ；

返回的行按随机顺序返回；

在每个请求中，Team82只能返回有限数量的行。

让我们深入分析这些限制。

限制1：Team82只能检索整数

第一个限制只返回整数，而不返回字符串。由于原始请求返回整数，我们将使用的任何联合语句也必须返回整数。在SQL中，如果执行联合操作，则必须确保两列的类型相同，并且由于一方获取整数，因此我们也必须返回整数。由于我们要过滤的数据很可能是字符串（会话令牌、SSH密钥等），因此我们必须以某种方式获得过滤字符串的能力。

通过将想要过滤的任何字符串转换为整数数组，并将每个字符作为单独的行返回，可以轻松克服这一限制。为此，Team82使用了stringarray和ASCIISQL函数。

一个SQL查询，返回字符串作为其字符的整数列表

限制2：返回的行按随机顺序返回

第二个限制是，当Team82返回多行时，web服务器将以随机顺序返回给Team82。当Team82查看漏洞后执行的代码时，Team82看到对于SQL查询返回的每一行，服务器将执行一些其他异步操作(这可以通过调用async.parale函数看到)。这意味着返回行的原始顺序将不会被保留，相反，该顺序将是异步操作完成的顺序。

这意味着，如果Team82将字符串作为整数数组进行过滤，就会丢失字符顺序，从而使过滤变得无关紧要。

Team82通过添加行索引来克服这一限制，行索引使用row_number SQL函数将字符串中字符的索引转换为返回的整数。因为Team82只返回ASCII字符，所以每个字符的值被限制为128。通过将索引号乘以1000 (i * 1000)并将其附加到结果中，Team82总是可以通过简单的除法和模块操作来确定字符索引。

一个SQL有效负载，返回字符串中每个字母的ascii值，加上字符的索引乘以1000

在检索到过滤的数据之后，Team82可以简单地将每个返回行除以1000，以了解字符索引。Team82还可以通过对返回值使用模块操作来恢复原始字符ASCII值。

限制3：在每个请求中只能返回有限数量的行

最后一个限制是最难克服的：超时问题。对于返回的每一行，服务器都执行了一些其他操作，包括另一个SQL查询和数据操作。当我们试图检索大量行时，请求超时。更糟糕的是，API端点相当慢，因此每次检索一行非常耗时。

Team82的解决方案实际上非常高级，Team82不是为每个字符返回一行，而是从许多行中构造一个整数。这是可能的，因为整数和字符之间的字节大小不同。在PostgreSQL中，一个整数是4字节长，而Team82试图过滤的字符是1字节长(只要是ascii字符)。这意味着通过执行简单的字节操作，Team82可以在每个整数中容纳四个不同的字符。此外，如果Team82在union命令中将整数转换为BIGINT，这在PostgreSQL中是可能做到的，Team82可以将每行扩展为8字节。

PostgreSQL类型大小

这意味着，如果要为Team82过滤的每个字符附加8个字节，并将其附加到BIGINT中，Team82可以在每个请求中过滤7倍多的字符(1个字节保留给字符索引)。

一个SQL查询，它接受一个字符串，并每隔几个字符创建一个BIGINT

使用这种方法，Team82能够在每个请求中提取多达8倍的数据。这减少了Team82窃取大量数据所需的时间，并使攻击场景变得可信。

构建有效负载 

在Team82绕过所有三个限制之后，Team82就得到了一个大的有效负载，允许提取任何Team82选择的数据:。

事实上，当Team82使用这个有效负载时，Team82设法窃取了存储在数据库中的敏感信息，从会话cookie到令牌，SSH密钥和哈希密码。

使用SQLi有效负载提取的数据示例

云端漏洞 

在成功利用了云部署漏洞后，下一步是在Cambium的云端尝试相同的漏洞。很快，Team82就找到了相应的云路由，并成功确认它也容易受到同样的漏洞的攻击。然后Team82尝试了一个安全版本的有效负载，并收到了这样的响应。

对SQL注入漏洞的响应，可以看到Team82的请求被释放了，返回一个403 Forbidden

接下来，我们注意到了包含awselb/2.0的HTTP服务器，这意味着，应用程序并没有停止Team82的请求，而是AWS WAF释放了Team82的请求，因为它可能将其标记为恶意请求。

对AWS WAF 的研究

为了研究AWS WAF，我们首先创建了自己的设置，在其中控制所有的活动部件：应用程序、客户端和WAF设置和日志。我们在AWS云上创建了一个简单的设备，并设置了AWS WAF来保护应用程序免受恶意请求(Team82设置了WAF)。

用于配置WAF规则集的界面 

然后，Team82创建了一个带有SQLi漏洞的web应用程序，并将其托管在AWS上。

Team82创建的易受攻击的Flask web应用程序

最后，Team82开始发送数百个自定义的请求，试图分析WAF是如何将请求标记为恶意的。

被WAF标记为恶意的请求被阻止，在这个请求中，Team82传递一个通用的SQLi有效负载，它由WAF标记

WAF通常有两种方法将请求标记为恶意：

搜索黑名单单词：WAF可以搜索它并将其识别为SQL语法的单词，如果请求中存在太多匹配项，它会将该请求标记为恶意SQLi尝试。

从请求中解析SQL语法：WAF可以尝试使用请求的不同部分解析有效的SQL语法，如果WAF成功识别SQL语法，它将标记该请求为恶意SQLi尝试。 

虽然大多数WAF除了使用WAF特有的方法外，还会使用这两种方法的组合，但它们都有一个共同的漏洞：它们需要WAF识别SQL语法。这引发了Team82的兴趣：如果Team82能够找到WAF无法识别的SQL语法，该怎么办？

SQL JSON

目前，JSON已经成为数据存储和传输的主要形式之一。为了支持JSON语法，并允许开发人员以类似于在其他应用程序中与数据交互的方式与数据交互，SQL中需要JSON支持。

目前，所有主要的关系数据库引擎都支持原生JSON语法，这包括MSSQL, PostgreSQL, SQLite和MySQL。此外，在最新版本中，所有数据库引擎默认启用JSON语法，这意味着它在今天的大多数数据库设置中很普遍。

开发人员选择在SQL数据库中使用JSON特性，原因有很多，首先是更好的性能和效率。由于许多后端已经使用JSON数据，因此在SQL引擎本身执行所有数据操作和转换可以减少所需的数据库调用数量。此外，如果数据库可以使用JSON数据格式(后端API很可能也会使用JSON数据格式)，那么所需的数据预处理和后处理就会更少，从而允许应用程序立即使用它。

通过在SQL中使用JSON，应用程序可以在SQL API中获取数据、从数据库中组合多个数据源、执行数据修改并将其转换为JSON格式。然后，应用程序可以接收json格式的数据并立即使用它，而不需要处理数据。

在SQL中使用JSON的数据流，允许开发人员在SQL中使用JSON API更好地与数据交互

虽然每个数据库都选择了不同的实现和JSON解析器，但每个数据库都支持不同范围的JSON函数和操作符。此外，它们都支持JSON数据类型和基本的JSON搜索和修改。

对每个主要数据库的JSON支持级别

然而，尽管所有的数据库引擎都增加了对JSON的支持，但并不是所有的安全工具都增加了对这个“新”特性的支持。安全工具中缺乏支持可能会导致安全工具(在Team82的例子中是WAF)和实际数据库引擎之间的原语解析不匹配，并导致SQL语法错误识别。

The New ‘ or ‘a’=’a

使用JSON语法，可以创建新的SQLi有效负载。由于这些有效负载不为人所知，它们可以绕过许多安全工具。使用来自不同数据库引擎的语法，Team82能够在SQL中编译以下真实语句列表:

使用JSON语法

从Team82对WAF如何将请求标记为恶意的理解中，可以得出结论，Team82需要找到WAF无法理解的SQL语法。如果Team82可以提供一个SQLi有效负载，WAF不会将其识别为有效SQL，但数据库引擎会解析它，Team82实际上就可以实现绕过。

事实证明，JSON正是WAF解析器和数据库引擎之间的这种不匹配。当Team82传递使用不太流行的JSON语法的有效SQL语句时，WAF实际上并没有将请求标记为恶意请求。

下面是一个恶意的SQLi有效负载，包含JSON语法。正如Team82所看到的，WAF并没有将该请求标记为恶意请求，也没有释放它

这个简单的JSON运算符，在本例中是@>，它检查右边的JSON是否包含在上面左边的JSON中，它将WAF放入一个循环中，并允许Team82提供恶意的SQLi有效负载，从而允许Team82绕过WAF。通过简单地在请求的开头预先添加简单的JSON语法，Team82就能够在云上使用SQLi漏洞窃取敏感信息!

利用云上的SQL注入漏洞

常见的WAF绕过 

上述绕过的核心问题是数据库引擎和SQLi检测解决方案之间缺乏一致性，这是因为SQL中的JSON并不是一个流行和广为人知的特性，而且它的语法没有添加到WAF解析器中。

然而，Team82认为这个问题可能不仅仅与这个WAF供应商有关，可能其他供应商也没有添加对JSON语法的支持。所以Team82采用了易受攻击的web应用程序，并在大多数主要WAF供应商上创建了一个设置。几天后，Team82发现JSON语法可以绕过他们检查过的大多数供应商:

Palo-Alto下一代防火墙

F5 Big-IP

Amazon AWS ELB

Cloudflare

Imperva

Team82使用JSON语法绕过的WAF供应商和产品列表

Team82成功地绕过了这么多大型WAF产品，如果Team82的有效负载有任何变化，这意味着Team82有一个通用的WAF绕过。这意味着即使不知道Team82和目标之间的WAF是什么，Team82仍然可以利用SQL注入漏洞，绕过WAF的保护。

自动化流程

为了研究这种WAF绕过的危害有多大，Team82决定在最大的开源开发工具SQLMap中添加对JSON语法规避技术的支持。

SQLMap工具允许用户自动化和攻击目标

SQLMap提供了一个自动利用SQL注入的过程，允许用户扫描整个网站以查找漏洞。在SQLMap识别出SQL漏洞后，它提供了识别漏洞类型和识别最适合此特定漏洞的利用技术的能力。

在正确选择利用漏洞的技术后，SQLMap甚至为用户提供了自动转储存储在数据库中的信息、枚举表和数据库、提取密码哈希以及执行一些利用后技术的能力。

虽然SQLMap提供了一些WAF逃避技术，但Team82发现它仍然很容易被大多数现代WAF识别，这意味着用户不能在存在WAF的情况下使用它。

试图在受WAF保护的应用程序上执行SQLMap。我们可以清楚地看到，尽管应用程序是易受攻击的，但SQLMap并不认为它是可利用的，因为大多数请求都被WAF释放了

Team82的目标是将这项新技术引入SQLMap，并使用JSON语法绕过WAF。为此，Team82注入了由SQLMap生成的有效负载，并添加了随机生成的JSON语法。由于每个数据库引擎都实现了一组不同的JSON函数和操作符，因此Team82为每个数据库引擎实现了一个单独的脚本。通过对SQLMap的添加，Team82能够绕过一个众所周知的WAF，并成功地利用了一个易受攻击的web应用程序。

使用Team82的脚本运行SQLMap允许SQLMap成功地利用易受攻击的web应用程序并绕过WAF

如果你希望使用此脚本来测试此绕过，只需从Github克隆SQLMap的最新版本。

总结

Team82发现，主要供应商的WAF在其SQL注入检查过程中不支持JSON语法，这使得Team82可以在SQL语句中预先添加JSON语法，从而使WAF无法识别恶意代码。

Team82向五家领先的WAF供应商披露了其发现，目前所有这些供应商都在其产品中添加了JSON语法支持。Team82认为其他供应商的产品可能会受到影响，应该对JSON支持进行审查。

本文翻译自：https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf?utm_campaign=%5BTeam82%5D+%7BJS-ON%3A+Security-OFF%7D+blog+-+December+2022&utm_content=Oktopost-twitter&utm_source=twitter&utm_tags=Blog%2Cvulnerability+disclosures%2CTEAM82%2Cresearch%2Cjson如若转载，请注明原文地址