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

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