Unit42的安全研究人员近期发现了一种针对云端环境的勒索软件活动,该活动当前已成功入侵了多个组织的云端环境。该恶意活动利用暴露的环境变量文件(.env文件)实现此目的,这些文件包含敏感变量,例如属于各种应用程序的凭据。
在这些受影响组织中,都出现的安全问题包括:
1、公开暴露环境变量;
2、使用长期有效的凭证;
3、缺乏最小特权架构;
该活动在各个组织的亚马逊网络服务 (AWS) 环境中建立了攻击基础设施,并利用该基础设施扫描了超过 2.3 亿个唯一目标以获取敏感信息。
此次攻击活动针对了 11万个域名,最终通过.env文件收集了超过 9万个唯一变量。在这些变量中,7000 个属于目标组织的云服务,我们将其中的1500个变量追溯到社交媒体帐户。此外,威胁行为者还使用多个源网络来促进此次攻击。
研究发现,威胁行为者在这次勒索活动中使用了以下手段:
1、Tor网络执行网络侦察和初始访问操作;
2、虚拟专用网络(VPN)实现横向移动并执行数据泄露;
3、用于该活动其他方面的虚拟专用服务器 ( VPS ) 节点;
此次攻击活动中,威胁行为者成功勒索了云存储容器中托管的数据。威胁行为者并未在勒索前加密数据,而是窃取了数据并将勒索信放在了受感染的云存储容器中。
此外,此次活动背后的威胁行为者可能利用了广泛的自动化技术来成功快速地开展行动。这表明这些威胁行为者团体既熟练又精通先进的云架构流程和技术。
请注意,威胁行为者的成功依赖于目标组织的错误配置,这些错误配置无意中暴露了他们的.env文件。它不是由云提供商服务中的漏洞或错误配置造成的。
本文将披露一起针对云环境、利用云平台动态可扩展性的勒索行为。该行为还利用多种云服务成功勒索组织的云数据。
本文讨论的事件发生在云环境中,账户运营者部署并使用了过于宽松的 IAM 凭证。这些凭证允许威胁行为者执行多项操作,如果账户运营者遵循云安全最佳实践,这些操作是不可能实现的。
威胁行为者通过受害组织 Web 应用程序中暴露的环境文件 ( .env ) 文件获得了对威胁行为者云环境的初始访问权限。由于存储在.env文件中的身份验证数据存在安全风险,组织应遵循最佳安全做法,绝不公开暴露环境文件。
环境文件允许用户定义应用程序和平台中使用的配置变量。这些文件通常包含机密信息,例如硬编码的云提供商访问密钥、软件即服务 (SaaS) API 密钥和数据库登录信息等,然后威胁行为者会使用这些机密信息进行初始访问。
扫描互联网上的域名并从暴露的环境变量文件中获得凭据的攻击模式实际上遵循了一种更大的模式,我们认为这种模式会通过其他受损的 AWS 环境传播。
注意:这些机密信息的存在是由于受害组织的错误配置导致其.env文件无意中暴露。所列供应商的应用程序或服务均不存在导致此暴露的漏洞或错误配置。
本文讨论的活动源于从可公开访问的.env文件获得的 AWS 身份和访问管理 (IAM)访问密钥被泄露。威胁行为者通过扫描和识别托管在不安全 Web 应用程序上的暴露.env文件来找到这些访问密钥。一旦威胁行为者识别出暴露的访问密钥,他们就会使用这些密钥访问托管云环境。
此特定威胁最常见的初始访问媒介是组织无意中错误配置服务器,随后将敏感文件暴露给公共互联网,其中最常暴露的文件是.env文件。
此活动背后的威胁行为者执行了各种用于扫描和识别的 API 调用,以了解有关环境的更多信息并选择要利用的服务。这些发现操作针对以下各种服务:
1、身份和访问管理 (IAM);
2、安全令牌服务 (STS);
3、简单存储服务 (S3);
4、简单电子邮件服务 (SES);
研究人员发现威胁行为者会利用上述服务中的缺陷,并试图扩大其对组织云环境的控制。在该活动的扫描识别阶段,每次操作开始时,威胁行为者都会调用GetCallerIdentity API 来验证分配给暴露 IAM 凭证的用户或角色身份。GetCallerIdentity是whoami的 AWS 版本,它能够返回有关用于发起请求的主体 IAM 凭证(关联的用户 ID、AWS 帐号和Amazon 资源名称 (ARN) )的信息,如下图所示:
其中,AWS UserID 是执行调用的实体的唯一标识符,AWS Account是 UserID 所属的 AWS 帐户的唯一 12 位标识符。ARN 包括执行调用的主体的 AWS 帐号和名称,每个云资源在 AWS 账户内都有一个唯一的 ARN。
ARN 声明了以下信息:
1、与之关联的 AWS 服务;
2、托管 AWS 资源的区域,但对于 IAM 等全球服务,该区域留空;
3、它所在的 AWS 账户;
4、与此 IAM 凭证关联的 IAM 资源类型(例如用户、角色或组);
威胁行为者还会尝试调用ListUsers API 请求来收集 AWS 账户中的 IAM 用户列表,以及ListBuckets API 请求来识别所有现有的 S3 存储桶。这些操作能够让威胁行为者进一步了解哪些 IAM 用户可用,他们可以利用这些用户进行未来的横向移动,并为数据泄露目标提供了 S3 存储桶名称。
然后,威胁行为者会通过以下 API 调用成功对 AWS SES 执行了更广泛的扫描和识别操作:
GetSendQuota
ListVerifiedEmailAddresses
GetAccountSendingEnabled
GetAccount
ListIdentities
威胁行为者在执行完扫描和识别操作之后,有可能会发现用于获取云环境初始访问权限的原始 IAM 凭证不具有所有云资源的管理员访问权限。此时,威胁行为者就机会通过创建具有无限制访问权限的新 IAM 资源,成功提升了其在受害云环境中的权限。
为了实现此目的,他们首先使用CreateRole API 请求创建了一个名为lambda-ex的 IAM 角色,然后调用AttachRolePolicy API 将 AWS 管理的AdministratorAccess策略附加到新创建的lambda-ex角色,如下图所示:
这两个 IAM 事件导致在受感染的 AWS 账户中出现了一个具有管理权限的新 IAM 角色,从而完成了威胁行为者的攻击特权升级部分。
成功创建特权 IAM 角色后,威胁行为者尝试创建两个不同的基础设施技术栈,一个使用Amazon Elastic Cloud Compute (EC2) 资源,另一个使用 AWS Lambda。通过执行这些执行策略,威胁行为者虽然无法创建安全组、密钥对和 EC2 实例,但他们能够成功创建多个附加了新创建 IAM 角色的 lambda 函数。接下来,威胁行为者会试图根据实例的大小创建新的 EC2 资源以用于加密货币挖矿,或创建新的Lambda函数为其执行自动扫描操作。
EC2 创建失败
在这些失败的操作中,威胁行为者首先会尝试执行CreateSecurityGroup API 调用并将组命名为security。然后,他们会运行AuthorizeSecurityGroupIngress来创建一条入口规则,并允许来自任何 IP 地址 ( 0.0.0.0/0 ) 的所有端口 ( 0 - 65535 )。
所有这些操作都在一分钟内完成,表明这是预先编写的自动化活动。然而,由于与受感染的 IAM 用户相关的权限有限,因此这些操作失败了。
成功创建 Lambda 函数
在 EC2 服务操作失败后,威胁行为者会转向到AWS Lambda 服务(一种基于云的无服务器计算服务),他们在其中使用从公开的 IAM 凭证获得的授予权限。他们的第一个操作使用AWS 区域 us-east-1中的CreateFunction20150331 API 调用创建了一个新的 lambda 函数,该函数会创建了一个名为ex的新 lambda 函数。
一旦威胁行为者成功创建了第一个 lambda 函数,他们就会在一秒钟内自动将同一个 lambda 函数部署到账户中每个其他启用的区域中。作为默认 lambda 函数创建过程的一部分,附加到 lambda 函数的角色会自动执行CreateLogGroup API 调用,然后执行CreateLogStream,从而开始记录所有 lambda 函数操作的过程。
CreateLogGroup事件会创建一个新的CloudWatch日志组,其中包含新创建的 lambda /aws/lambda/ex的名称。日志组中的每个日志流按日期汇总各种 lambda 运行信息。这使我们能够成功跟踪威胁行为者使用他们创建的 lambda 函数ex的操作。值得注意的是,lambda 函数的日志记录创建过程是自动化的,威胁行为者无法关闭它。
威胁行为者利用窃取的 IAM 用户凭证创建了一个恶意 lambda 函数。Unit 42 逆向工程团队分析了该恶意 lambda 函数,该函数由一个 bash 脚本组成,该脚本配置为使用包含数百万个域和 IP 地址的一组预配置源执行全互联网扫描。下图显示了 lambda 函数的完整代码:
下图显示了威胁行为者用于扫描和检索.env文件中暴露的身份验证凭据的架构设计:
在我们对威胁行为者的公共 S3 存储桶进行分析时,进一步证明了对自动化的严重依赖。我们发现威胁行为者正在扫描超过 2.3 亿个唯一目标,以查找配置错误和暴露的环境文件。下图显示了威胁行为者的公共存储桶的内容,列出了配置的目标数量:
在访问此公共 S3 存储桶时,我们估计有多个被盗用的 AWS 账户是此恶意扫描的目标,这是一次“入侵-扫描-入侵”自动化操作的一部分。
威胁行为者还会通过使用S3 Browser工具从 S3 存储桶进行数据泄露操作。此工具在使用时会生成各种 S3 API 调用。这些事件显示了威胁行为者与哪些 S3 存储桶进行了交互。这些 API 调用包括:
ListBuckets
GetBucketLocation
GetBucketObjectLockConfiguration
GetBucketLogging
GetBucketVersioning
GetBucketRequestPayment
GetAccelerateConfiguration
GetBucketReplication
GetBucketLifecycle
GetBucketPublicAccessBlock
GetBucketOwnershipControls
GetBucketAcl
请注意,如果 S3 存储桶未启用对象级日志记录,则成本和使用情况报告可以提供一种方法来确定 S3 浏览器活动是否导致数据泄露。
在威胁行为者成功从目标威胁行为者的 S3 存储桶中窃取并删除 S3 对象后,他们将勒索信上传到现在空的存储桶中。勒索信通常是勒索过程的最后一步,旨在恐吓威胁行为者并迫使其支付通常数额巨大的赎金。威胁行为者支付赎金表面上是为了防止威胁行为者在暗网上出售或泄露被盗数据,并希望找回被删除的数据。
下图所示的是威胁行为者留下的勒索信息:
在大多数此类攻击中,威胁行为者获得了长期 IAM 访问密钥,使他们能够进入控制后台,而其凭证不受时间限制,因此使用临时凭证会是一种解决方案。
防止这些攻击的另一种方法是在配置权限时遵循最小特权原则。限制与 IAM 资源关联的权限会限制受损凭证可以执行的操作范围(例如,限制可以执行iam:CreateRole和iam:AttachRolePolicy的身份)。这样,即使威胁行为者成功获得长期或短期凭证的访问权限,他们也没有足够的权限来执行恶意操作。
此外,禁用 AWS 账户内所有未使用的区域也可以防范这些攻击。威胁行为者在多个区域部署资源以试图不被发现,因此禁用所有未使用的区域可以防止威胁行为者隐藏其攻击。
最后,启用日志记录和建立监控流程对于保护组织的资源至关重要。AWS 的 GuardDuty 提供了基本级别的警报,但每个组织都应检查他们使用的服务以及异常活动可能如何出现在日志中。从那里,组织应该为异常活动创建警报。
本文分析了一次大规模勒索活动,该活动成功入侵了多个云环境,勒索活动中使用的初始访问权限直接源于受害组织 Web 应用程序中暴露的环境文件 ( .env ) 文件。通过瞄准.env文件,威胁行为者能够收集至少 11万个域的暴露环境文件。我们发现了超过 9万个泄露的唯一环境变量,其中 7000 个与云服务相关,1500 个与社交媒体帐户相关,通常包括帐户名称和身份验证密钥。
入侵威胁指标IoC
原文始发于微信公众号(FreeBuf):云端安全 | 泄露的环境变量如何导致云环境遭受大规模勒索软件威胁
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论