packj
Rules and placeholder for more upcoming checks
Packj (ausgesprochenes Paket) ist ein Tool, mit dem Software -Lieferkettenangriffe gemindert werden können. Es kann böswillige, verletzliche, verlassene, tippflichtige und andere "riskante" Pakete aus beliebten Open-Source-Paketregistern wie NPM, Rubygems und PYPI erkennen. Es kann leicht angepasst werden, um das Geräusch zu minimieren. Packj startete als Doktorand und wird derzeit unter verschiedenen Regierungszuschüssen entwickelt.
Beachten Sie, dass selbst gehostete Packj-Webserver und mehrere Integrationen später in diesem Monat kommen? Sehen Sie sich dieses Repo an, um auf dem Laufenden zu bleiben.
Wir unterstützen mehrere Bereitstellungsmodelle:
Verwenden Sie Packj, um Abhängigkeiten in Pull -Anfragen zu prüfen.
- name : Packj Security Audit
uses : ossillate-inc/[email protected]
with :
# TODO: replace with your dependency files in the repo
DEPENDENCY_FILES : pypi:requirements.txt,npm:package.json,rubygems:Gemfile
REPO_TOKEN : ${{ secrets.GITHUB_TOKEN }}Blick auf den Github -Marktplatz. Beispiel PR Run.
Der schnellste Weg, um Packj zu versuchen/zu testen, ist Docker. Podman wird auch für Container (isolierte) Läufe unterstützt.
docker run -v /tmp:/tmp/packj -it ossillate/packj:latest --help
Klonen Sie dieses Repo,
git clone https://github.com/ossillate-inc/packj.git && cd packj
Abhängigkeiten installieren
bundle install && pip3 install -r requirements.txt
Beginnen Sie mit Hilfe:
python3 main.py --help
Packj kann publizierte Pakete von NPM-, PYPI-, Rost-, PHP- und RubyGems -Paketregistern prüfen. Rost- und PHP -Unterstützung ist WIP. Wir fügen aktiv Unterstützung für Registrien hinzu. Es unterstützt auch die Überprüfung lokaler (unveröffentlichter) NPM- und PYPI -Pakete.
| Registrierung | Ökosystem | Unterstützt |
|---|---|---|
| NPM | JavaScript | ✅ |
| Pypi | Python | ✅ |
| Ladung | Rost | ✅ |
| Rubygemems | Rubin | ✅ |
| Packagistin | Php | ✅ |
| Docker | Docker | |
| Nuget | .NETTO | ✅ |
| Maven | Java | ✅ |
| Cocoapods | Schnell |
Packj bietet die folgenden Tools an:
Packj Audits Open-Source-Softwarepakete für "riskante" Attribute, die sie für Lieferkettenangriffe anfällig machen. Beispielsweise werden Pakete mit abgelaufenen E -Mail -Domänen (ohne 2FA), Zeitlücke mit großer Freisetzung, sensible APIs oder Zugriffsberechtigungen usw. als riskant gekennzeichnet.
Die Prüfung der folgenden Prüfung wird unterstützt:
python3 main.py audit -p pypi:requests rubygems:overcommitpython3 main.py audit -f npm:package.json pypi:requirements.txt Standardmäßig führt audit nur eine statische Codeanalyse durch, um riskante Code zu erkennen. Sie können das Flag PaaS -t oder --trace auch dynamische Codeanalyse durchführen, wodurch alle angeforderten Pakete unter Strace und Monitor Install -Time -Verhalten von Paketen installiert werden. Bitte beachten Sie die Beispielausgabe unten.
$ 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 version(s)]
[+] Checking version........................RISK [702 days old]
[+] Checking release time gap............PASS [68 days since last release]
[+] Checking author.........................PASS [[email protected]]
[+] Checking email/domain validity.......RISK [expired author email domain]
[+] Checking readme.........................PASS [26838 bytes]
[+] Checking homepage.......................PASS [https://github.com/browserify/browserify#readme]
[+] Checking downloads......................PASS [2M weekly]
[+] Checking repo URL.......................PASS [https://github.com/browserify/browserify]
[+] 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",
]
}
WARNUNG: Da Pakete während der Installation einen böswilligen Code ausführen könnten, wird empfohlen, nur
-toder--tracezu verwenden, wenn Sie in einem Docker -Container oder einer virtuellen Maschine ausgeführt werden.
Audit kann auch in Docker/Podman -Containern durchgeführt werden. Weitere Informationen zu riskanten Attributen finden Sie unter Audit Readme.
Packj bietet ein leichtes Sandboxing für eine safe installation eines Pakets. Insbesondere verhindert es, dass böswillige Pakete aus dem Exfiltrieren sensibler Daten, dem Zugriff auf sensible Dateien (z. B. SSH -Tasten) und anhaltenden Malware zugreifen.
Es sandkäfeln Time-Skripte, einschließlich einer nativen Einführung. Es verwendet Strace (dh kein VM/Container erforderlich).
Weitere Informationen zum Sandboxing -Mechanismus finden Sie in Sandbox Readme.
$ python3 main.py sandbox gem install overcommit
Fetching: overcommit-0.59.1.gem (100%)
Install hooks by running `overcommit --install` in your Git repository
Successfully installed overcommit-0.59.1
Parsing documentation for overcommit-0.59.1
Installing ri documentation for overcommit-0.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]
│ ├── overcommit-0.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]
│ └── overcommit-0.59.1.gem [new: FILE, 84K bytes]
├── specifications
│ ├── rexml-3.2.5.gemspec [new: FILE, 2.7K bytes]
│ ├── overcommit-0.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
│ └── overcommit [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]
├── overcommit-0.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:
TL; Dr. Packj startete als Doktorand. Es wird durch verschiedene staatliche Zuschüsse unterstützt.
Packj startete als akademisches Forschungsprojekt. Insbesondere basieren die von Packj verwendeten statischen Code-Analysetechniken auf der modernen Cybersicherheitsforschung: MaloS-Projekt unserer Forschungsgruppe bei Georgia Tech.
Packj wird von großzügigen Zuschüssen von NSF, GRA und Alinnovate unterstützt.
TL; Dr. Die hochmodernen Sicherheitslagerscanner gehen davon aus, dass der Open-Source-Code von Drittanbietern gutartig ist. Daher behandeln alle dieser Tools nur Bedrohungen von zufälligen Programmierfehler in gutartigen Code (auch bekannt als CVEs wie Log4j). Sie schützen nicht vor solarwind-ähnlichen modernen Software-Versorgungskettenangriffen aus absichtlich schlechten (alias böswilligen) Code, der von schlechten Akteuren ausgebaut wird, die neue Schwachstellen im Versorgungskanal verwenden, einschließlich Abhängigkeitsverwirrung, Tippfehler, Protestware (Sabotaging), Account-Entstehung und sozialer Ingenieurwesen. Ein aktuelles Beispiel (Dec'22) ist ein Pytorch -Paket, das mithilfe von Abhängigkeitskonstusionsfälligkeit (kein CVE zugewiesen) beeinträchtigt wurde.
Packj Audits für CVEs, sondern führt auch eine tiefe statische+dynamische Codeanalyse sowie Metadatenüberprüfungen durch, um jegliches "riskante" Verhalten und Attribute wie das Laichen von Shell, die Verwendung von SSH -Schlüsseln, das Missverhältnis von GitHub -Code im Verpackung (bewährte), Mangel von 2FA und mehrere mehr zu erkennen. Solche unsicheren Attribute qualifizieren sich nicht als CVEs, weshalb keiner der vorhandenen Tools sie kennzeichnen kann. Packj kann in Ihrer Software-Lieferkette böswillige, tippflichtige, verlassene, verletzliche und andere unsichere Abhängigkeiten (schwache Verbindungen) markieren.
Das derzeitige Bedrohungsmodell der Software-Supply-Chain-Bedrohung geht davon aus , dass der Open-Source-Code von Drittanbietern gutartig ist und die Sicherheitslücken nur für versehentliche Programmierfehler (auch bekannt als CVE) verfolgt werden. Daher melden alle bestehenden Open-Source-Scanner-Scanner nur öffentlich bekannte CVEs und befassen sich mit Bedrohungen von versehentlichen Fehler im gutartigen Code.
Ein typisches Beispiel für einen zufälligen Programmierfehler ist eine fehlende Grenzen, die die Benutzereingabe überprüft, wodurch der Code anfällig für Pufferüberlaufangriffe ist. Zu den praktischen beliebten Beispielen gehören Log4j und Heartbleed. Angreifer müssen einen Exploit entwickeln, um CVEs auszulösen (z. B. ein gefertigtes TCP/IP -Paket bei Heartbleed oder einem numerisch hohen Eingang, um einen Pufferüberlauf zu verursachen). CVEs können durch Patching oder Upgrade auf eine neuere Version der Bibliothek behoben werden (z. B. neuere Version von LOG4J behebt den CVE).
Die moderne Bedrohung der Software Supply Chain -Bedrohung hat sich nach dem Angriff des Solarblasens verschoben . Schlechte Schauspieler haben neue Schwachstellen gefunden, diesmal jedoch im Versorgungskanal, nicht im Code. Diese neuen Schwachstellen wie Abhängigkeitsverwirrung, Tippfehler, Protestware (Sabotaging), Account-Entführungen und Social Engineering werden ausgenutzt, um Malware zu verbreiten. Es wurden Tausende von gefährdeten NPM/PYPI/Ruby -Paketen berichtet.
Im Gegensatz zu CVEs ist Malware absichtlich schlechter (auch bekannt als bösartiger) Code. Darüber hinaus ist Malware selbst ein Exploit und kann nicht durch Upgrade auf eine neuere Version gepatcht oder behoben werden. Zum Beispiel war der Abhängigkeitsverwirrungsangriff absichtlich bösartig; Es hat keinen zufälligen Programmierfehler im Code ausnutzt. In ähnlicher Weise ist ein Autor des populären Pakets, der seinen eigenen Kodex sabotiert, gegen den Krieg zu protestieren, sehr beabsichtigt und nutzt keine CVEs aus. Tippfehler ist ein weiterer Angriffsvektor, mit dem schlechte Akteure Malware in beliebten Open-Source-Paketregistern verbreiten: Es nutzt Tippfehler und Unerfahrenheit von Entwicklern, nicht in versehentlichem Programmierfehler oder CVEs im Code.
Bestehende Scanner erkennen diese Solarwinds-ähnlichen modernen Software-Versorgungskettenangriffe aus absichtlich verletzlicher (böswilliger) Code nicht . Diese Tools scannen einfach den Quellcode für Open-Source-Abhängigkeiten, kompilieren eine Liste aller verwendeten Abhängigkeiten und sehen jeden <abhängigkeitsnamen, Abhängigkeitsversion> in einer Datenbank (z. B. NVD), um betroffene Paketversionen (z. B. gefährdete Version von Log4J, LibSL-Version betroffen zu melden, die von Heartbleed-Version betroffen ist).
Packj Audits für CVEs, sondern führt auch eine tiefe statische+dynamische Codeanalyse sowie Metadatenüberprüfungen durch, um jegliches "riskante" Verhalten und Attribute wie das Laichen von Shell, die Verwendung von SSH -Schlüsseln, das Missverhältnis von GitHub -Code im Verpackung (bewährte), Mangel von 2FA und mehrere mehr zu erkennen. Solche unsicheren Attribute qualifizieren sich nicht als CVEs, weshalb keiner der vorhandenen Tools sie kennzeichnen kann. Packj kann in Ihrer Software-Lieferkette böswillige, tippflichtige, verlassene, verletzliche und andere unsichere Abhängigkeiten (schwache Verbindungen) markieren. Bitte lesen Sie mehr unter Audit Readme
Packj kann leicht an Ihr Bedrohungsmodell angepasst werden. Fügen Sie einfach eine .packj.yaml -Datei in die oberste Dire Ihres Repo/Projekts hinzu und reduzieren Sie die Alarm -Müdigkeit, indem Sie unerwünschte Attribute ausgeben.
Wir haben über 40- und 20 böswillige Pakete auf PYPI bzw. Rubygems mit diesem Tool gefunden. Einige von ihnen wurden abgenommen. Siehe ein Beispiel unten:
$ python3 main.py audit pypi:krisqian
[+] Fetching 'krisqian' from pypi...OK [ver 0.0.7]
[+] Checking version...OK [256 days old]
[+] Checking release history...OK [7 version(s)]
[+] Checking release time gap...OK [1 days since last release]
[+] Checking author...OK [[email protected]]
[+] Checking email/domain validity...OK [[email protected]]
[+] Checking readme...ALERT [no readme]
[+] Checking homepage...OK [https://www.bilibili.com/bangumi/media/md140632]
[+] 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-vetted package report at https://packj.dev/package/PyPi/KrisQian/0.0.7
Packj markiert Krisqian (V0.0.7) als misstrauisch aufgrund des Fehlens von Quell -Repo und der Verwendung sensibler APIs (Netzwerk, Codegenerierung) während der Paketinstallationszeit (in Setup.py). Wir beschlossen, einen tieferen Blick darauf zu werfen, und fanden das Paket böswillig. In unserer detaillierten Analyse finden Sie unter https://packj.dev/malware/krisqian.
Weitere Beispiele für Malware, die wir gefunden haben, sind unter https://packj.dev/malware aufgeführt. Bitte wenden Sie sich an uns unter [email protected], um die vollständige Liste zu erhalten.
Um mehr über Packj Tool oder Open-Source-Software-Supply-Chain-Angriffe zu erfahren
Betrachten ? Dieses Repo, um auf dem Laufenden zu bleiben.
Haben Sie eine Funktions- oder Support -Anfrage? Bitte besuchen Sie unsere GitHub -Diskussionsseite oder schließen Sie sich unserer Discord -Community an, um Diskussionen und Anfragen zu erhalten.
Packj wurde von Cybersecurity-Forschern von Ossillate Inc. und externen Mitarbeitern entwickelt, um Entwicklern dabei zu helfen, die Risiken von Supply-Chain-Angriffen zu verringern, wenn sie nicht vertrauenswürdige Open-Source-Softwareabhängigkeiten beschaffen. Wir danken unseren Entwicklern und Mitarbeitern. Zeigen Sie Ihre Wertschätzung, indem Sie uns eine geben, wenn Ihnen unsere Arbeit gefällt.
Wir begrüßen Codebeiträge mit offenen Armen. Siehe Beitrags.MD -Richtlinien. Einen Fehler gefunden? Bitte öffnen Sie ein Problem. In unseren Richtlinien für Sicherheit.MD finden Sie ein Sicherheitsproblem.
Packj kann derzeit die Pakete von NPM, PYPI und RubyGems für "riskante" Attribute einfragen. Wir unterstützen Rost.
Packj verwendet statische Codeanalyse, dynamische Verfolgung und Metadatenanalyse für eine umfassende Prüfung. Die statische Analyse allein reicht nicht aus, um anspruchsvolle Malware zu kennzeichnen, die sich selbst mithilfe der Code -Verschleierung besser verbergen kann. Die dynamische Analyse wird durchgeführt, indem das Paket unter strace installiert und das Laufzeitverhalten überwacht wird. Bitte lesen Sie mehr unter Audit Readme.
Dies ist ein sehr häufiges bösartiges Verhalten. Packj erkennt Code verschleiert sowie das Laichen von Shell -Befehlen (EXEC -Systemaufruf). Beispielsweise kann Packj die Verwendung von getattr() und eval() API mit der "Runtime -Code -Generierung" angeben. Ein Entwickler kann dann einen tieferen Blick darauf werfen. Einzelheiten finden Sie unter Main.py.
