云环境下的隐藏管理员威胁：需要重点注意的10个权限
导语：全世界的组织都在向云端迁移，而这种迁移正在造成影子管理员的威胁。本文介绍我们的一些发现以及开发的工具，这些工具是帮助检测和减轻云端影子管理员日益增长的威胁。
全世界的组织都在向云端迁移，而这种迁移正在造成影子管理员的威胁。on-premises影子管理员帐户具有敏感特权，通常被忽略，因为它们不是特权活动目录(AD)组的成员。相反，它们通过直接分配权限(在AD对象上使用ACL)获得特权。
虽然流氓管理员和恶意行为者采用的在on-premises网络上升级特权的隐秘技术已经被清楚的记录下来，但是仍然存在一些关于云环境的不确定性。
在RSA会议上，CyberArk实验室公布了关于云环境下影子管理员造成的威胁的一项新的研究。这次会议进行的很顺利，并被ThreatPost报道了。
本文将讲述我们的一些发现以及开发的工具，这些工具是帮助检测和减轻云端影子管理员日益增长的威胁。我们研究了10种不同类型的权限，潜在的攻击者可以滥用这些权限来升级特权并控制整个云环境。
作为研究的一部分，我们开发了一个免费的云安全工具SkyArk，以帮助检测和减轻云影子管理员造成的日益增加的威胁:https://github.com/cyberark/SkyArk。
所需的范式转换
攻击者可能会发现并滥用一些复杂的、可能是“有限”的权限，从而升级他们的特权，成为完全的云管理员。它们还可以很容易地使用这些权限来一直隐藏本来就比较隐蔽的影子实体，直到影子账号被用作允许访问网络的后门帐户。
这在任何数量的云平台上都是可能的。为了我们的研究目的，我们将使用Amazon Web Services (AWS)作为一个示例。AWS的完整和最终管理员权限是通过将众所周知的“管理员访问”权限策略分配给所选的管理实体来实现的。
图1 “管理员访问”权限策略——允许完全的管理员权限。
任何具有“管理员访问”策略的实体都有权对每个目标资源(“资源”:“*”)执行任何操作(“操作”:“*”)。然而，在我们的研究中，我们发现了另外10种许可，它们授予指定实体完全相同的管理权限。
这些敏感的权限看起来普通，乍一看好像他们并没有特权，所以使得组织低估了这些账户的敏感性。因此，组织将忽略掉他们在这些帐户上放置了相同的安全控制，从而使影子账户成为标准的、完整的管理员访问实体。这种意识上的不足为潜在的攻击者创造了机会。
组织机构不能再将更知名的管理员访问实体设置成唯一的特权实体。在考虑要赋予特权的实体上，需要进行范式转换。
更隐秘的管理员
让我们看看以下权限策略:
图2 “有限”权限策略
乍一看，图2中的策略看起来像一个有限且受限的策略，因为该策略只允许8个操作，而其中的6个是只读操作(Get+List)。
但是，注意其他两个权限- CreatePolicyVersion和SetDefaultPolicyVersion是很重要的。实际上是通过这两个权限授予指定实体和潜在的攻击者这些权限，使他们能够将当前的“有限”权限升级到完全的管理权限——就像其他完全特权的“管理员访问”策略一样。这是因为AWS的每个权限策略都可以同时拥有五个策略版本，这是一个很好的并且非常有用的特性，例如，如果您更新了一个特定的策略并遇到了一些错误。在这种情况下，您可以轻松地切换回策略的先前版本。
具有上述权限策略的实体可以为其现有的分配策略创建新的策略版本，使用API调用CreatePolicyVersion和SetDefaultPolicyVersion。然后，在创建新策略版本之后，实体可以选择应用它并授予自身管理员访问权限。
因此，攻击这种实体的潜在的攻击者会在目标环境中执行其所有的恶意操作。此外，执行完恶意活动后，攻击者可以将权限策略版本转换回原始版本，从而使其看起来是没有异样。
下面是一个演示上述场景的快速视频截图和链接:
如上述场景，有权限修改策略版本的云环境中的实体，必须被视为是享有特权的。组织也需要考虑这些实体是否真的有必要需要这种敏感的权限。防御团队必须确保这些具有特权的实体拥有强大的、频繁旋转和安全的存储凭据、启用多因素身份验证和密切监视的安全保护。
作为第二个例子，让我们来看看下面的策略:
图3 “有限”DevOps用户权限策略的示例
乍一看，这可能看起来像DevOps用户经常使用的有限策略。此策略只允许与EC2实例相关的四个API调用，并且也可以看到策略的指定实体不能删除其他EC2实例。
然而，一个潜在的攻击者渗透到组织中，还没有获得AWS环境的完全管理权限，但是，他们可以使用具有上述策略实体的凭据来创建新的特权实例配置文件。攻击者可以使用新的特权实例配置文件，创建并将拥有特权的角色附加到他可能已经访问的EC2实例之一上。从这个实例中，攻击者可以承担整个管理角色并控制整个AWS环境。
下面是一个演示此攻击场景的快速视频截图和链接:
如果使用，需要注意并保护的10个权限
我们的研究发现了10个敏感的身份和访问管理(IAM)权限，这些权限可以被攻击者利用建立隐秘的影子管理员。以下是详细的清单:
1.CreateAccessKey
使用CreateAccessKey操作的权限是理解云影子管理员概念的一个很好的例子。使用CreateAccessKey IAM API权限的攻击者可以滥用它来为另一个IAM管理帐户创建一个新的访问密钥。为了响应这个API调用，攻击者将被提供新创建的访问密钥。
图4 具有此权限策略的实体将是影子管理员
具有上述策略的实体(用户/组/角色)与其他具有“AdministratorAccess(管理员访问权限)”权限的完整管理用户一样强大。仅使用图4中的策略攻击一个账户，攻击者就会获得新的特权访问密钥，并继续代表目标用户在环境中执行恶意操作，该目标用户就是攻击者刚刚为其创建了一个新的访问密钥的用户。
2.CreateLoginProfile
有了这个权限，攻击者就可以拥有一个只有API访问密钥的特权实体(就像IAM实体，它不是针对人类的，而是用于应用程序的API自动使用)。然后，攻击者可以添加一个新的基于密码的登录配置文件，为该实体设置一个新密码，模拟它并代表被攻击的用户执行恶意操作。
3.UpdateLoginProfile
此权限为潜在攻击者提供重置其他IAM用户登录密码的权限。
4.AttachUserPolicy、AttachGroupPolicy或AttachRolePolicy
利用包含这些权限的策略，攻击者可以将现有的管理策略附加到他当前拥有的任何其他实体上。
5.PutUserPolicy、PutGroupPolicy或PutRolePolicy
这些权限允许攻击者向其他实体添加“内联”策略，而不是“管理策略”。内联策略是一种嵌入到主体实体(用户、组或角色)的策略。因此，当您删除一个实体时，它的嵌入式内联策略也会被删除。攻击者定义的新添加的内联策略将允许攻击者向先前被攻击的实体授予额外的特权。
6.CreatePolicy
使用此权限，攻击者可以添加一个隐形的管理策略，并将其称为“ReadOnly”策略，使其看起来无害。
7.AddUserToGroup
通过这个权限，攻击者可以将他当前拥有的用户直接添加到组织的管理组中。
8.UpdateAssumeRolePolicy
每个角色都有一个定义谁可以承担该角色的策略。这通常被称为“角色信任策略”。使用此权限，攻击者可以更改具有特权角色的假定权限，然后以非特权帐户进行假定权限。
9.CreatePolicyVersion、SetDefaultPolicyVersion
与我们的第一个示例一样，使用“CreatePolicyVersion”和“SetDefaultPolicyVersion”的权限，攻击者可以更改客户管理的策略，并将一个非特权实体更改为特权实体。
10.PassRole CreateInstanceProfile / AddRoleToInstanceProfile
与我们的第二个示例类似，通过这些权限修改实例配置文件，攻击者可以创建一个新的特权实例配置文件，并将其附加到他所拥有的已被攻击的EC2实例上。
SkyArk：一个新的，免费的工具，用于节制云影子管理员
在GitHub上可以获得，SkyArk是一个开源的云安全工具，可以用来公开云影子管理员和保护云特权实体。
它有两个有用的子模块——AWStealth和 AWStrace。AWStealth可用于在扫描的AWS环境中发现最具有特权的实体，包括云影子管理员。AWStrace分析AWS CloudTrail日志，并优先考虑潜在的云影子管理攻击者可能使用的风险敏感的IAM操作。
我们鼓励组织使用SkyArk来发现他们最重要的拥有AWS特权的实体，并确保这些实体的安全。记住，攻击者正在寻找那些特权实体，所以时机真的很重要。