技术文章

软件开发人员、前国家预防和控制中心CLI团队工程经理达西•克拉克引导大家注意到国家预防机制注册网站上的一个缺口--他称之为"明显的混乱"。"

什么是显而易见的混淆? 

克拉克在他的 博客帖子 ,国家防范机制的一揽子清单在国家防范机制网站上公布 独立地 从它的油球的实际内容来看, 首次报告 在登记册旁边。由于清单和包是脱钩的,当依赖关系和清单与预期的大相径庭时,使用包的人就会产生"混淆"。 

作为一个简单的例子,克拉克创建了一套名为"国家防范机制"的概念验证包。 darcyclarke-manifest-pkg "根据不结盟运动网站, 0从属关系 没有许可证信息

但是,如果在(真实的)清单文件中快速查看一下,包.json,包在包中,就会发现另一种情况:

安装后,"达克赖克----显示----PKG"将明显地拉入 ‘sleepover’ 依赖性-克拉克也创造,事实上包是 许可证的 .

此外,我们看到该一揽子方案称之为 ‘express’ 从第一行可以看出,它列出的版本(3.0.0)与我们分析的实际版本(2.1.X)不同。

克拉克的虚拟软件包还运行了一个"安装"脚本--这在国家预防机制网站上再次没有披露,它展示了潜在的恶意行为,一个威胁参与者可以利用这些行为,例如 我们看到了时间 和 又一次 .

为什么重要?

在开发环境中,如果没有有效的设计文件系统工作流和工具到位,特别是在应用程序盲目信任应用程序显示而不是开放源代码包中包含的实际(脆弱或恶意)文件的情况下,显式混淆就会成为问题。

例如,一些安全工具可能选择获取和显示在npmjs.com网站上提供的信息,从而误导开发人员错误地认为包中包含的信息是错误的。 不同的 依赖性和许可证发放信息。

显而易见的困惑是什么让人担心的吗?

如果您完全依赖包清单和执行基于清单的扫描的安全工具中所包含的元数据,那么是的,您应该担心。这些信息往往充满了不准确之处,即使在非恶意的情况下也是如此。例如,当复制或分叉真正的项目时,新的当事方可能无法更新清单中的元数据信息。

所以他的超音速平台 单靠清单 .这并不是一个新问题,只是现在引起了人们的注意。当我们建造时 超声电话生命周期 和 超声式存储库防火墙 ,我们也创造了 高级二进制指纹(ABF) 这是一种专用的方法,用来查看扫描它们的包是"部署的",而不是"声明的"。"

通过ABF扫描,我们检查了所有文件的二进制指纹(类似于截断的SHA1哈希),而不仅仅是文件名和清单。ABF非常精确,因为它检查了构建后应用程序中包含的所有内容,包括任何嵌入式依赖关系。这意味着ABF扫描将永远不会返回其报告中的错误阳性。超声类型数据与发现漏洞的任何文件的组件指纹相关联。当报告漏洞时,是因为组件指纹在应用程序中。

通过提供对嵌入式依赖的准确评估,结果是一个全面的 《材料软件法案》 透明地代表第三方风险。ABF标识使用二进制、结构相似性、派生坐标和文件名称的加密散列。它甚至检测到重新命名或更改的组件,不管声明、不正确的标签或手动添加到代码库中。

例如,克拉克的POC包"达尔文----清单----PKG"被追踪为 sonatype-2023-2789 当用索尼打字机扫描的时候就会出现安全违规行为。包信息显示最合适的名称(不是"快速")和版本信息--与TAR.GZ文件一致:

此外,我们的报告显示了正确的许可证信息----而不是由npmj.com网站转发的信息:

如果克拉克的"过夜者"捆绑的依赖关系被拖入到您的开发项目中,并且包含任何安全漏洞、违规行为或我们的系统检测到的恶意代码 多用途/自动化 恶意软件检测引擎,它也会被标记和清楚显示在超声型产品.

如何处理明显的混乱?

由于索尼类型的生命周期和存储库防火墙是如何操作的,所以在默认情况下,他类型的客户和用户受到保护,不受"明显的混淆"。'

先前的错误报告[ 1 , 2 ]关于这个问题,国家防范机制显然没有采取任何行动。但这不一定是一个令人担忧的原因。

虽然在国家预防机制包中实际存在的和缺乏验证的情况下。正如克拉克指出的,它的明显声明可能带来潜在的问题--例如缓存中毒、意外依赖注入、恶意脚本的执行和版本降级攻击,风险最终取决于 什么的 你的安全工具信托。

如果你没有使用索尼打字机,检查你的工具,以确保它们不依赖于清单。如果是的话,来 与我们聊天 , 我们很乐意提供帮助,因为基于"清单"的扫描绝不是一个好主意。工具应该挖得更深。