攻击者绕过 2FA。怎么防守?

信息安全 多因素
2021-08-31 03:09:10

最新的 NSA 转储中详细介绍了一种据称被俄罗斯情报机构用来规避 2FA 的方法。(在这种情况下,Google 2FA 的第二个因素是代码。)

这是一个相当明显的方案,我确信必须定期使用。它似乎像这样工作:

  1. URL 通过鱼叉式网络钓鱼发送到目标,该 URL 指向攻击者控制的类似于 Google Gmail 的网络钓鱼网站。
  2. 用户将凭据发送到虚假的 Gmail。
  3. (假设)攻击者将凭据输入到合法的 Gmail 中,并检查是否需要第二个因素。
  4. 目标收到合法的第二个因素。
  5. Phony Gmail 网站提示目标为第二个因素。目标发送第二个因素。
  6. 攻击者将第二因素输入合法站点并成功进行身份验证。

我能看到防御这种攻击的唯一方法是通过 FW、威胁情报等将虚假站点发现为骗局或阻止网络钓鱼站点。

有没有其他实用的方法来防御这种计划?

在此处输入图像描述

4个回答

并非所有的双因素身份验证方案都是相同的。某些形式的 2FA(例如向您发送短信)无法抵御这种攻击。其他形式的 2FA,例如 FIDO U2F,对这种攻击是安全的——它们在设计时就考虑到了这种攻击。

FIDO U2F 针对中间人攻击提供了两种防御:

  1. 注册- 用户将其 U2F 设备注册到特定网站(“来源”),例如google.com. 那么U2F设备将只响应来自已注册源的认证请求;如果用户被诱骗访问goog1e.com(网络钓鱼站点),则 U2F 不会响应请求,因为它可以看到它来自之前未注册的站点。

  2. 通道 ID 和源绑定- U2F 使用 TLS 通道 ID 扩展来防止中间人攻击,并使 U2F 设备能够验证它正在与用户在其 Web 浏览器中访问的同一个网站进行通信。此外,U2F 设备知道它认为正在与之交谈的来源,并且其签名的身份验证响应包括它认为正在与之交谈的来源的签名。这由服务器检查。因此,如果用户打开goog1e.com并且该页面请求 U2F 身份验证,则来自 U2F 设备的响应表明它的响应仅适用于与之通信goog1e.com- 如果攻击者试图将此响应中继到google.com,谷歌可以注意到某些东西已经出错了,因为签名数据中存在错误的域名。

这两个功能都涉及 U2F 双因素身份验证设备和用户浏览器之间的集成。这种集成允许设备知道浏览器正在访问的域名(来源),并允许设备检测或防止网络钓鱼和中间人攻击。

关于这个机制的进一步阅读:

  • FIDO U2F 规范的摘录,关于防御 MITM 攻击。

  • Yubico对协议流程的解释。

带外 2FA 是正确的方法。这意味着您有第二个无法被钓鱼的因素,例如客户端证书或 FIDO U2F。代码或基于 SMS 的 2FA 模型是最弱的 2FA 选项,因为它们是带内的,并且正如您所描述的,可以像凭据一样被网络钓鱼。

它们很方便,因为几乎任何人都可以使用它们,而且它们肯定比没有好,但它们提供的安全性永远不应与带外 2FA 提供的安全性相混淆。

这是(在浏览器中)密码管理器可以帮助您的情况之一。

因为密码管理器通过其真实 url 存储密码,所以它不会自动填充攻击者的页面,甚至不会给出建议。除了不泄露 2 步密码令牌外,它还可以保护密码不被泄露。

如果用户不知道自己的密码,这种保护甚至可以更好地发挥作用,并且只能通过密码管理器进行交互以填写密码。

底线是,如果攻击者可以欺骗您提供所有凭据,那么游戏就结束了。涉及的因素的数量无关紧要。有些事情可以帮助限制暴露,例如令牌的非常短的超时,这使得攻击者难以在时间限制内获取和重用令牌。但是,超时的保护有限,因为平衡可能很困难,尤其是在“假”2FA 的情况下,这种情况已经变得如此普遍,并且您必须允许延迟发送 SMS 等事情以防止可用性问题(我已经看到使用国际基于服务的 SMS 传递可能会更慢,并且令牌在您接收它并在浏览器中输入之前超时)。

许多称为 2FA 的系统根本不是真正的 2FA - 它们实际上是 2SA(两步验证)。在真正的 2FA 中,因素是您知道的东西(密码)和您拥有的东西(令牌,通常基于硬件)。涉及通过 SMS 发送代码的方案不是 2FA,它们是 2SA - 您实际上没有令牌 - 它被发送给您。由于它是发送给您的东西,因此存在新的威胁向量,例如重定向手机号码等。这就是 NIST 不推荐使用基于 SMS 的令牌作为可靠身份验证过程的原因之一。

关于 OPs 的具体问题,唯一可靠的保护是能够检测到网络钓鱼页面。谷歌发布了一个 chrome 扩展来尝试帮助解决这个问题。如果扩展程序检测到您正在向非 google 页面提供您的 google 凭据,它将警告您。

最大的问题是,我们多年来一直在教人们在 URL 中寻找“绿色挂锁”,以确保页面是合法的。不幸的是,像 Lets Encrypt 这样的努力现在使获得域验证证书变得容易,因此这些网络钓鱼页面中的许多现在都将带有绿色挂锁。这并不是说问题是由于 Lets Encrypt - 这是一个非常好的举措。这个问题部分是由于 PKI 基础设施的弱点,但主要是由于用户的意识和理解。通常,人们不了解 PKI 以及如何验证证书对于站点是否合法以及该站点是否是他们认为的站点。更糟糕的是,即使您确实了解,执行该验证所需的步骤/时间通常也不方便或太难,因此人们不会这样做。那些想方设法让事情看起来合法的破坏者使情况变得更糟——例如,最近的一个漏洞利用浏览器显示 URL 和 Unicode 字符的方式中的弱点来生成一个 URL,该 URL 在地址栏中呈现的方式在一瞥看起来是正确的,但 URL 中的实际字符指定了一个网络钓鱼站点。用户查看地址栏,看到一个绿色的挂锁,然后看了一眼看起来正确的 URL(你的大脑甚至会填写一些内容以使匹配看起来更好!)并认为该页面是合法的。您不会注意到字符之间有一些额外的空白或看起来有点奇怪的字符形状。最近的一个漏洞利用浏览器显示 URL 和 Unicode 字符的方式中的弱点来生成一个 URL,该 URL 以一种乍一看正确的方式呈现在地址栏中,但 URL 中的实际字符指定了一个网络钓鱼站点。用户查看地址栏,看到一个绿色的挂锁,然后看了一眼看起来正确的 URL(你的大脑甚至会填写一些内容以使匹配看起来更好!)并认为该页面是合法的。您不会注意到字符之间有一些额外的空白或看起来有点奇怪的字符形状。最近的一个漏洞利用浏览器显示 URL 和 Unicode 字符的方式中的弱点来生成一个 URL,该 URL 以一种乍一看正确的方式呈现在地址栏中,但 URL 中的实际字符指定了一个网络钓鱼站点。用户查看地址栏,看到一个绿色的挂锁,然后看了一眼看起来正确的 URL(你的大脑甚至会填写一些内容以使匹配看起来更好!)并认为该页面是合法的。您不会注意到字符之间有一些额外的空白或看起来有点奇怪的字符形状。) 并接受该页面为合法的。您不会注意到字符之间有一些额外的空白或看起来有点奇怪的字符形状。) 并接受该页面为合法的。您不会注意到字符之间有一些额外的空白或看起来有点奇怪的字符形状。

那么我们如何防范这种情况。不幸的是,没有单一的“这样做,你就会安全”。一些密码管理器可以提供帮助,因为他们只会在 URL 正确的情况下提供凭据,永远不要在电子邮件中使用 URL - 始终自己输入或使用您创建的书签。假设在某些时候你会被愚弄并采取措施来限制损害发生时,即每个站点的不同密码,尽可能使用基于硬件的 2FA,实际单击“高价值”站点的证书详细信息按钮并查看它说明了证书的注册对象,确保您的系统具有所有更新并且您使用的是最新的浏览器版本等,本质上是可疑的,并记住最大的威胁是社会工程,因此,对于任何迫使您基于恐惧、内疚、奖励或惩罚而采取行动的事情,请务必保持警惕。这些是非常有效的激励因素,威胁参与者依赖它们。网络钓鱼活动在实施过程中变得更加复杂,但在其核心,它们仍然依赖于情绪操纵——对美好事物的承诺或对可怕事物的威胁。

最后,如果您因为我提到密码管理器而想发表评论,请不要。是的,密码管理器存在风险,是的,有些比其他的更糟糕。但是,一般来说,正确使用的好的密码管理器通常会为普通用户提供比他们当前的密码管理过程更多的保护。是的,如果密码管理器被泄露,那么您的所有密码都会被泄露。然而,许多人发现密码管理太难了,并且无论如何都在每个站点上使用相同的,通常是弱密码。一旦一个站点被入侵,他们的所有站点都会被入侵。显然,如果您了解技术并且了解密码、散列等,您可能会想出一个更安全的解决方案,但您不是密码管理器的受众。

编辑:在重新阅读我的回复时,我不确定我是否足够强调真正的 2FA 越来越可用,并且许多目前支持使用 SMS 代码的不太安全的 2SA 的提供商也支持更安全的 2FA,在许多情况下使用 U2F (如其他回复中所述)。Yubico 或 duo(以及其他)的硬件“钥匙”价格便宜且易于设置/使用。我唯一的建议是,如果您决定采用硬件令牌/密钥路线,请确保您获得两个密钥,将它们都注册并将一个密钥放在安全的位置。我有一个随身携带,一个放在家里的保险箱里。从丢失/损坏的密钥中恢复并不像从忘记的密码中恢复那样容易,因此您希望尽可能避免陷入这种情况。