CyberArk 对发生于 2022 年 1 月的 Okta 遭入侵事件的观点

April 28, 2022 CyberArk Blog Team

CyberArk Perspectives on Okta Breach

主流身份和访问管理供应商 Okta 已证实其于 2022 年 1 月在通过第三方支持工程师的机器发起的一次有针对性的网络攻击中遭受入侵。3 月 22 日，在犯罪集团 Lapsus$ 在线上分享截图后，该证实信息发布。在此之前，还发生了涉及同一威胁行为体的另一起广受关注的事件。
这一事件的发生令人警醒，它意味着我们都是此类威胁的目标，无一例外——不存在简单解决办法。没有任何一家公司、解决方案或技术能够独立地阻止攻击者花样百出的新招数。作为网络卫士，我们必须在事件发生时公开并迅速地进行沟通，记住，安全是一项“团体运动”，然后，我们需要以肩负共同使命以及安全优先的心态携手面对此类威胁。
下文概述了到目前为止对此事件的情况说明，以及在身份提供商 (IdP)（无论您使用的是哪一家）被入侵后，您需要采取的一些实际步骤。

针对 Okta 漏洞的简要回顾

威胁行为体在 2022 年 1 月入侵了 Okta 第三方支持工程师的终端，并获得了 Okta 客户数据的访问权限。该问题很快被发现，但直到 2022 年 3 月 22 日 Lapsus$ 在网上发布截图后，事件才得以公开。Okta 随后证实了此次入侵。使用 Okta 进行单点登录和作为身份提供商的客户可能会受到此事件的影响。
Lapsus$ 犯罪集团因其目标之高调和非常规的手段而迅速变得臭名昭著。虽然潜在动机和整体损失情况尚不明确，但有两件事是可以确定的：身份入侵在这些事件中占据主导作用，而受害的主流科技公司并不是此类攻击唯一的预期目标。在 Okta 事件中， Lapsus$ 明确表示，其实际目标是 Okta 的客户。

随着恶意网络活动的增加，每一个组织都迫切需要主动承担漏洞，强化自身系统并做好迎战潜在攻击的准备，无论这些攻击是直接针对贵组织还是在最初时影响第三方提供商。
身份提供商应被视为第 0 层资产，并受到相应保护。如果贵组织的身份提供商遭受入侵，或者您怀疑其已经遭受入侵，那么应立即采取以下四个步骤，以最大程度地减少暴露和影响。

知晓或怀疑身份提供商已遭到入侵后，您应立即采取的 4 个步骤

第 1 步：细致检查（从报告的攻击日期以来）所做的配置更改。.一项简单的配置更改，即可切换整个身份验证流，并为攻击者提供持久性访问权限。请留意以下具体的入侵指标：

任何新的 MFA 设备部署或设备变更。
MFA 设置变更：例如，威胁行为体可以通过盗用身份和用户密码来禁用某些应用程序的 MFA，在绕过 MFA 的同时获得对这些应用程序的完全访问权限。
身份提供商 (IdP) 配置变更：若 URI（SSO 解决方案和 IdP 之间的连接）和相关配置发生变更，即便用户的密码发生更改，威胁行为体也可获得对应用程序和服务的持久访问。
密码和 MFA 重置尝试（尤其是针对特权帐户和管理帐户）。假设所有密码重置尝试（无论其成功与否）均可疑，并重置所有密码。
权限和角色变更以及新用户的创建。如果您的 IdP 解决方案提供基于风险的访问和基于异常访问的风险评分机制，请对系统中的所有高风险事件和高风险用户进行评估。比如，这些事件或许是通过 IP、位置、设备或不可能的旅行进行异常访问的结果。在目标应用程序自身中查找这些变化也很重要。检测在这些应用程序中所创建的，允许直接登录到这些目标应用程序的影子管理员可能更为困难。如果贵组织采用了身份治理和管理 (IGA) 平台，那么，现在是使用它进行认证练习的最佳时机。

第 2 步：查找任何无法识别或恶意的应用程序。如果威胁行为体可访问 SSO 平台，那么就能够添加恶意应用程序，或替换现有的应用程序，从而伪装成合法应用程序。应该为新添加的应用程序实施一个治理流程，例如批准流程或向多个管理员发送通知。恶意应用程序可能会在获得用户同意后滥用分配给它们的权限。例如，恶意应用程序可能会请求读取 Outlook 上的电子邮件或访问基于云的存储。

第 3 步：实施最小特权以最大限度地减少威胁行为体通过获取不同应用程序和服务的访问令牌，而造成的潜在损害及获得的访问权限。考虑实施即时访问和动态提升功能，以摒弃长期访问权限，并审查最小特权基础（如从终端删除本地管理员）。这也意味着实施符合最高身份验证器保证级别 (AAL3) 的 MFA 策略，以访问关键的应用程序。

第 4 步：限制特定和受管设备对敏感应用程序的访问，以帮助限制对这些应用程序的访问，包括在 MFA 之上添加多重访问条件（例如 IP 和设备健康状况）。还应采用最小特权管理实践，如限制 RDP 和远程访问仅访问服务台、特权访问管理解决方案 (PAM)、供应商特权访问和管理子网。