【API网关】Apache APISIX内部-外部攻击：API网关安全性研究

之前，我们发表了一项研究，介绍了应用程序编程接口（API）网关安全性。这一次，我们将重点讨论ApacheAPISIXneneneba API网关及其安全影响。

Apache APISIX API网关组件

为了帮助我们更好地了解Apache APISIX API网关，让我们来看看它的组件和信息流。

图1。Apache APISIX API网关信息流

APISIX API网关建立在nginx web服务器和OpenResty扩展框架之上，这两个框架是网关的核心组件。API网关还包括以下组件：

• APISIX内核、基于Lua的插件、多语言插件运行时和WASM插件运行时
• 内置插件，添加了可观察性、安全性和流量控制功能
• 一个可选的仪表板，直接与管理API通信，以提供用于配置网关的图形用户界面（GUI）

APISIX核心处理路由匹配、负载平衡、服务发现、配置管理和提供管理API等功能。它还包括支持Lua和多语言插件（如Go、Java、Python和JavaScript）的APISIX插件运行时。

APISIX还提供了一个可选的web仪表板，该仪表板直接与管理API通信，这为使用图形用户界面（GUI）配置网关提供了一种更方便的方式。

与不更改APISIX的默认主API令牌相关的风险

无论部署位置如何，错误配置都是最普遍的软件部署威胁之一。需要注意的是，安全配置仍然是用户的全部责任，包括云环境中的配置。用户在部署非托管服务时应格外小心。

评估安全默认值及其影响在用户教育中起着至关重要的作用：即使所有安全功能都可用，它们仍然需要得到适当的实施和使用。默认情况下，使用更安全的模式可以使应用程序在设计上更安全，并防止用户犯下无意的错误。

一个明显的安全错误的例子是没有更改管理界面的主密码。当主密码保持不变时，如果使用的默认密码是已知的或典型的，它将为威胁参与者提供管理访问权限。

遗憾的是，APISIX有一个用于访问管理API的默认主API令牌。继续使用默认的API密钥是不负责任的，用户应该立即更改它。

对于软件开发人员来说，不为每个实例生成随机令牌（例如，在其首次运行时），而是使用硬编码的API令牌可能更方便，从而易于遵循文档示例。

如果APISIX生成一个随机的API令牌，优先考虑安全性，我们就不会有默认的凭据问题。

根据我们的观察，具有默认管理令牌的多个暴露实例处于野外，只是等待被威胁行为者利用，而忽略了一个基本的安全概念，即管理员应该将管理API永久隐藏在非本地环境中。

但为什么我们仍然看到暴露的管理飞机实例？

尽管我们在野外看到的一些部署可能是安全研究人员创建的蜜罐，但其他部署则是潜在的配置错误，甚至更糟的是，配置错误的默认值，或公开且保持不变的默认密码和令牌。这个问题有几个层面。

首先，正如我们已经提到的，硬编码的主密码是公开的。

第二，行政专机暴露在外。在这个阶段，需要注意的是，用户应该格外小心其容器化应用程序的默认配置和运行时端口暴露。图2显示了Docker中的容器映像示例，以及当网络访问不受限制时可能发生的情况。

通过漏洞攻击绕过IP限制

更安全的部署可能会受到至少一个web应用程序防火墙（WAF）的保护，该防火墙使用IP限制规则，可以阻止用户访问管理平面。但是，如前所述，此IP限制规则仅适用于APISIX的API网关级别。2022年披露了CVE-2022-24112。该漏洞是2022年威胁参与者最常使用的缺陷之一，允许恶意参与者使用自定义标头绕过IP限制。当在默认管理密码保持不变的环境中利用此漏洞时，恶意行为者可以在API网关上执行远程代码执行（RCE）。

显然，我们可以看到，仅仅通过配置文件中的网络规则来保留默认的API密钥和限制访问是不够的，因为威胁行为者可以找到绕过这些安全部署的方法。因此，使管理平面可用于连接有多个设备的整个专用网络并不是最好的主意。网络连接的设备可能会受到损害，可能会导致网关受到损害。

从CVE-2022-24112的披露中可以吸取一些教训。该漏洞的根本原因仅在IP限制范围内。Apache APISIX的默认配置易受远程代码执行攻击这一事实仍然被忽视。

在我们的研究过程中，我们看到了导致RCE的默认凭据的积极利用。

威胁参与者首先使用默认凭据识别暴露和易受攻击的实例。之后，他们使用APISIX网关的Lua脚本功能创建了一个路由，从而在触发路由时在网关上产生RCE。

在APISIX网关中有不同的方法来执行Lua代码，但没有一种是沙盒的。因此，它允许在APISIX网关上执行Lua的恶意行为者无限制地访问所有可用模块。这允许威胁参与者以各种恶意方式与网关交互，例如部署恶意软件和加密劫持有效载荷，对网关进行拒绝服务（DoS）攻击，或者更糟的是，泄露敏感数据，最终导致云帐户泄露或用户假冒。

APISIX仪表盘潜在风险

可选的APISIX仪表板允许用户友好的网关配置，也存在类似的问题。此仪表板可直接访问网关配置，因此在管理员API与外部世界屏蔽但仪表板仍然可访问的情况下，用户应格外小心。默认情况下，仪表板应用程序需要凭据才能授予访问权限。但是，默认用户名和密码设置为“admin”，尤其是在容器化环境中。

需要强调的是，当APISIX仪表板暴露在外时，它将具有相同的RCE含义。

问题仍然存在——暴露的APISIX服务有多普遍？

暴露在野外的APISIX服务

2024年1月，Shodan搜索显示，622个暴露的唯一IP地址在不同的端口中运行某些版本的APISIX服务。

当我们使用默认令牌检查这些公开实例的内容时，至少有39个实例是完全开放的，公开了敏感数据。

去年，我们发布了一份关于API网关使用案例的报告，其中包括以下内容：

• 访问上游的秘密管理
• 令牌颁发和网关身份验证机制，包括安全身份提供者IdP设置
• 日志和秘密剥离
• 插件和脚本创建

在本报告的前一节中，我们讨论了执行Lua代码所缺少的沙盒。用户在使用基于Lua的插件或脚本并依赖用户输入时应格外小心，因为这些插件或脚本可能会在网关上引入具有RCE功能的漏洞。例如，如果用户在解析HTTP标头时编写了易受攻击的代码，则威胁参与者可以利用该代码并无限制地执行其有效负载。

API网关可用作访问组织整个API基础设施的中心访问点，这使API网关成为恶意行为者的理想目标。当恶意行为者访问网关时，可能会导致多个机密的信息泄露，例如所有后端身份验证令牌和IdP配置机密。披露IdP配置可能导致用户假冒、令牌获取攻击和整个API生态系统的滥用。

在讨论APISIX默认秘密管理系统时，我们必须提到它的默认存储，即存储网关配置的地方。APISIX依赖于etcd，这是一个开源的键值数据库，用于管理分布式系统上的关键信息和配置数据，深受Kubernetes用户的欢迎。该配置是未加密存储的，允许所有有权访问etcd实例的人读取存储在其中的机密。api端点的静态api-key是etcd机密的一个示例。

Figure 7. An API endpoint protected by an API key

Figure 8. An example of a plaintext API key

好消息是，自APISIX 3.1版本以来，用户可以使用插件配置的加密存储。遗憾的是，它不是默认设置，仍然需要额外的配置。

幸运的是，还有其他存储秘密的方法；APISIX还支持将机密存储在vault中，并在配置中引用它们。我们希望鼓励用户使用保管库来存储机密。但是，用户应该注意，他们很可能至少需要一个秘密才能访问vault，从而确保其安全性。

Figure 9. Vault types according to APISIX’s documentation

但是，我们通常不建议将机密存储在环境变量中。在我们2022年发表的一份报告中，我们分析了使用环境变量保守秘密的危险性。环境变量经常被滥用和误解，从而导致安全问题的出现，造成悲剧性的后果。

我们在最近的一份报告中详细描述了这一点，我们在报告中谈到了暴露的容器注册表——将存储在环境变量中的秘密硬编码到容器图像中。

我们承认，从来没有一个100%安全的系统。开发人员可以以“更安全”的方式使用环境变量；然而，这需要理解环境变量的底层实现，并确保不会跨越任何安全边界（例如，仅在运行时注入它们，不进行硬编码）。

我们提供了一个示例，说明如何删除造成安全风险的不必要环境变量，并使用自定义容器映像增强Azure无服务器解决方案的安全性。

Figure 10: An example of a plaintext API key for Azure Functions

过度日志的风险

在解决问题时，日志记录活动可能是救命稻草。它允许管理员和开发人员模拟并了解问题所在。但是，过多的日志记录会占用您的存储空间，并成为额外的攻击面，尤其是当用户记录敏感信息时。用户通常也会与同行讨论悬而未决的问题或上传日志进行咨询。

但是，当敏感信息（如访问令牌）被未经授权的实体记录和访问时，会发生什么？

这个问题的答案取决于多种因素。敏感信息是如何通过请求传递的（无论是在URL、标头还是正文中），活动的记录有多彻底，当然，信息的敏感度有多高？假设我们在HTTPGET请求中传递一个令牌作为参数。我们的问题是：这是一个有效的代币，而不是过期的代币吗？令牌的权限是什么？具有延长有效期的过于宽松的代币是等待爆炸的定时炸弹。

我们已经测试了一个默认设置的http记录器插件；我们只配置了http日志服务器URL。默认情况下，包括授权头在内的所有头都存在。

Figure 12. An example of a default setting for APISIX http-logger

然而，这在安全性方面意味着什么？我们可以说，强大的动力带来巨大的责任，因为配置完全掌握在用户手中。首先，我们应该问自己以下问题：我们想要监控什么？我们真的需要记录代币吗？如果是这样，我们能否剥离、替换或提取敏感信息，使其对威胁行为者没有价值？

例如，如果我们以APISIX文档中的一个例子为例，那么“假定的”默认值提供的信息要少得多。正如我们再次证明的那样，依赖违约是一种危险的做法。用户应该知道他们记录的内容以及目的。

Figure 13. Log based on APISIX’s default documentation

在任何情况下，如果我们出于任何原因记录敏感信息，我们都应该通过确保通过传输层安全性（TLS）进行安全传输并保护其存储（这可能会有问题，尤其是在日志记录平台上）来保护该信息的敏感性。否则，我们只会增加敏感信息被泄露的风险。

当使用第三方IdP服务（如Key斗篷和AWS Cognito）并在数据库中存储配置机密时，强制执行TLS至关重要。

与APISIX API网关插件相关的风险

社区插件可能是漏洞的一个重要来源，尤其是当它们由具有不同经验的多方管理时。在某些情况下，社区插件甚至可以与其安全问题一起集成到产品中。因此，插件的使用不仅应考虑其给定的功能，还应考虑其安全性。

APISIX的API网关将其插件集分为几个类别：转换、身份验证、安全、流量、可观察性和无服务器。这些类别中的每一个都有不同的相关风险。例如，转换插件的风险与处理API请求形式的用户输入、用户的响应以及相关的解析问题有关。同时，身份验证插件容易出现不安全的敏感信息存储和不正确的验证实现。另一方面，如前所述，可观察性插件可能存在与过度记录敏感信息有关的问题。

其中一个身份验证插件是实现RFC-7617的基本身份验证，它使用用户名和密码进行身份验证。尽管目前这种机制在严重的用例中被弃用，但它完美地展示了API网关与机密相关的安全态势。设置此插件后，需要在授权标头中编码的有效用户名和密码才能成功进行身份验证。

Figure 14. An example of basic-auth plugin credentials’ storage

图14清楚地展示了凭证（包括密码）是以明文形式存储的。尽管可以对密码启用加密或保险库引用，但真正的问题应该是为什么要存储密码，以及为什么API网关存储这些秘密。如果机密的原始形式对于第三方服务身份验证是必要的，并且它们不是从初始请求传递的，则存储机密是有意义的。

出于API网关级别的身份验证目的，存储原始密码是不必要的。事实上，这是一个安全漏洞，允许威胁行为者在发生漏洞时利用密码。

为验证目的存储凭据的一种安全方法是创建一个咸散列并存储散列，而不是存储原始密码。如果使用了正确的哈希，在发生漏洞的情况下，威胁参与者将只能访问经过腌制的哈希。考虑到salted hash的属性，他们将无法恢复身份验证所需的纯文本密码，从而使整个生态系统更加安全。

威胁行为者如何滥用API网关进行网络犯罪

威胁行为者如何瞄准API网关？我们将以APISIX API网关为例来回答这个问题。我们应该考虑的第一件事是威胁行为者的动机——他们如何利用API网关安全错误配置达到邪恶目的。

显然，滥用免费的易受攻击的计算资源是部署加密劫持恶意软件的有效动机和理由，该恶意软件可以产生收入，包括机器人加入分布式拒绝服务（DDoS）攻击中使用的大规模网络。

另一个动机可能是恶意软件的分发。考虑到API网关充当API/后端资源，而它不太可能充当纯HTML资源，这种情况可能会更复杂。然而，我们可以想象一个API服务返回软件下载链接。在这种情况下，被利用的API网关实例可能被配置为恶意链接，从而成为供应链攻击。

在更有针对性的攻击中，威胁行为者可能会使用API网关功能来收集凭据、执行用户模拟或获取关键的公司信息，以便在未来的有针对性的袭击中出售或利用这些信息。

在蜜罐数据的狂野视角中

我们的蜜罐于2023年10月至2024年1月活跃，旨在监测和分析对链接到网站的API的攻击。该网站托管在端口80上，是吸引攻击者访问API的前沿阵地，该API托管在更高的端口上，并链接到该网站的源代码。

在此期间，该网站收到了约24000个请求，而API端点收到了约15500个请求。排除主要来自机器人的root“/”请求，我们发现了大约11500次使用众所周知的通用漏洞的尝试。

Figure 16. APISIX gateway-specific requests

 

该设置没有明确表明是通过APISIX管理的，要求攻击者与API交互，以辨别它是不是。值得注意的是，有14次针对APISIX的攻击，其特征是特定的URL、额外的API请求参数，以及试图使用常见的用户名-密码组合访问管理面板。

Figure 17. An example of an HTTP request that targets an exposed APISIX dashboard with default credentials

结论

错误配置是当今最普遍的安全问题之一。依赖所谓的安全默认是一个重大的安全风险，更改默认安全设置，尤其是硬编码和主凭据，是必不可少的。更新软件可以被认为是最佳实践的陈词滥调，但其重要性不容低估。确保您的APISIX网关不易受到任何公开漏洞的攻击，特别是CVE-2022-24112，这应该是一个重要的优先事项-该漏洞在被利用时可以完全控制API网关，同时为恶意行为者提供一个进入集中式系统的入口，该系统可能会聚合您的整个API生态系统。

鉴于漏洞的性质和APISIX的核心功能，用户不仅应谨慎部署最新的API网关，还应谨慎使用基于Lua的自定义脚本，因为这些脚本可能会引入威胁行为者容易利用的漏洞。

确保etcd等存储的安全以及对每个管理平面和仪表板的访问同样至关重要。管理员应考虑应用WAF以外的网络保护机制（用于异常检测），因为如我们所述，链接到API网关的各个后端也可能存在漏洞。

由于许多现代软件应用程序部署在设计时没有考虑到安全性，因此系统管理员必须实施安全性最佳实践。将对多个后端的访问聚合到一个点正变得越来越流行，尤其是在混合云解决方案中。这就是应用程序后端分布在云服务提供商（CSP）或内部部署平台之间的地方。然而，在实施这种方法之前，用户应该权衡聚合到单个接入点的额外安全风险。如果没有得到充分的保护，单个接入点可能会在妥协后迅速成为组织的单个故障点。

API网关聚合对内部部署后端的访问，并提供集成多个云无服务器框架和支持身份提供商配置的功能方式。然而，重要的是要记住，错误的配置和过度的令牌权限可能会导致完全的云帐户泄露或用户假冒。