CLOUD SECURITY LAB

轻信AI提供的CLI安装方法：从幻觉到幻觉劫持

—

by

cslab
in

AI的幻觉（hallucination）是指它以看似合理的方式回答与事实不符的内容的现象。在安装开发工具时，这个问题会变得更加直接。因为它不仅仅是误解说明，而是决定要在我的计算机上运行什么。

在安装三星云平台的CLI，即通过命令行操作服务的工具时，我也经历了这样的试错。我将AI推荐的个人GitHub上的scloud误认为是官方安装方法。然而，官方指南推荐的工具是scp-cli。从这次经验中得到的教训很简单：链接实际可以打开这一事实，并不能确认其官方性、最新性以及与我的环境的兼容性。

概念图，表达在执行AI推荐的工具之前检查其来源

特色图片：概念插图，并非实际工作界面或攻击场景。

仓库存在，但并非我寻找的官方指南

最初，我遵循了AI提供的scloud安装指南。我错误地将个人创建的GitHub仓库视为官方安装路径。在此过程中，我因旧版本、错误的配置方法和URL结构而吃了不少苦头。

问题不仅仅是几个命令字符不同。从一开始，就偏离了应该以哪个工具的说明为基准进行安装和配置。后来查阅官方文档才发现，基本指南是通过scp-cli执行的方式。

在这里，我不想说个人仓库本身就是问题。非官方工具如果符合目的，也可能很有用。但是，如果将非官方工具作为官方安装路径来介绍，用户就很难区分该工具支持的范围和当前服务的需求。没有证据表明该仓库是恶意的。本文的重点不在于评估管理员，而在于验证推荐的过程。

当AI给出的答案附带真实链接时，人们很容易感到安心。然而，“该仓库存在”和“它是符合我当前目的的官方工具”是不同的主张。这一次，我不得不确认后者。

官方文档中确认的安装和配置标准

在准备本文时，我于2026年10月21日直接阅读了三星云平台CLI通用官方文档。文档提供了Windows和Linux的下载链接，并指导在Linux上为下载的文件授予执行权限的命令如下：

chmod +x scp-cli

此命令是更改下载文件执行权限的步骤。它不替代验证文件来源的工作。下载的标准是从官方文档中针对不同操作系统的链接开始。我查阅的页面没有提供macOS的下载指南。因此，我不会补充说相同的文件可以直接在iMac上运行，或者有单独的安装命令。

配置也不是可以从工具名称推测出来的。官方文档将执行环境定义为JSON文件，在Linux中指导使用~/.scp/cli-config.json，在Windows中指导使用用户主文件夹下的.scp/cli-config.json。核心项目是authurl、accesskey、accesssecretkey、defaultscpregion，在使用临时凭证时还有一个可选项目session_token。实际的认证值不包含在本文中。

特别是auth_url因目标环境而异。同一页面的官方表格中，for Samsung是https://iam.s.samsungsdscloud.com/v1/endpoints，for Sovereign是https://iam.g.samsungsdscloud.com/v1/endpoints，for Enterprise是https://iam.e.samsungsdscloud.com/v1/endpoints。这就是为什么不能将示例中写的一个URL复制为所有环境的正确答案。默认区域也必须与实际目标环境一起确认。

从官方文档中确认安装文件和设置，并接着查询API版本和端点的确认顺序

图1. 基于官方文档重新构建的确认顺序。依据：CLI Common。以下查询并非在实际账户中执行的结果。

文档指导的服务API版本查询的基本命令如下：

scp-cli versions show

官方示例结果中包含Region Name、Service Name、Version、Status、Endpoint列。这可以作为参考，以确认安装的工具处理哪个区域的哪个服务端点和API版本。文档中还提供了--region-name、--service、--status、--timeout等可选参数。

这里的Version是服务API版本。不应与CLI可执行文件本身的发布版本混淆。我查阅的Common页面没有找到检查可执行文件版本的专用命令。因此，我不会像回忆其他熟悉的CLI那样猜测--version等命令，而是保留了发布版本必须从官方发布信息和该文件的支持指南中单独确认的局限性。

每个命令的选项可以通过官方文档中提供的帮助来确认。例如，scp-cli iam policy create --help是查看策略创建命令帮助的示例。本文中没有执行策略创建命令本身。由于没有执行安装文件、认证和实际端点查询，因此不应将其解读为安装成功经验或实测结果。

错误推荐导致供应链风险的节点

这次经验是兼容性和配置问题，但相同的信任方式可能导致安全问题。软件供应链包括我运行的程序在哪里创建以及通过什么路径传输。复制安装命令的那一刻，AI推荐的名称和分发源就进入了我的执行环境。

根据工具的不同，安装过程中可能会执行脚本，之后运行的程序也可能访问文件或网络。如果在未确认来源的情况下授予广泛的权限或认证信息，错误推荐的影响可能会更大。这并不意味着所有非官方工具都是危险的。这意味着在将代码引入我的环境之前，有必要确认分发主体。

更具意图性地利用这种风险的方式是幻觉劫持（hallucination squatting），在包的语境中通常称为“slopsquatting”。这是一种攻击者注册AI虚构的、原本不存在的包或依赖项名称，并以此名称分发恶意代码的技术。如果用户相信AI的推荐并安装，最初没有实体的名称可能会链接到攻击者创建的代码。

这次scloud的经验本身并非幻觉劫持攻击案例。它是一个错误推荐了已存在的非官方仓库的案例，并未确认攻击者抢占了AI虚构的包名，也未确认恶意代码或损害。连接这两个案例的是“将AI的推荐作为执行目标，而不进行来源验证”的信任方式。

比较图，说明本次经验是现有非官方工具的错误推荐，而幻觉劫持是攻击者注册虚构包名的独立流程

图2. 区分用户经验和研究中描述的攻击机制的原始图示。攻击部分基于Lasso研究和TrendAI研究重新构建。

研究揭示的是可能性和重复性

Lasso Security 2024年的研究探讨了AI推荐不存在的包，以及这些名称可能导致实际安装尝试的问题。核心在于，不仅仅是错误答案的存在，更在于错误答案中出现的名称可能是攻击者可以抢占的分发名称。

USENIX Security 2025的原始研究分析了16个模型生成的576,000个代码样本。研究人员报告称，包幻觉是多种模型和设置中出现的现象。这表明不能仅仅将其视为特定用户提问错误所致。然而，当时研究条件下的结果不应被重新解读为今天所有AI工具的错误率或实际攻击成功率。

名称和机制也需要区分。TrendAI的自身研究在slopsquatting的名称下解释了虚构包名与恶意注册的联系。参与命名讨论的Andrew Nesbitt的文章记录了该名称在2025年4月与Seth Larson的对话中出现的经过。在命名之前，利用包幻觉的问题就已经在研究中。

攻击者注册名称后，即使只检查“包是否存在”也能通过。因此，仅仅确认存在是不够的。必须确认该包是否是原始项目的官方分发物。

下次安装前要确认的清单

与其不使用AI，不如在执行前确定要确认的标准，这更具实践性。从本次经验中总结出的必要标准如下：

  • 从官方文档开始。 不要首先相信AI提供的仓库链接，而是确认它是否是服务官方文档链接的分发源。搜索排名或星级数量并非官方分发的证明。
  • 区分产品名、包名、命令名。 不要将本案例中的scloud和scp-cli等目的相似的工具视为相同。安装名称和实际执行命令可能不同。
  • 确认当前支持范围。 区分操作系统、发布时间与支持状态、服务API版本、区域、认证环境。不要仅凭旧的README就断定与当前服务的兼容性。
  • 安装前检查执行内容。 对于直接执行远程脚本的命令或需要管理员权限的步骤，请确认其原因和内容。如果提供了官方签名·哈希，请进行验证，但哈希也应从可信路径获取。
  • 延迟授予秘密和权限。 首次确认的工具不要立即输入生产环境的认证值。在完成必要的审查后，以最小权限使用，不要将配置文件或密钥粘贴到AI问题或公开日志中。
  • 团队中重复使用已验证的发布物。 记录已批准的来源和版本，并在可能的生态系统中管理锁定文件和哈希。这些是持续使用已审查发布物的手段，而不是自动判断是否恶意的保证书。

可以这样请求AI：“请先显示官方文档链接和实际引用依据，并区分包名、执行命令名、支持的操作系统、配置路径。请不要猜测未确认的命令。”收到答案后，必须直接对照链接和正文。仅仅再次询问同一个AI并不能完成独立验证。

继续使用AI，但要确认执行依据

AI可以帮助快速理解文档结构或配置项的含义。我不想因为这次经验而否定这种帮助。但是，如果将看似合理的解释视为官方支持的证据，可能会长期停留在错误的起点。

我所经历的是将非官方scloud指南误认为是官方路径而导致的试错。更进一步，还存在幻觉劫持的风险，即攻击者用实际的发布物填充AI虚构的名称。这就是为什么在执行一行安装命令之前，除了“名称是否存在”之外，还要确认“谁分发它，以及它是否适合我的环境”的原因。

参考资料

Comments

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注