深入分析HashiCorp Vault中的身份验证漏洞
发布时间：2022-08-04 11:18:27 所属栏目：安全 来源：互联网
导读：在这篇文章中，我们将为读者深入讲解HashiCorp Vault中的两个身份验证漏洞。实际上，我们不仅会介绍这两个漏洞的利用方法，同时，还会演示如何在云原生软件中找到这种类型的安全漏洞。这两个漏洞(CVE-2020-16250/16251)均已得到了HashiCorp公司的妥善处理，
|
在这篇文章中，我们将为读者深入讲解HashiCorp Vault中的两个身份验证漏洞。实际上，我们不仅会介绍这两个漏洞的利用方法，同时，还会演示如何在“云原生”软件中找到这种类型的安全漏洞。这两个漏洞(CVE-2020-16250/16251)均已得到了HashiCorp公司的妥善处理，并在8月份发布的1.2.5，1.3.8，1.4.4和1.5.1版本Vault中进行了修复。 Vault是一种广泛使用的工具，用于安全地存储、生成和访问API密钥、密码或证书等机密信息。尽管它也能够用作人类用户的共享密码管理器，但是它的功能却主要是针对基于API的访问进行优化的。Vault的应用场景包括为某些服务（Web服务器、数据库或第三方资源（如AWS S3 bucket）等）提供临时的登录凭据。 使用像Vault这样的中心化机密信息存储设施能够带来许多安全优势，例如集中审计，强制凭证轮换或加密数据存储。然而，对于攻击者来说，中心化的机密信息存储也是一个非常值得关注的攻击目标——一旦得手，攻击者就能访问各种重要的机密信息，从而可以访问大部分的目标基础设施。 在深入研究这些漏洞的技术细节之前，下一节将概述Vault的身份验证架构及其与云提供商集成的方式。熟悉Vault的读者可以跳过本节。 以这种方式使用Vault有一些不错的安全优势：lambda函数本身不需要包含引导凭证，而且每次访问数据库的凭证都是可以审计的。轮换旧的或被破坏的数据库凭证非常简单，并且可以集中执行。 然而，这种操作上的简单性，完全是将复杂性隐藏在AWS iam auth方法中结果。那么，/v1/auth/aws/login API端点究竟是如何工作的，未经认证的攻击者是否有办法冒充随机的AWS IAM角色呢？ sts:GetCallerIdentity 在其内部，Vault的aws auth方法支持两种不同的认证机制：iam和ec2。在这里，我们感兴趣的是iam，我们之前的Lambda示例中曾用过该机制。Iam认证机制是建立在名为GetCallerIdentity的AWS API方法之上的，它是AWS安全令牌服务（STS）的一部分。 顾名思义，GetCallerIdentity将返回IAM角色或用户的详细信息，其凭证被用于调用API。要了解Vault如何使用该方法对客户进行身份验证，我们需要了解AWS API如何进行身份验证的。 AWS不是将某种形式的身份验证令牌或凭据附加到API请求中，而是要求客户端使用调用者的秘密访问密钥为(规范化的)请求计算HMAC签名，并将此签名附加到请求中。这种机制使得预先对请求进行签名并将其转发给另一方，从而实现一定程度的身份冒充成为可能。一个流行的用例是，赋予客户端S3的文件上传权限，而无需授予他们访问具有写权限的凭据的权限。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号