packj - Packj stops :zap: Solarwinds-, ESLint-, and PyTorc

项目说明

<img src=" width="45"/>&nbsp;<span style="font-size: 42px"> Packj flags malicious/risky open-source packages</span>

*Packj* (pronounced package) is a tool to help to mitigate software supply chain attacks. It can detect malicious, , abandoned, typo-squatting, and other "risky" packages from popular open-source package registries, such as NPM, RubyGems, and PyPI. It can be easily customized to minimize noise. Packj started as a PhD research project and is currently being de under go.

![GitHub Stars]() ![]() ![Prs Welcome]() !Github Commit Activity ![Discord]() ![License: AGPL v3]() ![Docker]()

> Note
Self-hosted Packj webserver and several integrations coming later this month :punch: Watch this repo to stay up to date.

!demo video

Contents #

* Get started - a as Docker image, GitHub Action, and packages
* Functionality - deep static/dynamic code analysis and sandboxing
* Supported ecosystems - NPM, PyPI, Rubygems, PHP, Rust
* Our story - started as a PhD research project and is backed by go
* Why Packj - existing C ASSUME code is BENIGN and not analyze its behavior
* Customization - turn off alerts as per your threat model to reduce noise
* Malware found - reported over 70 malicious PyPI and RubyGems packages
* Talks and - presentations from PyCon, OpenSourceSummit, BlackHAT
* Project roadmap - view or suggest new features; join our discord channel
* Team and collaboration - lead by Cybersecurity researchers from academia/industry
* FAQ - supported package managers, commonly asked questions on techniques, and more

Get started #

We support multiple deployment models:

1. GitHub runner

Use Packj to audit dependencies in pull requests.

View on GitHub marketplace. Example PR run.

2. Docker image (recommended)

The quickest way to try/test Packj is using Docker. Podman is also supported for containerized (isolated) runs.

3. Source repo

Clone this repo,

Install dependencies

Start with help:

Supported ecosystems #

Packj can packages from NPM, PyPI, Rust, PHP, and Rubygems package registries. Rust and PHP support is WIP. We're actively adding support for registries.
It also supports local (unpublished) NPM and PyPI packages.

| Registry | Ecosystem | Supported |
| --------- | ---------- | ------------------ |
| NPM | Ja | :white_check_mark: |
| PyPI | Python | :white_check_mark: |
| Cargo | Rust | :white_check_mark: |
| Rubygems | Ruby | :white_check_mark: |
| Packagist | PHP | :white_check_mark: |
| Docker | Docker | :x: |
| Nuget | .NET | :white_check_mark: |
| Maven | Java | :white_check_mark: |
| Cocoapods | Swift | :x: |

Functionality #

Packj offers the following tools:

* Audit - to vet a package for "risky" attributes.
* Sandbox - for safe installation of a package.

Auditing a package ##

Packj audits open-source software packages for "risky" attributes that make them to supply chain attacks. For instance, packages with expired email domains (lacking 2FA), large release time gap, sensitive APIs or access permissions, etc. are flagged as risky.

Auditing the following is supported:

By default, audit only performs static code analysis to detect risky code. You can paas -t or --trace flag to perform dynamic code analysis as well, which will install all requested packages under strace and monitor install-time behavior of packages. Please see the example output below.

<details>
<summary><h4>Show example run/output</h4></summary>

$ docker run -v /tmp:/tmp/packj -it ossillate/packj:latest audit --trace -p npm:browserify

[+] Fetching 'browserify' from npm..........PASS [ver 17.0.0]
[+] Checking package description.........PASS [browser-side require() the node way]
[+] Checking release history.............PASS [484 (s)]
[+] Checking ........................RISK [702 days old]
[+] Checking release time gap............PASS [68 days since last release]
[+] Checking author.........................PASS []
[+] Checking email/domain .......RISK [expired author email domain]
[+] Checking readme.........................PASS [26838 bytes]
[+] Checking homepage.......................PASS []
[+] Checking downloads......................PASS [2M weekly]
[+] Checking repo URL.......................PASS []
[+] Checking repo data...................PASS [stars: 14189, forks: 1244]
[+] Checking if repo is a forked copy....PASS [original, not forked]
[+] Checking repo description............PASS [browser-side require() the node.js way]
[+] Checking repo activity...............PASS [commits: 2290, contributors: 207, tags: 413]
[+] Checking for CVEs.......................PASS [none found]
[+] Checking dependencies...................RISK [48 found]
[+] Downloading package from npm............PASS [163.83 KB]
[+] Analyzing code..........................RISK [needs 3 perm(s): decode,codegen,file]
[+] Checking files/funcs....................PASS [429 files (383 .js), 744 funcs, LoC: 9.7K]
[+] Installing package and tracing code.....PASS [found 5 process,1130 files,22 network syscalls]
=============================================
[+] 5 risk(s) found, package is undesirable!
=> Complete report: /tmp/packj_54rbjhgm/report_npm-browserify-17.0.0_hlr1rhcz.json
{
"undesirable": [
"old package: 702 days old",
"invalid or no author email: expired author email domain",
"generates new code at runtime",
"reads files and dirs",
"forks or exits OS processes",
]
}
</details>

> WARNING: since packages could execute malicious code during installation, it is recommended to ONLY use -t or --trace when running inside a Docker container or a Machine.

Audit can also be performed in Docker/Podman containers. Please find details on risky attributes and how to use at Audit README.

Sandboxed package installation ##

Packj offers a lightweight sandboxing for safe installation of a package. Specifically, it prevents malicious packages from exfiltrating sensitive data, accessing sensiti (e.g., SSH keys), and persisting malware.

It sandboxes install-time scripts, including any nati. It uses strace (i.e., NO required).

Please find details on the sandboxing mechanism and how to use at Sandbox README.

<details>
<summary><h4>Show example run/output</h4></summary>

$ python3 main.py sandbox gem install o

Fetching: o.59.1.gem (100%)
Install hooks by running o --install in your Git repository
Successfully installed o.59.1
Parsing documentation for o.59.1
Installing ri documentation for o.59.1

#############################
# Review summarized activity
#############################

[+] Network connections
[+] DNS (1 IPv4 addresses) at port 53 [rule: ALLOW]
[+] rubygems.org (4 IPv6 addresses) at port 443 [rule: IPv6 rules not supported]
[+] rubygems.org (4 IPv4 addresses) at port 443 [rule: ALLOW]
[+] Filesystem changes
/
└── home
└── ubuntu
└── .ruby
├── gems
│ ├── iniparse-1.5.0 [new: DIR, 15 files, 46.6K bytes]
│ ├── rexml-3.2.5 [new: DIR, 77 files, 455.6K bytes]
│ ├── o.59.1 [new: DIR, 252 files, 432.7K bytes]
│ └── childprocess-4.1.0 [new: DIR, 57 files, 141.2K bytes]
├── cache
│ ├── iniparse-1.5.0.gem [new: FILE, 16.4K bytes]
│ ├── rexml-3.2.5.gem [new: FILE, 93.2K bytes]
│ ├── childprocess-4.1.0.gem [new: FILE, 34.3K bytes]
│ └── o.59.1.gem [new: FILE, 84K bytes]
├── specifications
│ ├── rexml-3.2.5.gemspec [new: FILE, 2.7K bytes]
│ ├── o.59.1.gemspec [new: FILE, 1.7K bytes]
│ ├── childprocess-4.1.0.gemspec [new: FILE, 1.8K bytes]
│ └── iniparse-1.5.0.gemspec [new: FILE, 1.3K bytes]
├── bin
│ └── o [new: FILE, 622 bytes]
└── doc
├── iniparse-1.5.0
│ └── ri [new: DIR, 119 files, 131.7K bytes]
├── rexml-3.2.5
│ └── ri [new: DIR, 836 files, 841K bytes]
├── o.59.1
│ └── ri [new: DIR, 1046 files, 1.5M bytes]
└── childprocess-4.1.0
└── ri [new: DIR, 272 files, 297.8K bytes]

[C]ommit all changes, [Q|q]uit & discard changes, [L|l]ist details:
</details>

Our story

TL;DR Packj started as a PhD research project. It is backed by go grants.

<details>
<summary><h4>Show long answer</h4></summary>

Packj started as an academic research project. Specifically, the static code analysis techniques used by Packj are based on cutting-edge Cybersecurity research: MalOSS project by our research group at Georgia Tech.

<a href=" target="_blank">
<img src=" width="300" alt="academic paper">
</a>

Packj is backed by generous grants from NSF, GRA, and ALInnovate.

</details>

Why Packj

TL;DR The state-of-the-art scanners assume that the third-party open-source code is BENIGN. Therefore, all such tools ONLY address threats from accidental programming bugs in benign code (a.k.a. CVEs such as Log4J). They DO NOT protect against Solarwinds-like modern software supply-chain attacks from deliberately bad (a.k.a. malicious) code that is propagated by bad actors using new in the supply channel, including dependency confusion, typo-squatting, protestware (sabotaging), account hijacking, and social engineering. A recent (Dec'22) example is PyTorch package that was compromised using dependency confusion (no C).

Packj not only audits for CVEs, but also performs deep static+dynamic code analysis as well as metadata checks to detect any "risky" behavior and attributes, such as spawning of shell, use of SSH keys, mismatch of GitHub code code (pro), lack of 2FA, and several more. Such insecure attributes do not qualify as as CVEs, which is why none of the existing tools can flag them. Packj can flag malicious, typo-squatting, abandoned, , and other insecure dependencies (weak links) in your software supply chain.

<details>
<summary><h4>Show long answer</h4></summary>

The current software supply chain threat model assumes that the third-party open-source code is benign, and therefore, security are only tracked for accidental programming bugs (a.k.a. CVEs). As such, all existing open-source scanners ONLY report publicly known CVEs and address threats from accidental bugs in benign code.

A typical example of an accidental programming bug is a missing bounds check on user input, which makes the code to buffer o attacks. Real-world popular examples include Log4J and HeartBleed. Attackers need to develop an exploit to trigger CVEs (e.g., a crafted TCP/IP packet in case of HeartBleed or a numerically high input to cause buffer o). CVEs can be fixed by patching or upgrading to a newer of the library (e.g., newer of Log4J fixes the CVE).

The modern software supply chain threat landscape shifted after the Solarwinds attack. Bad actors ha new , but this time in the supply channel, not code. These new such as dependency confusion, typo-squatting, protestware (sabotaging), account hijacking, and social engineering are being exploited to propagate malware. Thousands of compromised NPM/PyPI/Ruby packages have been reported.

In contrast to CVEs, malware is deliberately bad (a.k.a. malicious) code. Moreover, malware itself is an exploit and cannot be patched or fixed by upgrading to a newer . For example, dependency confusion attack was intentionally malicious; it did not exploit any accidental programming bug in the code. Similarly, an author of popular package sabotaging their own code to protest against the war is very much intentional and does not exploit any CVEs. Typo-squatting is another attack that bad actors use to propagate malware in popular open-source package registries: it exploits typos and inexperience of devs, not accidental programming bugs or CVEs in the code.

Existing scanners FAIL to detect these Solarwinds-like modern software supply-chain attacks from deliberately (malicious) code. These tools simply scan the source code for open-source dependencies, compile a list of all dependencies being used, and look each <dependency-NAME, dependency-> up in a database (e.g., NVD) to report affected package (e.g., of Log4J, LibSSL affected by HeartBleed).

Packj not only audits for CVEs, but also performs deep static+dynamic code analysis as well as metadata checks to detect any "risky" behavior and attributes, such as spawning of shell, use of SSH keys, mismatch of GitHub code code (pro), lack of 2FA, and several more. Such insecure attributes do not qualify as as CVEs, which is why none of the existing tools can flag them. Packj can flag malicious, typo-squatting, abandoned, , and other insecure dependencies (weak links) in your software supply chain. Please read more at Audit README
</details>

Customization #

Packj can be easily customized (zero noise) to your threat model. Simply add a .packj.yaml file in the top dir of your repo/project and reduce alert fatigue by commenting out unwanted attributes.

Malware found #

We found over 40 and 20 malicious packages on PyPI and Rubygems, respectively using this tool. A number of them been taken down. Refer to an example below:

<details>
<summary><h4>Show example malware</h4></summary>

$ python3 main.py audit pypi:krisqian

[+] Fetching 'krisqian' from pypi...OK [ver 0.0.7]
[+] Checking ...OK [256 days old]
[+] Checking release history...OK [7 (s)]
[+] Checking release time gap...OK [1 days since last release]
[+] Checking author...OK []
[+] Checking email/domain ...OK []
[+] Checking readme...ALERT [no readme]
[+] Checking homepage...OK []
[+] Checking downloads...OK [13 weekly]
[+] Checking repo_url URL...OK [None]
[+] Checking for CVEs...OK [none found]
[+] Checking dependencies...OK [none found]
[+] Downloading package 'KrisQian' (ver 0.0.7) from pypi...OK [1.94 KB]
[+] Analyzing code...ALERT [needs 3 perms: process,network,file]
[+] Checking files/funcs...OK [9 files (2 .py), 6 funcs, LoC: 184]
=============================================
[+] 6 risk(s) found, package is undesirable!
{
"undesirable": [
"no readme",
"only 45 weekly downloads",
"no source repo found",
"generates new code at runtime",
"fetches data over the network: ['KrisQian-0.0.7/setup.py:40', 'KrisQian-0.0.7/setup.py:50']",
"reads files and dirs: ['KrisQian-0.0.7/setup.py:59', 'KrisQian-0.0.7/setup.py:70']"
]
}
=> Complete report: pypi-KrisQian-0.0.7.json
=> View pre- package report at
</details>

Packj flagged KrisQian (v0.0.7) as suspicious due to absence of source repo and use of sensitive APIs (network, code generation) during package installation time (in setup.py). We decided to take a deeper look, and found the package malicious. Please find our detailed analysis at

More examples of malware we found are listed at Please reach out to us at for full list.

Resources #

To learn more about Packj tool or open-source software supply chain attacks, refer to our

![PyConUS'22 Video]()
![OSSEU'22 Video]()
![NULLCON'22 Video]()

Feature roadmap #

* Add Rust analyzer. Rust is a work in progress.
* Add functionality to detect several (TODO) "risky" code as well as metadata attributes.
* Self-hosted Packj webserver and several useful integrations (e.g., Gitlab runner)

Watch :eyes: this repo to stay up to date.

Have a feature or support request? Please visit our GitHub discussion page or join our discord community for discussion and requests.

Team and contributors #

Packj has been de by Cybersecurity researchers at Ossillate Inc. and external collaborators to help de mitigate risks of supply chain attacks when sourcing untrusted third-party open-source software dependencies. We thank our de and collaborators. Show your appreciation by giving us a :star: if you like our work.

Founding members:
* Ashish Bijlani
* Devdutt Patnaik
* Ajinkya Rajput

We welcome code contributions with open arms. See CONTRIBUTING.md guidelines. Found a bug? Please open an issue. Refer to our SECURITY.md guidelines to report a security issue.

FAQ #

<details>
<summary><b>What Package Managers (Registries) are supported?</b></summary>

Packj can currently vet NPM, PyPI, and RubyGems packages for "risky" attributes. We are adding support for Rust.

</details>

<details>
<summary><b>What techniques does Packj employ to detect risky/malicious packages?</b></summary>

Packj uses static code analysis, dynamic tracing, and metadata analysis for comprehensi. Static analysis alone is not sufficient to flag sophisticated malware that can hide itself better using code obfuscation. Dynamic analysis is performed by installing the package under strace and monitoring it's runtime behavior. Please read more at Audit README.

</details>

<details>
<summary><b>Does it work on obfuscated calls? For example, a base 64 encrypted string that gets decrypted and then passed to a shell?</b></summary>

This is a very common malicious behavior. Packj detects code obfuscation as well as spawning of shell commands (exec system call). For example, Packj can flag use of getattr() and eval() API as they indicate "runtime code generation"; a de can go and take a deeper look then. See main.py for details.

</details>

项目信息

开发语言：Python

Star 数：693

技术要点

该项目属于病毒分析方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Packj stops :zap: Solarwinds-, ESLint-, and PyTorch-like attacks by flagging malicious/vulnerable open-source dependencies ("weak links") in your software supply-chain展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。