安小圈
第659期
浏览器 · 风险
▲攻击者越来越多地利用基于身份的技术而非软件利用，钓鱼和被盗凭证（钓鱼的副产物）现在已成为泄露的主要原因。
攻击者之所以转向像钓鱼这样的身份攻击，是因为他们仅通过登录受害者的账户就能实现传统端点或网络攻击的所有目标。随着组织现在在整个员工队伍中使用数百个互联网应用，可被钓鱼或被盗凭证攻击的账户范围呈指数级增长。
随着能够绕过多因素认证的钓鱼工具包成为新常态，这些工具包能够钓取由短信、一次性密码和推送方式保护的账户，当预防控制措施失败时，检测控制就会受到持续的压力。
攻击者正在绕过检测控制
大多数钓鱼检测和控制执行都集中在电子邮件和网络层——通常在安全邮件网关（SEG）、安全 Web 网关（SWG/代理），或者二者。
但攻击者知道这一点，并正在采取措施来避开这些控制，通过：
-
通过动态轮换和更新常被签名的元素，如 IP、域名和 URL，常规性地规避基于 IoC 的阻断名单。
-
通过在他们的钓鱼页面上实施机器人防护（如 CAPTCHA 或 Cloudflare Turnstile）以及其他检测规避方法，阻止对页面进行分析。
-
更改页面上的视觉和 DOM 元素，以致即使页面已加载，检测签名也可能无法触发。
▲实施像 Cloudflare Turnstile 这样的机器人检查是绕过沙箱分析工具的有效方式。
事实上，通过发起多通道和跨通道攻击，攻击者完全绕过了基于电子邮件的控制。请看这个最近的例子：冒充 Onfido 的攻击者通过恶意 Google 广告（又称恶意广告投放）投递他们的钓鱼攻击——完全绕过了电子邮件。
▲攻击者正通过即时通讯、社交媒体、使用恶意广告，以及通过发送受信任应用的消息来绕过电子邮件，直接瞄准受害者。
在此也值得指出电子邮件解决方案的局限性。电子邮件在发件人信誉和 DMARC/DKIM 等方面有一些额外检查，但这些检查实际上并不能识别恶意页面。类似地，一些现代电子邮件解决方案对邮件内容进行更深入的分析。但……这并不能真正帮助识别钓鱼站点本身（它们只表明邮件中可能链接了钓鱼站）。这更适用于 BEC 类型的攻击，其目标是对受害者进行社交工程，而不是将他们引导到恶意页面。正如我们上面所强调的，这对通过不同媒介发起的攻击也同样无能为力。
浏览器内检测与响应如何能扳回一城
大多数钓鱼攻击涉及向用户投递一个恶意链接。用户点击链接并加载恶意页面。在绝大多数情况下，这个恶意页面是某个网站的登录门户，攻击者的目标是窃取受害者账户。
这些攻击几乎完全发生在受害者的浏览器中。因此，与其构建更多的电子邮件或网络层控制，从外向内地去观察在浏览器中访问的钓鱼页面，不如在浏览器内部构建钓鱼检测与响应能力，这为我们提供了巨大的机会。
回顾检测与响应的历史，这非常合理。当 2000 年代后期至 2010 年代初端点攻击激增时，它们利用了一个事实：防御者试图主要通过网络层检测、基于特征的文件分析以及在沙箱中运行文件来检测恶意软件（而沙箱可被沙箱感知型恶意软件可靠绕过，甚至只需在代码中加入执行延迟即可）。但这催生了 EDR，它提供了在实时观察并拦截恶意软件的更好方式。
▲EDR 使得在操作系统层面进行实时检测与响应成为可能，而不是依赖于端点的进出流量。
关键在于进入数据流内部，能够在端点上实时观察活动。
现如今，我们处境相似。现代钓鱼攻击发生在通过浏览器访问的网页上，而我们依赖的工具——电子邮件、网络，甚至端点——都没有所需的可见性。它们是从外向内在看。
▲当前的钓鱼检测并不在正确的位置，无法实时观察并阻止恶意活动。
但如果我们能在浏览器内部进行检测与响应，会怎样？接下来是三个浏览器胜过其他防御位置的理由：
1、分析页面，而非链接
常见的钓鱼检测依赖于对链接或静态 HTML 的分析，而不是对恶意页面本身的分析。现代钓鱼页面不再是静态 HTML——就像大多数现代网页一样，它们是动态 Web 应用，在浏览器中渲染，JavaScript 会动态重写页面并加载恶意内容。这意味着大多数基本的静态检查无法识别在页面上运行的恶意内容。
如果没有更深层次的分析，你只能依赖于检查域名、URL 和 IP 地址是否出现在已知恶意的阻断名单中。但这些指标都非常一次性。攻击者可以批量购买，不断接管合法域名，并普遍预期他们会用掉大量指标。现代钓鱼架构还能动态轮换并更新提供给访问者的链接（因此每位点击链接的人都会收到不同的 URL），甚至使用一次性魔术链接（这也意味着任何安全团队成员后来尝试调查页面都无法访问该页面）。
最终，这意味着阻断名单并不那么有效——因为攻击者轻而易举就能更换用于创建检测的指标。如果你想到“痛苦金字塔”（Pyramid of Pain），这些指标位于最底层——这是端点安全世界多年来一直努力摒弃的东西。
但在浏览器里，你可以观察完整渲染的网页。由于对页面（以及其恶意元素）拥有更深的可见性，你可以……
2、检测 TTP，而非 IoC
即使在 TTP 检测发挥作用的地方，它们通常依赖于拼接网络请求，或在沙箱中加载页面。
然而，攻击者正变得相当擅长绕过沙箱分析——仅仅通过实施机器人防护，要求用户与 CAPTCHA 或 Cloudflare Turnstile 进行交互。
实施像 Cloudflare Turnstile 这样机器人检查是绕过沙箱分析工具的有效方式。
即使你能通过 Turnstile，你还需要提供正确的 URL 参数与请求头，并执行 JavaScript，才能呈现恶意页面。这意味着防御者即便知道域名，也无法仅通过一次简单的 HTTP(S) 请求就发现恶意行为。
如果这一切还不够，他们还会混淆视觉和 DOM 元素，以防止基于特征的检测将其捕获——因此即使你能成功加载页面，你的检测很可能也不会触发。
使用代理时，你可以看到用户访问并与页面交互所产生的部分网络流量。然而当面对大量无序的网络流量数据时，你将难以将关键操作（如用户是否输入密码）与特定浏览器标签关联起来。
但在浏览器中，你可以获得远更好的可见性，包括：
-
完整的解密 HTTP 流量——不仅仅是 DNS 和 TCP/IP 元数据；
-
完整的用户交互追踪——每一次点击、击键或 DOM 变化都能被追踪；
-
在执行的每一层进行完整检查，而不仅仅是首个返回的 HTML；
-
对浏览器 API 的全面访问，可与浏览器历史记录、本地存储、附加 cookie 等进行关联。
这为你提供了构建高置信度检测所需的一切，重点放在页面行为和用户交互上——相比 IoC 检测，这些更难被攻击者绕过。
▲在浏览器中，你可以构建基于 TTP 的更高效控制
而凭借这种新可见性，因为你在浏览器里，与用户同时看到页面，你可以……
3、实时拦截，而非事后检讨
对于非浏览器解决方案，实时钓鱼检测基本不存在。
在最佳情况下，你的代理解决方案也许能通过用户与页面交互产生的网络流量来检测恶意行为。但由于在 TLS 加密之后重构网络请求的复杂性，这通常会有时间延迟，并且并不完全可靠。
若某页面被标记为恶意，通常还需要安全团队作进一步调查，以排除误报并启动调查流程。这最好也得花上数小时，极有可能是数天。然后，一旦页面被确认为恶意并生成 IoC，可能需要数天甚至数周时间才能将信息分发出去、更新威胁情报源并导入阻断名单。
但在浏览器内，你是实时观察页面，与用户同步看到它。这在不仅检测，而且在用户遭钓鱼前就拦截并阻断攻击方面具有颠覆意义。焦点由事后遏制和清理转向实时的事前阻断。
浏览器将是钓鱼检测与响应的未来
END
原文始发于微信公众号（安小圈）：3个理由，告诉你为什么浏览器是阻止钓鱼攻击的最佳选择？
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论