用于检查依赖配置中引用的私有包名称是否存在未认领的命名空间,支持 Python(pypi)requirements.txt、JavaScript(npm)package.json、PHP(composer)composer.json 或 MVN(maven)pom.xml。
2021年2月9日,安全研究员 Alex Birsan 发表了一篇文章,涉及多种编程语言生态系统中依赖管理工具存在的不同解析顺序缺陷。
微软发布了一份白皮书,描述了缓解影响的方法,但根本原因仍然存在。
confused 只是读取应用的依赖定义文件,并检查文件中每个依赖项在公共包仓库中的存在情况。它会报告所有在公共仓库中未找到的包名称——这种状态意味着该包可能容易受到此类攻击,尽管该攻击向量尚未被利用。
但这并不意味着应用尚未被积极利用。如果你知道自己的软件使用了私有包仓库,应确保私有包的命名空间已被可信方(通常是你自己或你的公司)认领。
某些包生态系统(如 npm)有“作用域”的概念,可以是私有的或公共的。简单来说,这是一个带有上级命名空间的作用域。作用域本身在公共环境中不可见,这意味着 confused 无法可靠地检测它是否已被认领。如果你的应用使用了带作用域的包名,应确保公共仓库中已有可信方认领了该作用域名。
或
如果你已安装较新版本的 go 编译器:go get -u github.com/visma-prodsec/confused(同样的命令可用于更新)
或
git clone https://github.com/visma-prodsec/confused ; cd confused ; go get ; go build
用法:
confused [-l 语言名] 依赖文件名.ext
confused 参数说明:
-l 字符串
包仓库系统。可选值:"pip", "npm", "composer", "mvn", "rubygems"(默认 "npm")
-s 字符串
已知安全命名空间的逗号分隔列表。支持通配符
-v 详细输出
./confused -l pip requirements.txt
发现以下包在公共包仓库中不可用:
[!] internal_package1
./confused -l npm package.json
发现以下包在公共包仓库中不可用:
[!] internal_package1
[!] @mycompany/internal_package1
[!] @mycompany/internal_package2
# 当 @mycompany 私有作用域已在 npm 中注册时,使用 -s 参数
./confused -l npm -s '@mycompany/*' package.json
发现以下包在公共包仓库中不可用:
[!] internal_package1
./confused -l mvn pom.xml
发现以下包在公共包仓库中不可用:
[!] internal
[!] internal/package1
[!] internal/_package2
./confused -l rubygems Gemfile.lock
发现以下包在公共包仓库中不可用:
[!] internal
[!] internal/package1
[!] internal/_package2