暴露的 API 安全性 ： API 漏洞在现实世界数据泄露中的作用

API 漏洞在现实世界数据泄露中的作用 Alfredo Oliveira, David Fiser Contents 组织真的理解API安全的复杂性吗？未能保障系统安全是否可能会使整个业务面临风险？ 在本文中，我们讨论了公司在实际应用中面临的API安全风险。首先，我们重点关注了两个流行的API网关：APISIX和Kong。我们发现超过600个APISIX实例以及成百上万的Kong网关，这些网关配置错误、在线可访问且未受到攻击保护。 作为API安全不仅关乎网关的问题，我们还分析了驱动API后端的微服务。在对开源容器镜像注册表的调查中，我们发现了一起巨大的数据泄露事件，影响了众多组织，涉及9.31太字节（TB）的数据。被盗数据包括公司机密信息，从第三方系统集成的API密钥到整个代码库——所有这些数据都可供公众下载。 具备增强API安全性的内置功能，云服务已成为可信赖的工具。然而，如同所有技术一样，这些系统并非完全无懈可击。我们发现微软Azure服务中存在关键的安全漏洞，攻击者仅通过一个被篡改的容器即可接管整个集群。 通过本论文，我们旨在为首席技术官（CTOs）、DevOps工程师以及一般员工提供全面的API安全挑战知识及其应对措施。在阐述问题的同时，我们也提供了可操作且实用的步骤来确保API系统的安全性；例如，采用攻击者思维模式，确保安全的身份验证机制到位，引用密钥并避免在任何情况下使用默认密码，即使是在被认为安全的环境中也是如此。我们描述了真实世界的漏洞，帮助您在黑客有机会渗透系统之前预见到其网络犯罪策略。 阅读更多我们的见解 ， 保护您的系统免受这些威胁。 API 网关 一个API网关通常是云原生时代进入公司API生态系统的一个入口。网关通常将传入的流量路由到适当的后端，例如运行在虚拟机集群内部容器中的微服务。然而，API网关提供的功能远不止路由。虽然这提供了更多的功能，但无意间允许不谨慎的用户引入各种配置错误，从而使整个系统变得脆弱。1. 以下是 API 网关的一些其他功能。 授权和身份验证 API网关支持多种身份验证机制，包括多因素认证（MFA），以验证用户或应用程序的身份。此外，网关使用授权方法，如基于角色的访问控制（RBAC）或访问控制列表（ACL），来定义用户可以在特定资源上执行哪些操作。某些功能可以原生支持，而其他功能则可以通过第三方身份提供商支持。必须将网关管理界面包含在范围内。 卸载 卸载是指将安全套接字层（SSL）处理、请求缓存和响应转换等任务委托给API网关，而不是交给后端服务，从而显著减轻了单个服务的压力，并提高了整体系统的性能。 传输层安全 (TLS) 终止 TLS终止于API网关意味着流向API网关的请求是加密的，而发送到后端的请求则以明文形式且可读。 Aggregation API 网关可以聚合多个后端服务的响应，并向客户端提供统一的响应，简化客户端逻辑并减少所需请求的数量。 单点访问 这种集中化可以简化安全管理 ， 作为所有 API 请求的单一入口点。 部署 我们还可以通过部署和配置 API 网关的方式来区分它们。 • 云 - 用作云服务提供商(CSP) 提供的服务• 内部部署 - 自定义配置的第三方 API 网关软件• 混合解决方案 - CSP 提供的 API 网关 ， 用于混合解决方案或自定义配置的第三方 API 网关 每项功能和部署都伴随着相应的风险。在本文中，我们将主要聚焦于企业内部部署和混合API网关。这些网关仍然支持云服务，但并不作为托管服务提供，为用户提供更多的配置选项和应用场景。 风险建模 作为风险示例，我们提供一种配置，在该配置中API网关具有需要API密钥的路由。然而，后端服务根本不进行任何身份验证。 无论是否拥有内部网络中的后端服务访问权限，都不需要进行身份验证。在这种情况下，如果服务在内部网络中可达，配置会使后端服务面临服务器端请求伪造（SSRF）攻击的风险。受攻击的内部设备、容器或服务会为威胁行为者提供免费的访问权限，允许他们执行横向移动攻击。 当涉及到TLS终止时，其一个好处是可以减少发送加密请求、在另一端解密以及卸载后端所需的操作性能开销。然而，这也伴随着代价，即在TLS终止后，密钥将以明文形式传输。如果没有在网络层面采取额外的安全措施，熟练的攻击者可能会尝试拦截数据包并泄露或篡改密钥，例如在可能的情况下发起MITM攻击。用户在本地工作负载中应格外小心。 描述的案例使我们认识到访问控制、TLS以及正确的密钥存储在安全方面的重要性，这一重要性不仅适用于API网关，还适用于整个系统。 曝光 用户将自管理服务部署到云环境中的情况并不罕见。例如，他们会在弹性计算实例中部署API网关，最终将责任从云服务提供商转移给自己。我们使用一家广为人知的云服务提供商的IPv4地址范围进行了研究，并寻找运行在云环境内的API网关及其相关服务的特征。为此，我们选择了两种流行的网关——APISIX和Kong。 APISIX API 网关 API SIX 是基于 NGINX 网络服务器和 OpenResty LUA 扩展框架构建的，这些构成了网关的核心组件。插件扩展了功能并增加了可观测性、安全性和流量控制等特性。可选的仪表板是一个单独的服务，直接与管理 API 进行通信。 APISIX核心处理路由匹配、负载均衡、服务发现、配置管理以及管理API的提供等功能。它还包含一个支持Lua和多种语言插件（例如Go、Java、Python、JavaScript等）的插件运行时。 用户完全拥有配置控制权。安全配置完全由用户负责。不正确的配置是软件部署中最常见的威胁之一，无论是在何处进行部署。 我们评估了APISIX的安全默认设置，并发现管理界面存在一个静态主密码。这使得APISIX网关的默认配置面临风险，因为不了解适当安全措施的用户可能不会被激励去更改密码。这种无意间为威胁行为者敞开了大门，使他们能够轻易访问系统，因为他们已经知道了密码。2 管理API不应向公众暴露，在更安全的部署中，它将受到至少Web应用防火墙（WAF）和其他网络限制（如IP地址限制）的保护——然而，CVE-2022-241124 APIGateway的漏洞使其可以绕过防护；该漏洞与默认密码结合使用，允许威胁行为者成功在网关上执行远程代码执行。 该漏洞影响APISIX 1.3-2.12网关。关键要点是，该漏洞位于IP过滤器中，而非默认主密码。示例强调了更改默认API密钥的重要性，而不仅仅依赖于私有或受限网络隔离。 APISIX 仪表板 API监控仪表盘直接访问管理API，因此当管理API被屏蔽而仪表盘仍然可访问时，用户应格外小心。仪表盘应用程序通过用户名和密码进行保护，这些凭证通常默认设置为“admin”，尤其是在容器化应用中。使用简单的POST请求，我们可以判断仪表盘实例是否使用了默认凭证，因为它会返回一个有效的令牌而不是错误响应。 配置陷阱 正如前面 API 网关用例及其性质所描述的 ， API 网关的安全相关组件是 ： • Secrets management for access upstreets• 令牌颁发和网关身份验证机制以及身份提供商 (IdP) 设置• 测井和机密剥离• 插件和脚本创建 APISIX 没有任何沙盒用于执行 Lua 代码。因此，用户在使用依赖用户提供的 Lua 代码的插件或脚本时应格外小心，因为用户输入可能会引入网关本身的漏洞。例如，通过易受攻击的 Lua 代码处理 HTTP 头。 一个作为公司APIs中央接入点的API网关，在被入侵后成为理想的攻击目标，并且是数据泄露的完美候选对象，可能导致上游配置或身份提供商（IdP）密钥泄露。这将使威胁行为者考虑用户冒充和令牌收割攻击。 秘密管理 APISIX 默认依赖 etcd，这是一个广为人知的 Kubernetes 存储解决方案。默认情况下，配置未进行加密存储，这意味着任何访问 etcd 实例的人都可以读取存储的秘密信息，例如静态 API 密钥。 公开暴露系统数据 在2024年1月进行的Shodan搜索中，发现共有622个独特的IP地址在不同端口运行了API Gateway Service（APISIX）的某些版本。 当我们使用提供的默认秘密检查内容时 ， 至少有 39 个是完全开放的 ， 暴露了敏感数据。 好消息是自 APISIX 3.1 版以来 ，5用户可以使用加密配置插件来存储密钥配置。遗憾的是，这并非默认设置，仍需进行额外配置。 幸运的是，还有其他方式存储密钥；APISIX 支持将密钥存储在金库中并在配置中引用它们。我们强调使用金库来存储密钥。然而，用户应注意他们可能至少需要一个密钥才能访问金库，并确保其安全性。 我们不建议将密钥存储在环境变量中。在之前的研究报告中，我们分析了使用环境变量保存密钥所面临的危险。6环境变量往往被误用，引入了安全问题，正如我们在研究发现中所指出的，暴露容器注册表以显示存储的硬编码密钥，并且这些密钥被发现包含在容器镜像中。 我们承认没有任何系统是100%安全的，即使环境变量也可以以更“安全”的方式使用。然而，这需要完全理解其底层实现，并确保不会跨越任何安全边界。例如，仅在运行时注入（不进行硬编码），并意识到环境变量的默认继承机制。 在将变量传递给子进程时，除了作为另一个安全风险外并无有效的用途，这在我们之前关于使用自定义容器镜像增强Azure无服务器安全性的文章中进一步阐述。7 记录系统活动在排查问题时可能成为救命稻草。它使管理员和开发人员能够模拟并理解问题所在。 然而，过度记录不仅会使存储更快地满载，还会提供额外的攻击面，尤其是因为它会记录敏感信息。通常还会与同行讨论待解决问题并上传日志以寻求咨询。 我们如何知道是否记录了敏感信息 ？ 这个问题的答案取决于多个因素。例如，它是如何传递通过请求的（是在URL内部、HTTP头部还是主体中），活动日志记录得有多详细，当然还有信息的敏感程度。 让我们假设我们在GET请求中传递一个token作为参数。我们的疑问是：这个token是否有效且未过期？它的权限是什么？权限过大且有效期较长的token就像是定时炸弹，随时可能引发问题。8 我们测试了一个默认设置的HTTP日志插件；我们仅配置了HTTP日志服务器URL。所有标头，包括授权标头，默认情况下均已包含。 然而，从安全角度来看这意味着什么？我们可以引用一句名言：“能力越大，责任越大”，因为所有配置完全由用户掌握。首先，我们应该自问以下几个问题：我们要监控什么？我们真的需要记录令牌吗？如果需要，我们能否剥离、替换或提取敏感信息，使其不再对威胁行为者有价值？ 例如，如果我们参考APISIX文档中的一个示例，APISIX提供的示例日志包含的信息较少。正如我们再次证明的那样，依赖默认设置是一种危险的做法。用户应该了解他们正在记录哪些信息以及这些信息的目的。 无论如何，如果出于任何原因我们需要记录敏感信息，我们应该通过确保使用传输层安全（TLS）进行安全传输和保护其存储来保障该信息的安全性。否则，我们将增加敏感信息泄露的风险。 与 APISIX API 网关插件相关的风险 社区插件可能成为巨大的安全漏洞来源，尤其是当它们由不同经验水平的多个实体管理时。在某些情况下，社区插件甚至可能携带着安全问题被集成到产品中。因此，在考虑插件的使用时，不仅应关注其提供的功能，还应关注其安全性。 APISIX 的 API 网关将其插件集划分为多个类别：转换、认证、安全、流量、可观测性和无服务器。每个类别都与不同的风险相关。例如，转换插件的风险与其处理以API请求形式提交的用户输入及其响应相关，并且涉及相关的解析问题。同时，认证插件容易出现不安全的敏感信息存储和错误的验证实现。另一方面，可观测性插件可能会遇到过度记录敏感信息的问题，如前所述。 身份验证插件之一是实现 RFC - 7617 的基本身份验证 ，9使用用户名