Okta 安全漏洞被追溯与曝光:
一次关于管理与员工疏忽的教训

11 月 6 日,国际身份管理软件领导者 Okta 发布了一份安全追溯通告,回顾了 9 月 28 日至 10 月 17 日期间发生的入侵事件。此次攻击导致 134 家客户的敏感文件被访问,5 家客户的 Okta 管理账户被劫持

Okta

调查人员将此次入侵追溯到一名员工 —— 他在工作电脑上使用了个人 Chrome 账户同步工作凭证。这凸显了安全措施的严重缺失,例如缺乏访问限制和双因素认证。Okta 的披露在很大程度上将责任归咎于员工无视规定,却掩盖了导致入侵的系统性设计缺陷。显而易见,更完善的安全管理本可以避免这起事件。

Sinokap 一直坚持推荐使用双因素认证,我们也在相关视频中分享过对此主题的见解,欢迎大家查阅。

甩锅员工:深入剖析 Okta 的安全事件

“在对该账户可疑使用情况进行调查时,Okta 安全部门发现,一名员工曾在公司管理的笔记本电脑上,用 Chrome 浏览器登录了其个人 Google 账号。” Bradbury 写道。

 

“该服务账户的用户名和密码被保存到了该员工的个人 Google 账号中。最可能的泄露途径是,该员工的个人 Google 账号或个人设备遭到入侵,从而导致凭证被暴露。”

 

这意味着,当员工在 Chrome 中登录该账户,并且 Chrome 处于已登录个人 Google 账号的状态时,凭证就被保存到了该个人账号中 —— 很可能是通过 Chrome 内置的密码管理器完成的。随后,威胁行为者在攻陷该个人账号或设备后,便获得了访问 Okta 账户所需的凭证。

 

“在像 Okta 这样的公司,使用公司电脑访问个人账号一直被视为严重禁忌。如果之前有人对此不够清楚,那么现在应该非常明确了。这名员工几乎可以肯定违反了公司政策,因此如果因此遭到解雇也不足为奇。

 

然而,如果此次入侵仅仅是由员工的不当行为触发,那么只能说明各方都存在错误。实际上,责任在于设计被攻陷支持系统的安全人员,尤其是被攻陷的服务账户的配置方式存在问题。”

服务账户存在于多种操作系统和框架中,它们不同于普通的人类用户账户。

 

服务账户主要执行 自动化的机器对机器功能,例如在每天夜间的特定时间执行数据备份或病毒扫描。

 

因此,它们无法像用户账户一样通过多因素认证(MFA)进行保护。这也解释了为什么 Okta 没有为服务账户设置 MFA。

 

然而,这次入侵暴露出了一些未受到足够重视的缺陷 —— 即使在部分 Okta 高级安全官员的公开说明中,也未得到充分强调。

根因分析

David Bradbury 表示,Okta 于 2023 年 9 月 29 日 首次在其网络中检测到潜在的可疑活动。当时,1Password 主动报告称其内部的 Okta 实例已被攻陷。起初怀疑是一名 1Password 员工的设备感染了恶意软件,从而导致入侵。

 

10 月 2 日,另一家客户 BeyondTrust 也主动报告称其账户遭到入侵。但 Okta 直到 10 月 16 日 才确认入侵源头。这种迟缓的反应,使得威胁行为者能够在超过两周的时间里持续访问服务账户。

Bradbury 写道:
“当用户打开并查看支持案例中附带的文件时,系统会生成一个与该文件相关的特定日志事件类型和 ID。但如果用户直接进入客户支持系统的 Files 标签页 —— 就像攻击者在这次事件中所做的那样 —— 系统会生成完全不同的日志事件和记录 ID。”

 

Okta 最初的调查集中在支持案例的访问情况,随后才去评估与这些案例相关的日志。10 月 13 日,BeyondTrust 向 Okta 安全部门提供了一个与攻击者相关的可疑 IP 地址。凭借这一指标,Okta 才识别出与受损账户相关的更多文件访问事件。

 

另一个失误是,Okta 在网络可见性方面的不足,这放大了入侵的后果。否则,Okta 本可以更早发现攻击者的访问行为,尽管这并不是入侵发生的根本原因。

整改措施

首先,Okta 应当为服务账户设置超越简单密码的访问控制。例如:

  • 可以通过 限制或设定条件(如仅允许特定 IP 地址连接)来控制访问;

  • 或者 定期轮换认证令牌,以降低长期使用带来的风险。

此外,必须禁止员工在工作设备上登录个人账号,而落实相关安全防范措施是 Okta 高层管理人员的职责。

尽管“零信任”安全方法有时被过度使用,但其核心原则仍然合理。假设网络已经被攻陷,企业需要在设计层面防止不安全事件的发生。应当采取 分层设计、纵深防御 的策略,避免单点故障,例如避免仅仅因为一个密码或认证令牌泄露,就导致严重后果。

Bradbury 在其说明中默认承认了一些整改措施上的不足,包括:

  1. 禁用受损的服务账户(已完成)
    —— Okta 已禁用客户支持系统中的该服务账户。

  2. 阻止在 Chrome 上使用个人 Google 账号(已完成)
    —— Okta 在 Chrome Enterprise 中配置了策略,禁止在公司管理的笔记本电脑上使用个人 Google 账号登录 Chrome。

  3. 加强客户支持系统监控(已完成)
    —— Okta 已为客户支持系统部署了额外的检测与监控规则。

  4. 基于网络位置绑定 Okta 管理员会话令牌(已完成)

Sinokap对Okta漏洞事件的看法

Okta 值得肯定的一点是,他们在事件发生后进行了内部分析和处理,采取了实质性的改进措施,并向公众公布了时间线。但他们不应仅仅将责任归咎于一名员工 —— 实际上这是管理层失职所导致的,把问题推给个人只会掩盖真正的根源。

作为一家内部 IT 团队,Sinokap 提醒所有企业应以此事件为警示。管理层的参与以及员工的安全培训 对数据安全至关重要。

请继续关注我们的下一期内容,我们将提供有关企业管理与安全培训的建议与解决方案,以帮助更好地保护客户数据。

CN