-
-
[翻译]snap隐患:Ubuntu软件包建议系统中隐藏的危险
-
发表于: 2024-2-19 11:56 989
-
翻译:梦幻的彼岸
原文地址:https://www.aquasec.com/blog/snap-trap-the-hidden-dangers-within-ubuntus-package-suggestion-system/
Aqua Nautilus 的研究人员发现了一个由 Ubuntu 的command-not-found软件包和 snap 软件包仓库之间的交互引起的安全问题。虽然command-not-found是为未安装的命令提供安装建议的便捷工具,但攻击者可能会通过 snap 软件包库无意中操纵它,导致恶意软件包的欺骗性推荐。
此外,我们的研究表明,多达 26% 的与 APT(高级软件包工具)软件包相关的命令容易被恶意行为者假冒。这一问题可能为影响 Linux 用户和运行 WSL 的 Windows 的供应链攻击铺平道路。本博客将深入探讨command-not-found[命令未找到]的操作细节、安装受攻击的 snap 软件包的相关风险以及可能被利用的各种攻击载体。
command-not-found 软件包
command-not-found软件包在 Ubuntu 上是默认安装的,它为 Linux 用户提供了一项宝贵的服务:当用户试图在 Bash 或 Zsh 中执行一个系统上不可用的命令时,它会建议安装一些软件包。这是通过执行command_not_found_handle函数实现的,Bash 在遇到无法识别的命令时会调用该函数。
该软件包可为APT和snap软件包提供建议。例如,如果用户试图运行ifconfig,但它没有安装,软件包就会建议用户通过 apt 安装net-tools:
图 1:建议通过 apt 安装 "net-tools "软件包
同样,当用户尝试运行与 Visual Studio Code 相关联的代码命令时,他们会收到通过 snap 安装代码包的建议。
图 2:建议通过 snap 安装 "code "软件包
如果一条命令同时对应一个 snap 和一个 apt 软件包,那么命令未找到软件包会同时建议这两个选项,比如mojo命令:
图 3:软件包提供了关于 apt 和 snap 软件包的建议。
了解 "command-not-found "的建议算法
command-not-found软件包配备了一个内部数据库,可将命令与流行的 APT 软件包关联起来,值得注意的是,命令名称可能与软件包名称不同(如上文ifconfig命令与net-tools软件包的例子)。只有在command-not-found软件包本身升级时,才会更新该数据库。
相反,对于 snap 软件包,软件包依赖于snap advise-snap命令。这一功能由 snap 提供,它引用了自己从 Snap Store 获取的定期更新的数据库。
系统如何决定推荐哪个软件包?要理解这一点,我们可以深入研究下面来自command-not-found软件包的代码片段。
图 4:"command-not-found "软件包的代码片段。
程序开始时,command-not-found软件包利用get_packages函数识别相应的 APT 软件包,并利用get_snaps函数检索匹配的snap软件包。随后,它会评估多个条件,以提供尽可能准确的建议。如果在 snap 和 APT 软件库中都没有找到完全匹配的软件包,它会尝试推荐类似的命令,并考虑潜在的错别字。在存在完全匹配的情况下,建议取决于结果的数量,这是因为可能有多个 snap 或 APT 软件包与同一命令相关联。
我们了解了command-not-found软件包所采用的建议机制(该机制依赖于 APT 和 snap 软件库)后,一个重要的问题出现了: 攻击者操纵该系统让命令未找到软件包推荐其恶意软件包的可行性有多大?
虽然 APT 软件包在主机操作系统上运行不受限制,但并非任何人都能向官方 APT 软件源提供软件包。开发者必须经过一个验收过程,才能获准上传软件包。
由于这些原因,并考虑到command-not-found软件包的 APT 数据库不会定期更新,我们将重点转移到攻击者在 snap 软件库中发布恶意软件包的可能性上。
snap软件包的限制
既然我们已经确定了要研究 snap 软件包,那么探索 snap 团队对发布者及其软件包的限制就至关重要了。
首先,我们需要了解限制级别。snap限制有两个主要级别:
- Strict confinement[严格限制],这是大多数 snap 包所使用的。严格限制的 snap 运行在一个沙箱环境中,它们不能访问文件、网络、进程或任何其他系统资源
- Classic[经典],可以在主机上运行,就像一个没有任何限制的 APT 包一样。
这就提出了一个直接的问题:为什么恶意行为者不会选择分发经典snap呢?这里的保障措施是要求 snap 团队对请求某些权限(如经典限制)的 snap 进行手动审核。然而,并非所有应用程序都需要经典限制所提供的全套权限,同时还需要访问特定的本地系统资源。为了满足这一要求,我们开发了接口机制。
snap 接口
snap 接口是被严格限制的snap包的受控网关,使它们能够与沙箱环境中通常禁止使用的外部资源进行交互。有许多接口(这里有一份全面的列表),每个接口都能有效地在沙箱墙壁上创建受控 "裂缝"。通过这些开口,小程序可以与主机资源或其他正在运行的小程序的环境互动。
图 5:可用快取接口的部分列表。
在上图中,我们可以看到可用 Snap 接口的部分列表。一些接口赋予snap大量权限,允许它们访问和操纵敏感的系统资源,包括账户管理和声音记录。其他接口则提供了更多无害的功能,例如 "音频播放",它只允许snap播放音频。
这些接口可根据其自动连接属性进行分类。该属性决定了哪些接口可以自动连接到snap包(标记为 "是"),哪些接口需要snap团队手动批准,就像传统的限制一样,然后才能在商店中发布。
恶意严格 snap 程序包的危险
我们的调查主要集中在攻击者使用恶意快包最可能采用的策略上。有鉴于此,我们对不触发任何手动审查的快包的功能特别感兴趣。具体来说,我们的目标是揭示攻击者利用严格限制的snap包可能实现的目标,这种snap包只利用设置为自动连接的接口,而不需要手动批准。
桌面接口
虽然大多数许可接口都需要人工审核,但桌面接口可以自动连接。这些接口允许具有图形用户界面(GUI)的应用程序连接到显示服务器,并在主机系统上显示窗口。
在 Linux 中,显示服务器是一个程序,负责管理系统上的图形输出和输入,实现图形用户界面(GUI)。应用程序使用特定的显示服务器协议与显示服务器通信。X11 和 Wayland 就是此类协议的两个例子。X11 是一个历史悠久的显示服务器协议,而 Wayland 则是一个较新的协议,旨在提供一个更现代、更安全的窗口系统来取代 X11。
这里的主要问题是,沙盒限制的强度取决于显示服务器的能力。因此,过时的显示服务器(如使用 X11 协议的 X 窗口系统)在不同应用程序的窗口之间缺乏真正的安全隔离。这使得连接到 X11 接口的 Snap 可以窃听其他窗口,并有可能捕获主机的按键。
Canonical 知道这个问题,Matthew Garrett曾在 2016 年写过一篇关于这个问题的博客,强调了 Snap 限制在 X11 上存在的安全漏洞。
他发布了一个开源工具来演示这一漏洞。我对这个 PoC 进行了一些修改,并在 Ubuntu 22 上运行了它:
我们可以在上述视频中观察到,执行名为 friendlyteddy 的严格限制的 snap 包,可以窃取主机上用户在输入时的凭据。
虽然 snap 团队宣称他们希望从不安全的 X 服务器过渡到更安全的显示服务器协议(如 Wayland),但如今 X 服务器仍被各发行版普遍使用。虽然 Wayland 是 ubuntu 22 的默认协议,但 X 服务器仍然是默认安装的,有许多文章和帖子都在介绍如何在 Ubuntu 中切换到使用 X 服务器而不是 Wayland -https://linuxconfig.org/how-to-use-x-instead-of-wayland-on-ubuntu-22-04。
内核漏洞
即使避免使用不安全的 X11 协议,安装恶意 snap 软件包仍然存在风险。主机和所有其他活动的 snap 软件包共享同一个内核。这就意味着,如果内核中存在snap软件包可以利用的漏洞,它就可能突破沙箱,从而完全控制主机系统。Linux 内核每年都会发现大量漏洞。仅在 2023 年,报告的漏洞就有 282 个(根据stack.watch)。虽然每个漏洞的严重程度不同,而且并非所有漏洞都能通过 Snap 容器利用,但潜在威胁仍然很大。
此外,snap 还具有自动更新功能,可将已安装的 snap 版本自动更新为最新版本。虽然这有利于修补 snap 软件包本身的漏洞,但也存在安全隐患。恶意行为者可以利用这一功能部署针对新漏洞的漏洞利用程序。例如,攻击者可能会假冒一个受信任的软件包。一旦发现关键的 Linux 内核漏洞,他们就会向 snap 软件源推送恶意更新。结果,自动更新机制会自动向所有用户分发恶意版本,在用户有机会应用任何安全补丁之前利用内核漏洞。
Command-Not-Found 冒充软件包的行为
在对 snap 软件包和安装恶意软件包的风险有了基本了解后,我们回到了我们最关心的问题:command-not-found的软件包。我们现在的目标是研究攻击者如何可能利用命令未找到系统欺骗用户安装他的恶意软件包。
snap 软件包命令别名
snap 的文档规定,为防止不同的snap暴露相同的应用程序名称而产生冲突,snap的命令格式为 <snap名称>.<应用程序名称>。当 snap 名称与应用程序名称相同时,命令简化为 <snap name>。
例如,如果snap名为 code,应用程序名为 vscode,执行的命令就是 code.vscode。相反,如果应用程序名称也恰好是 code,与snap名称一致,则执行的命令将从 code.code 简化为 code。
如果开发人员希望他们的snap执行的命令偏离 <snap name>.<application name> 格式,而不是简单的 <snap name>,他们必须申请一个别名。这种申请会启动一个人工审核程序,对所申请的别名进行投票,以确保它与应用程序一致。
不过,由于注册的名称只是别名,而不是正式的snap名称,因此实际的snap名称仍有待争夺。这意味着攻击者有可能注册相应的 snap 名称,从而冒充命令。
让我们来看一个例子。
图 6:软件包建议安装 snap "tarquin"。
在上图中,我们发现在输入 tarquingui 命令时,"command-not-found "软件包建议安装 tarquin snap。命令 tarquingui 与snap名称不完全匹配,这表明 tarquingui 是 tarquin snap的别名(别名请求详情可在此处找到)。不过,如前所述,由于别名并不等同于snap名称保留,这就为攻击者注册 tarquingui snap名称并在其下发布自己的snap包留下了空间。
下面是我们以 tarquingui 为名发布snap包后的命令输出:
图 7:在我们发布名称为 "tarquingui "的snap 包后
攻击者可以通过 Snap Store API 系统地查看所有命令别名,以识别snap名称仍然可用的任何别名。找到后,他们就可以用该名称注册一个新的snap包,从而有机会欺骗用户安装恶意软件包。
值得注意的是,文档指出别名不一定是唯一的,可能存在潜在冲突。
APT 软件包命令
我们已经研究过 snap 软件包如何被冒充,但冒充 APT 软件包的可能性则是另一个令人担忧的问题。如前所述,命令未找到实用程序依赖于位于 /var/lib/command-not-found/commands.db 的本地数据库,该数据库将命令链接到其对应的 APT 软件包,从而指导用户进行准确安装。
我们想研究有多少本地数据库中列出的命令会被攻击者利用,将它们注册为snap包名称。这将有可能导致命令未找到实用程序在提示合法 APT 软件包的同时提示恶意 Snap 软件包。
在为每条命令查询 snap Store 以检查可用的 snap 包名称时,发现的情况令人震惊。我们发现,有 26% 的 APT 软件包命令是可用的,这带来了巨大的安全风险,因为它们可能被注册到攻击者的账户下。
例如,其中一个软件包是 jupyter-notebook 软件包:
图 8:建议通过 apt 安装 "jupyter-notebook "软件包
jupyter-notebook APT 软件包的维护者没有申请相应的snap名称。这一疏忽为攻击者提供了一个机会之窗,使其可以申请并上传名为 jupyter-notebook 的恶意snap包。以下是我们注册 jupyter-notebook snap名称并上传虚拟 "恶意 "软件包后的输出结果:
图 9:注册 "jupyter-notebook " snap名后的输出结果
我们可以观察到,命令未找到实用程序首先建议安装 snap 软件包,甚至比原始 APT 软件包更早。这种行为可能会误导用户安装 snap 软件包。
真正的危险在于这个问题的规模。单个恶意 snap 包冒充合法 APT 或 snap 包固然令人担忧,但如果攻击者系统性地利用 26% 的 APT 包命令,包括那些在 snap 存储中带有别名的命令,则可能造成毁灭性后果。
错别字攻击
除了匹配广泛使用的命令的确切名称,攻击者还可以利用错别字策略。这包括利用用户常见的排印错误。
例如,考虑一下如果用户不小心输入了 ifconfigg 而不是 ifconfig,会发生什么情况:
图 10:用户不小心输入了 "ifconfigg "而不是 "ifconfig",软件将其更正为 ifconfig
在上面的例子中,命令未找到软件包帮助用户纠正了错误,为输入错误的 ifconfig 命令推荐了 net-tools 软件包。然而,如果攻击者利用这些常见错误,注册一个带有错字的 snap,如 ifconfigg,情况就会变得更加棘手。
图 11:"command-not-found "建议使用恶意的 ifconfigg 软件包
如前所述,命令未找到实用程序通常会纠正用户,为输入错误的 ifconfig 命令推荐正确的 net-tools 软件包。但是,如果攻击者注册了一个名称为 ifconfigg 的snap包,command-not-found 会错误地将其与这个错误的命令匹配,并推荐恶意snap(如上图所示),完全绕过 net-tools 建议。
总结与缓解措施
攻击者利用未找到命令实用程序推荐自己的恶意 snap 软件包的风险是一个亟待解决的问题。真正的危险在于这个问题的潜在范围,攻击者能够从广泛使用的软件包中模仿数千条命令。过去 Snap Store 中出现恶意软件包的事例凸显了这一问题(参见参考文献:Snapcraft 论坛、The Next Web)。
目前仍不确定这些功能被利用的范围有多大,这突出表明了提高警惕和采取主动防御策略的紧迫性。
为防范此类威胁,用户和软件包维护者应采取多项预防措施:
- 用户应在安装前验证软件包的来源,检查维护者的可信度和推荐平台(是 snap 还是 APT)。
- 拥有别名的 Snap 开发人员应及时注册与其应用程序一致的相应名称,以防止滥用。
- 我们鼓励 APT 软件包的开发人员为其命令注册相关的 snap 名称,以预先防止攻击者冒充。
- Aqua 客户可以阻止在容器化工作负载中执行 APT 和 snap。运行时解决方案可以检测利用此问题产生的恶意行为。
[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)
赞赏
- [原创]物联网安全:基础篇 4124
- 威胁情报小课堂:阻止活跃勒索软件的感染 2177
- [翻译]发现利用 Facebook 和 MS 管理控制台实施的 Kimsuky APT 攻击 7061
- 威胁情报小课堂:LockBit Black 2053
- 威胁情报小课堂:Nitrogen 2079