S3 Ep102.5:“ProxyNotShell”交换错误 – 专家讲述 [音频 + 文本] PlatoBlockchain 数据智能。 垂直搜索。 哎。

S3 Ep102.5:“ProxyNotShell”交换错误 – 专家发言 [音频 + 文本]

不要惊慌……但要准备好采取行动

与保罗·达克林和切斯特·维斯涅夫斯基

介绍和结尾音乐 伊迪丝·马奇.

单击并拖动下面的声波以跳到任何一点。你也可以 直接听 在 Soundcloud 上。

你可以听我们的 的SoundCloud, 苹果播客, Google播客, Spotify, 以及任何可以找到好的播客的地方。 或者只是放下 我们的 RSS 提要的 URL 进入你最喜欢的播客。


阅读成绩单

[音乐调制解调器]


鸭。  大家好。

欢迎来到 Naked Security 播客的另一个特别迷你剧集。

我是 Paul Ducklin,我的朋友和同事 Chester Wisniewski 再次加入。

你好,切特。


切特。  [假澳大利亚口音] 祝你好运,鸭子。


鸭。  好吧,切特,我相信每个人都在听。 如果他们在播客发布后不久就在收听,就知道我们要说什么了!

它必须是双管的 Microsoft Exchange 零日漏洞 几乎是在 2022 年 XNUMX 月的最后一天洗掉的:

我们的销售伙伴会说,“哦,现在是月末,这是季末,这是一个疯狂的时期……但明天每个人都会重置为 0 美元。”

对于系统管理员和 IT 经理来说,本周末不会是这样!


切特。  鸭子,我想,用死去的道格拉斯·亚当斯的不朽话语, “不要恐慌” 可能是为了。

许多组织不再在 Exchange 服务器上托管自己的内部电子邮件,因此很多人可以在这个周末深吸一口气,花点时间消磨时间,而不会为此感到压力过大。

但是,如果您在本地运行 Exchange……

…如果是我,我可能会加班一些时间,只是为了采取一些缓解措施,以确保我在周一或周二不会有不愉快的意外,因为这很可能会发展成更多的事情戏剧性。


鸭。  所以是 CVE-2022-41040CVE-2022-41042……真是满口。

我在 Twitter 上看到它被称为 代理非Shell,因为它与 代理外壳 一年多前的大事件,

但是,尽管它有这些相似之处,但它是一对全新的漏洞利用链接在一起,可能会提供远程代码执行——对吗?


切特。  听起来就是这样。

这些漏洞是在对受害者的主动攻击中发现的,一个名为 GTSC 的越南组织揭开了这两个新漏洞,使攻击者能够访问他们的一些客户。

听起来他们负责任地披露了 那些漏洞 由趋势科技负责报告零日漏洞的零日倡议 [ZDI]。

当然,在三周前,ZDI 又与微软分享了所有这些情报。

而它今天出来的原因是我认为越南组......

……听起来他们有点不耐烦了,担心已经过去三周了,还没有发出警报或建议来帮助保护人们免受这些所谓的民族国家行为者的伤害。

所以他们决定敲响警钟,让每个人都知道他们需要做一些事情来保护自己。


鸭。  而且,公平地说,他们小心翼翼地说, “我们不会确切透露如何利用这些漏洞,但我们将为您提供我们认为有效的缓解措施。”

听起来好像这两种利用本身都不是特别危险……

......但连在一起,这意味着组织外部能够从您的服务器读取电子邮件的人实际上可以使用第一个错误打开门,并使用第二个错误实质上在​​您的 Exchange 服务器上植入恶意软件。


切特。  这是一个非常重要的观点,鸭子,你说过, “可以在您的服务器上阅读电子邮件的人。”

这不是*未经身份验证的*攻击,因此攻击者确实需要对您的组织有所了解才能成功执行这些攻击。


鸭。  现在,我们并不确切知道他们需要什么样的凭证,因为在我们录制这个 [2022-09-30T23:00:00Z] 的时候,一切在很大程度上仍然是秘密的。

但从我读到的(我倾向于相信的人)看来,会话 cookie 或身份验证令牌似乎不够好,而且您实际上需要用户密码。

在提供密码后,如果有双因素身份验证 [2FA],第一个错误(打开门的错误)会在提供密码的点和 2FA 代码的点之间触发*请求*。

因此,您需要密码,但不需要 2FA 代码……


切特。  如果您想这样称呼它,这听起来像是一个“中间身份验证漏洞”。

这是一个喜忧参半的祝福。

这确实意味着自动化 Python 脚本不能仅仅扫描整个互联网,并可能在几分钟或几小时内利用世界上的每台 Exchange 服务器,正如我们在 2021 年看到的 ProxyLogon 和 ProxyShell 所发生的那样。

在过去的 18 个月中,我们看到了蠕虫病毒的回归,这对许多组织造成了损害。


鸭。  “蠕虫”?


切特。  沃玛格,是的! [笑]


鸭。  这是一个词吗?

好吧,如果不是,那就是现在!

我喜欢……我可以借用它,切斯特。 [笑]


切特。  我认为这是轻度蠕虫,对吧?

您需要一个密码,但不幸的是,在任何给定的 Exchange 服务器上找到一个有效的电子邮件地址和密码组合可能并不难。

当您谈论成百上千的用户时……在许多组织中,其中一两个用户的密码可能很差。

迄今为止,您可能还没有被利用,因为成功登录 Outlook Web Access [OWA] 需要他们的 FIDO 令牌,或者他们的身份验证器,或者您可能使用的任何第二个因素。

但是这种攻击不需要第二个因素。

因此,仅获取用户名和密码组合是一个相当低的障碍……


鸭。  现在这里还有另一个复杂性,不是吗?

即虽然 微软的指导方针 官方表示 Microsoft Exchange Online 客户可以退出 Blue Alert,只有当您拥有本地 Exchange 时才危险……

......有惊人数量的人切换到云,可能是几年前,他们在转换期间同时运行他们的本地和他们的云服务,他们从未有机会关闭本地交换服务器。


切特。  恰好!

我们看到这可以追溯到 ProxyLogin 和 ProxyShell。

在许多情况下,犯罪分子通过他们认为自己没有的 Exchange 服务器进入他们的网络。

就像,有人没有检查在他们的 VMware 服务器上运行的虚拟机列表,以注意到他们的迁移 Exchange 服务器在他们的本地网络和云网络之间的数据叉装过程中协助他们......

……事实上,仍然处于打开状态、启用状态并暴露在互联网上。

更糟糕的是,当不知道它们在那里时,它们被修补的可能性就更小了。

我的意思是,拥有 Exchange 的组织至少可能会特意安排定期对其进行维护。

但是,如果您“因为忘记了”而不知道网络上有什么东西,这对虚拟机来说真的很容易,那么您的情况就更糟了,因为您可能没有应用 Windows 更新或 Exchange 更新。


鸭。  墨菲定律说,如果你真的依赖那台服务器并且你没有妥善照顾它,它就会在你真正需要它的前一天崩溃。

但是,如果您不知道它的存在并且它可能会被用于坏事,那么它运行多年而没有任何问题的可能性可能非常高。 [笑]


切特。  是的,不幸的是,这当然是我的经验!

这听起来很愚蠢,但无论如何,我们建议您定期扫描您自己的网络以了解您拥有的网络。

但可以肯定的是,当您听到这样的公告时,如果它是您知道自己过去使用过的产品,例如 Microsoft Exchange,那么现在是运行该内部公告的好时机 Nmap扫描...

…甚至可能登录 shodan.io 并检查您的外部服务,以确保所有这些东西都已关闭。


鸭。  我们现在从微软自己的回应中知道,他们正在疯狂地寻找补丁。

当这些补丁出现时,你最好快点应用它们,不是吗?

因为如果任何补丁都将成为逆向工程的目标以找出漏洞,那么它将是这种类型的东西。


切特。  是的,绝对是,鸭子!

即使你修补了,也会有一个时间窗口,对吧?

我的意思是,通常微软,无论如何,对于补丁星期二,他们会在太平洋时间上午 10.00 点发布他们的补丁。

现在我们处于夏令时,所以是 UTC-7……所以,通常在 17:00 UTC 左右是微软发布补丁的时间,因此他们的大多数员工有一整天的时间来响应西雅图的传入查询。 [微软总部位于华盛顿州西雅图市贝尔维尤。]

这里的关键是在它开始发生之前有一种数小时甚至数分钟的“竞赛”,这取决于利用它的难易程度。

再一次,回到之前使用 ProxyShell 和 ProxyLogon 进行的 Exchange 漏洞利用,我们经常发现,即使是在三、四、五天内打补丁的客户……

…老实说,这对于 Exchange 服务器来说有点快,它们很难修补,需要进行大量测试以确保在您中断电子邮件服务器之前它是可靠的。

这对那些服务器来说已经足够了 网页壳, cryptominers, 各种 后门 安装在他们身上。

所以,当官方补丁出来的时候,你不仅要迅速行动……

…*在*您采取行动之后,值得回过头来彻底检查这些系统是否有证据表明它们可能在补丁可用和您能够应用它之间的间隙中受到攻击。

我敢肯定会有很多关于 Naked Security 和 Twitter 和其他地方,谈论我们看到的攻击类型,以便您知道要寻找什么。


鸭。  虽然你可以去寻找一堆已知恶意软件的哈希值,这些恶意软件已经在有限数量的攻击中传播……

…真的,底线是各种恶意软件都有可能。

所以,就像我想你在 最后一个小插曲 正如我们所做的那样,仅仅等待发生坏事的警报出现在您的仪表板中是不够的:

你必须主动出去看看,以防骗子已经进入你的网络并且他们留下了一些你还没有注意到的东西(可能已经存在很长时间了!)。


切特。  所以我认为这会引导我们走向, “在等待补丁的同时,我们现在该怎么办?”

微软安全研究中心(MSRC)博客发布 一些缓解建议 和细节……微软目前愿意披露的内容。

我会说,如果你是一个纯粹的人 微软在线交换 客户,您非常清楚,您应该注意以防万一。

但是,如果您处于混合环境中,或者您仍在本地运行 Microsoft Exchange,我认为今天下午或明天早上可能有一些工作非常值得做,如果没有其他事情的话。

当然,在录音的时候,这是星期五下午……所以,真的,当你听这个的时候,“马上,只要你听到它,如果你还没有做的话。”

鸭子,这里的最佳做法是什么?

显然,您可以做的一件事就是在补丁可用之前关闭外部 Web 访问。

您可以关闭您的 IIS 服务器,然后就可以了!


鸭。  我怀疑许多公司不会处于那种位置。

微软列出了他们说的两件事……好吧,他们没有说, “这肯定会奏效。”

他们认为这将极大地限制您的风险。

一是您可以将 URL 重写规则应用于您的 IIS 服务器。 (我的理解是接受传入连接的 IIS 会变成对 Exchange Web 服务 [EWS] 的访问。)

因此,您可以进行一个 IIS 设置,该设置将寻找第一个漏洞的可能利用,这将阻止 PowerShell 触发启动。

您可以在 Exchange Server 上阻止一些 TCP 端口。

我相信是端口 5985 和 5986,这将停止所谓的 PowerShell Remoting…它将阻止这些恶意 PowerShell 远程执行命令被插入 Exchange 服务器。

但是请注意,微软确实表示这将“限制”您的曝光,而不是承诺他们知道它可以解决所有问题。

这可能是因为他们怀疑还有其他方式可以触发这种情况,但他们只是还没有完全弄清楚它们是什么。 [笑]

这两种设置都不是您在 Exchange 本身中执行的操作。

其中一个是在 IIS 中,另一个是某种网络过滤规则。


切特。  好吧,这有助于我们度过接下来的几天,而 Microsoft 会为我们提供永久性修复。

好消息是,我认为有很多安全软件,无论是可能集成在防火墙中的 IPS,还是保护 Microsoft Windows Server 基础架构的端点安全产品……

...在许多情况下(至少早期报告),针对此的攻击看起来与 ProxyLogon 非常相似,因此,目前尚不清楚现有规则是否可以防止这些攻击。

他们可能会,但除此之外,大多数供应商似乎都在试图收紧一点,以确保他们尽可能准备好,基于当前公开共享的所有指标,因此他们将检测并如果这些发生在您的 Exchange 服务器上,则向您发送警报。


鸭。  没错,切斯特。

对于 Sophos 客户来说,好消息是,如果您想查看日志,可以跟踪特定于 Sophos 的检测。

不只是 IPS,无论是防火墙上的 IPS 还是端点上的 IPS,我们还有一堆行为规则。

如果您想去寻找它们,您可以跟踪这些检测名称……在 @SophosXops Twitter提要。

随着我们获得可用于威胁搜寻的新检测名称,我们将它们发布在那里,以便您轻松查找它们:


切特。  我敢肯定,我们将在下周的播客中有更多话要说,无论是道格重新加入你,还是我再次坐在嘉宾席上。

但我非常有信心,我们在很长一段时间内都无法将其搁置……


鸭。  我认为,像 ProxyShell 和 Log4Shell 一样,会在相当长的一段时间内产生回响。

所以也许我们最好像往常一样说,切斯特:

直到下一次…


两个都。  保持安全。

[音乐调制解调器]


时间戳记:

更多来自 裸体安全