暴露的 OPA 服务器可以泄漏应用程序的哪些信息

本文会介绍 OPA 以及它的用途，并结合已发现的案例来说明通过 Shodan 识别 389 个暴露的 OPA 服务器后发现了什么，以及暴露的 OPA 如何对用户的应用程序的整体安全性产生哪些负面影响。

今年早些时候，趋势科技发布了一份关于通过 Shodan 发现 243469 个暴露暴露的 Kubernetes 节点的报告。另外，研究人员还发现了 389 个易受攻击的开放策略代理 (OPA) 服务器。 OPA 是一个开源的云本地计算基金会 (CNCF) 项目，使用 Go 编程语言开发，目前已被用作许多策略执行工具的主引擎，迄今为止下载量超过 1.3 亿次。它使用称为 Rego 的特定声明性策略语言来设计其策略。 OPA 可用于各种系统和环境，例如 Kubernetes、微服务、API 网关和其他云本地工具。如果OPA服务器不受保护，它们的策略可能会泄露敏感的应用程序信息，包括用户配置文件和正在使用的服务。这些暴露的策略还可能无意中泄露关于系统应该如何工作的信息，以绕过对已实现策略的限制，攻击者可以利用这些限制进行攻击。

OPA 架构概述

这篇文章讨论了研究人员在通过 Shodan 识别出数百个暴露的 OPA 服务器后发现的问题，以及暴露的 OPA 如何对你的应用程序的整体安全性产生负面影响。

策略即代码（Policy As Code）的需求

Policy As Code本质上都是让原来对 Policy 描述抽象成代码，从而拥有代码的特性（复用性、抽象性、可执行、可测试、版本化等），以此来获得更高层次的抽象。

在当今包含 sprint、scrum、container、DevOps 和 DevSecOps 以及云的运行环境中，如果不使用自动化，网络、安全和合规团队很难跟上开发团队和业务需求。这就是为什么基础设施即代码 (IaC)、GitOps 和安全即代码 (SaC) 等方法在保护云环境和微服务方面变得必不可少的原因。所有这些方法共同实现云安全，目的就是帮助在流程和部署开始时集成安全性，以防止威胁和风险。

但是合规性呢？你如何检查、执行和持续监控你的系统，以确保它们遵循安全最佳实践并遵守最新的安全标准，例如支付卡行业数据安全标准 (PCI-DSS)、健康保险流通与责任法案(HIPAA)，以及系统和组织控制 (SOC 2)？这就是策略即代码发挥作用的地方，可以显着帮助加快合规性创建、自动化和验证过程。

策略即代码（或合规性即代码）已成为实施、管理和跟踪系统策略更改并确保它们在云本地系统 4C 中应用和实施的好方法：代码、容器、集群和云。

使用与 IaC 和 SaC 类似的方法，策略即代码使用软件开发中已经使用的所有出色工具和技术来解决合规性问题。一方面，策略以特定文件格式（如 JSON 或 YAML）或使用特定编程语言（如 Python 或 Rego）创建和存储。这些存储在 Git 存储库中，用于版本控制、跟踪和可审计性。这样，组织可以在发生更改时在这些存储库上开发和触发管道和自动化。策略即代码可以在代码审查、自动化测试以及持续集成和交付 (CI/CD) 管道中以编程方式实施，确保更改在到达生产系统之前得到适当的验证和测试。 OPA 是可用于策略即代码流程的领先开源工具之一。它可用于网络上的许多不同应用程序和系统。尽管如此，它的主要采集者之一是 Kubernetes 集群的准入控制器，其中它的Gatekeeper版本作为任何试图在集群中运行的容器的安全器。

Shodan 上暴露的服务器

在分析暴露的云本地工具，特别是暴露暴露的 kubelet 时，研究人员还通过 Shodan 发现了近 400 个暴露在 8181 端口上的 OPA 服务器，而且这个数字在过去几个月中一直在增加。端口 8181 是 OPA 服务器的默认端口，它们都具有可用于未经身份验证和未经授权的请求的 API 端点。根据研究人员的 Shodan 搜索，美国、韩国和德国是暴露 OPA 数量最多的前三个国家。

研究人员使用列表策略端点来收集有关该实例中安装的所有策略模块的信息，如官方 OPA 文档中所示。然后，研究人员查询了每 389 个开放的 OPA 服务器，以识别、收集和分析它们可以通过其策略模块信息暴露的敏感信息类型。研究人员主要关注 Policy API 来列出策略和分析数据。

首先，研究人员通过查询 /v1/config/ 端点来分析安装在这些服务器上的 OPA 的版本。如下图所示，大多数暴露的服务器都使用过时的 OPA 版本，例如 0.34.2。在撰写本文时，最新的 OPA 版本是 0.43.0。

根据在 Shodan 上找到的数据，暴露的 OPA 服务器数量及其版本

在上图中，研究人员可以看到通过 Shodan 找到的一个暴露 OPA 服务器的示例。除了能够通过此页面查询服务器之外，如果用户输入数据没有得到适当的清理和验证，它还可以作为命令注入攻击的入口点。还有 REST API 被暴露和未经身份验证的问题。

在 Shodan 上发现了一个过时 (0.29.3) 和暴露的 OPA 服务器的示例。截至撰写本文时，此 OPA 服务器的最新版本为 0.43。

同时，这是对该暴露服务器的 /v1/policies 端点发出 GET 请求的结果：

从暴露的 OPA 服务器访问列表策略 (/v1/policies) 端点以列出所有可用策略

在美化生成的policy.json文件并分析其内容后，研究人员从policy文件本身中发现了一些特殊的信息：

在这个暴露的 OPA 服务器上有五个可用的规则，其 ID 提供了有关其用途的线索；

"systems/ea2c8e2dbfa748608077be0d6fd45369/rules/rules.rego" ；
"systems/ea2c8e2dbfa748608077be0d6fd45369/test/test.rego" ；
"systems/ea2c8e2dbfa748608077be0d6fd45369/product/manager/ rules/rules.rego" ；
"systems/ea2c8e2dbfa748608077be0d6fd45369/product/rules/rules.rego" ；
"systems/ea2c8e2dbfa748608077be0d6fd45369/backoffice/rules/rules.rego"；

第一条规则是默认规则，默认返回值设置为 false。第二条规则是测试规则；

研究人员可以访问此暴露的 OPA 服务器上可用的所有策略，这些策略可以以原始和抽象语法树 (AST) 格式访问；

一些规则可以揭示内部应用程序角色，例如“发布者”和“编辑者”；

一些 base64 编码的数据转换为“助手”。

分析暴露的OPA策略

在从所有这些暴露的 OPA 服务器收集和分析了近 400 条策略之后，研究人员能够找到以下信息：

这些策略中至少有33%的策略包含与应用程序相关的某种敏感信息，包括用户配置文件、正在使用的服务，以及将通过 Amazon Web Services (AWS) API 网关触发 API 的 URL，甚至是一些内部系统 URL。

这些策略中有 91% 包含有关系统应如何运行以绕过基于已实施策略的某些限制的某种信息。

在收集的 OPA 策略中找到的相关和敏感信息的百分比

以下是一些服务和 URL 示例，仅通过查看策略和它们为未经身份验证的请求提供的输出即可找到：

仅通过查看 OPA 策略即可找到的服务和 URL 示例

通过适当的请求或令牌，攻击者可以获得有关这些服务的更多信息，并寻找漏洞或其他入口点以进入组织的系统。研究人员强烈建议目前将 OPA 用作其策略即代码解决方案的公司，以确保他们不会无意中在线暴露其 API 和策略。在某些情况下，公司可能会在没有意识到的情况下使用 OPA，Kubernetes 托管服务的多个提供商依赖 OPA 来执行策略。

出于安全考虑，研究人员仅从 REST API 查询列表策略端点。但是，还有许多其他可用的端点和方法，它们不仅列出了敏感信息，而且还允许攻击者编辑甚至删除暴露的OPA服务器中的数据和对象。其中包括：

所有这些都可以在 OPA REST API 文档中找到。

保护 OPA 服务器

首先，OPA 服务器不应该暴露在互联网上。因此，有必要限制该访问，以避免任何人通过 REST API 绕过你的 OPA 配置。对于授权用例，OPA部署的标准模式是让OPA与请求它做出决策的应用程序运行在同一台设备上。这样，组织就不需要将 OPA 暴露给互联网或内部网络，因为通信是通过 localhost 接口执行的。此外，以这种方式部署 OPA 意味着组织通常不需要为 REST API 启用身份验证/授权，因为只有在同一台设备上运行的进程才能查询 OPA 实例。为此，可以使用“opa run --addr localhost:8181”启动 OPA，使其仅绑定到 localhost 接口。

其次，当使用策略即代码工具(如OPA)时，在源代码管理(SCM)系统等位置保护策略是很重要的。通过分支保护和代码所有者等特性，拥有适当的访问控制来监视可以更改这些策略中的哪些内容也是至关重要的。有了SCM系统的强大功能，组织可以创建对这些策略的任何更改的更精简的审查和批准过程，确保源代码中的任何内容也反映在生产OPA服务器中。

TLS 和 HTTPS

如上所述，在 Shodan 上发现的这些暴露的 OPA 服务器中的大多数都没有使用任何类型的通信加密，因为默认情况下没有启用这种加密。要配置 TLS 和 HTTPS，系统管理员需要创建证书和私钥，并提供以下命令行标志：

TLS 证书的路径：--tls-cert-file=

TLS 私钥的路径：--tls-private-key-file=

有关此过程的最新信息，请参阅有关 TLS 和 HTTPS 的 OPA 文档。

身份验证和授权

默认情况下，OPA 身份验证和授权机制是关闭的。这在 OPA 的官方文档中有所描述，系统管理员和 DevOps 工程师在安装后立即启用这些机制至关重要。

根据 OPA 文档，这两种机制都可以通过以下命令行标志进行配置：

身份验证：--authentication=

这可以是不记名令牌 (--authentication=token) 或客户端 TLS 证书 (--authentication=tls)。

授权：--authorization=

这使用 Rego 策略来决定谁可以在 OPA 中做什么。它可以通过在 OPA 启动期间设置 --authorization=basic 标志并提供最小授权策略来启用。

有关此过程的更多详细信息，请参阅 OPA 关于身份验证和授权的官方文档。

云安全建议

Kubernetes 是开发人员中最受欢迎的平台之一，其高采用率证明了这一点，并且没有任何很快放缓的迹象。随着用户基础的不断扩大，Kubernetes的部署需要确保安全，免受威胁和风险。为此，开发人员可以将策略作为代码工具，它可以帮助以自动化的方式实现控制和验证过程。

除了努力应用一些基本的内务管理规则来保证 Kubernetes 集群的安全之外，组织还可以使用特定于云的安全解决方案。