跳转至

Dependency Confusion

Basic Information

In summary, a dependency confusion vulnerability occurs when a project is using a library with a misspelled name, inexistent or with an unspecified version and the used dependency repository allows to gather updated versions from public repositories.

  • Misspelled: Import reqests instead of requests
  • Inexistent: Import company-logging, an internal library which no longer exists
  • Unspecified version: Import an internal existent company-requests library , but the repo check public repos to see if there are greater versions.

Exploitation

Note

In all cases the attacker just need to publish a malicious package with name of libraries used by the victim company.

Misspelled & Inexistent

If your company is trying to import a library that isn't internal, highly probably the repo of libraries is going to be searching for it in public repositories. If an attacker has created it, your code and machines running is highly probably going to be compromised.

Unspecified Version

It's very common for developers to not specify any version of the library used, or specify just a major version. Then, the interpreter will try to download the latest version fitting those requirements. If the library is a known external library (like python requests), an attacker cannot do much, as he won't be able to create a library called requests (unless he is the original author). However, if the library is internal, like requests-company in this example, if the library repo allows to check for new versions also externally, it will search for a newer version publicly available. So if an attacker knows that the company is using the requests-company library version 1.0.1 (allow minor updates). He can publish the library requests-company version 1.0.2 and the company will use that library instead of the internal one.

AWS Fix

This vulnerability was found in AWS CodeArtifact (read the details in this blog post). AWS fixed this by allowing to specify if a library is internal or external, to avoid downloading internal dependencied from external repositories.

Finding Vulnerable Libraries

In the original post about dependency confusion the author searched for thousands of exposed package.json files containing javascript project’s dependencies.

工具

dependency check

检测人员可使用开源工具Dependency-Check对外部依赖库进行扫描，Dependency-Check是OWASP（Open Web Application Security Project）的一个实用开源程序，用于识别项目依赖项并检查是否存在任何已知的、公开披露的漏洞。Dependency-Check可以命令行形式单独使用，也可集成到各种主流的软件中使用，如Ant、Maven、Gradle、Jenkins、Sonar等。

首先，使用扫描工具Dependency-check对外部依赖库进行扫描，收集整理项目所用外部依赖库，可用Dependency-Check对其进行批量扫描。Dependency-check具体使用方法参见https://jeremylong.github.io/DependencyCheck/dependency-check-cli/arguments.html 。以下将介绍Dependency-Check的命令行使用方式，开发项目组也可将Dependency-Check集成到所使用的软件（如Ant、Maven、Gradle、Jenkins、Sonar等）中使用：

1、进入官网owasp.org/www-project-dependency-check/下载最新版本的Dependency-check，选择Command Line进行下载。下载完成后进行解压即可开始使用。

2、建议每次执行新的扫描任务之前，更新规则库，在命令行窗口进入Dependency-Check的bin目录下，输入更新命令即可完成规则库的更新：

Bash
dependency-check –updateonly

3、更新完成后，开始进行外部依赖库漏洞的扫描，常用扫描命令如下：

Bash
Dependency-check --project <project name> --scan <jar path> --out <result path> --format <XML/HTML/CSV/JSON/JUNIT/ALL> --disableCentral

4、打开命令行中的扫描结果存放路径，有多种不同格式的结果，使用“.csv”格式的文件，可方便对扫描结果进行初步整理，保留“DependencyName”、“Md5”、“CVE”、“Vulnerability”、“Severity”等必须项，简化表格，并且在表格中添加与后期修复相关的必须项。

扫描后的结果需人工排除误报，使用工具扫描出来的检测结果存在误报的情况，可能原因包括漏洞与所述组件无关、引发漏洞的方法未被调用、引发漏洞的配置未启用等。需要根据CVE官网上的漏洞介绍、官方漏洞说明结合源代码和修复方法人工进行逐一排查，确认所用组件是否存在扫描结果中所述漏洞，并确定每个漏洞的修复方法，组件安全风险复核是一件相当费时费力的工作。

References

  • https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
  • https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d