Packj signale les paquets open-source malveillants/risqués

Packj (prononcé 'package') est un outil pour aider à atténuer les attaques sur la chaîne d'approvisionnement logicielle. Il peut détecter les paquets malveillants, vulnérables, abandonnés, de typosquattage et autres paquets « risqués » provenant de registres de paquets open-source populaires, tels que NPM, RubyGems et PyPI. Il peut être facilement personnalisé pour minimiser le bruit. Packj a débuté comme projet de recherche de doctorat et est actuellement développé dans le cadre de diverses subventions gouvernementales.

Github Commit Activity

# Écosystèmes pris en charge # Packj peut auditer les packages publiés depuis les registres NPM, PyPI, Rust, PHP et Rubygems. La compatibilité Rust et PHP est en cours de développement. Nous ajoutons activement la prise en charge de registres. Il prend également en charge l'audit de packages NPM et PyPI locaux (non publiés). | Registre | Écosystème | Pris en charge | | ---------- | ----------- | ------------------- | | NPM | JavaScript | :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: | # Fonctionnalités # Packj propose les outils suivants : * [Audit](#audit-dun-package) - pour auditer un package à la recherche d'attributs « à risque ». * [Sandbox](#installation-sandboxée-de-packages) - pour une installation sécurisée d'un package. ## Audit d'un package ## Packj audite les packages de logiciels open-source à la recherche d'attributs « à risque » qui les rendent vulnérables aux attaques sur la chaîne d'approvisionnement. Par exemple, les packages avec des domaines de messagerie expirés (manque de 2FA), un grand écart de temps entre les versions, des API sensibles ou des permissions d'accès, etc., sont signalés comme risqués. L'audit des éléments suivants est pris en charge : - plusieurs packages : `python3 main.py audit -p pypi:requests rubygems:overcommit` - fichiers de dépendances : `python3 main.py audit -f npm:package.json pypi:requirements.txt` Par défaut, `audit` effectue uniquement une analyse statique du code pour détecter du code risqué. Vous pouvez passer le drapeau `-t` ou `--trace` pour effectuer également une analyse dynamique du code, ce qui installera tous les packages demandés sous strace et surveillera le comportement des packages lors de l'installation. Veuillez voir l'exemple de sortie ci-dessous. <details> <summary><h4>Afficher un exemple d'exécution/sortie</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 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", ] } </details> > ATTENTION : puisque les packages peuvent exécuter du code malveillant lors de l'installation, il est recommandé d'utiliser `-t` ou `--trace` UNIQUEMENT lorsque vous exécutez dans un conteneur Docker ou une machine virtuelle. L'audit peut également être effectué dans des conteneurs Docker/Podman. Veuillez trouver les détails sur les attributs à risque et comment utiliser dans [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md). ## Installation sandboxée de packages ## Packj offre un sandboxing léger pour une « installation sécurisée » d'un package. Plus précisément, il empêche les packages malveillants d'exfiltrer des données sensibles, d'accéder à des fichiers sensibles (par exemple, les clés SSH) et de persister des logiciels malveillants. Il sandboxe les scripts d'installation, y compris toute compilation native. Il utilise **strace** (c'est-à-dire **PAS** de VM/conteneur requis). Veuillez trouver les détails sur le mécanisme de sandboxing et comment l'utiliser dans [Sandbox README](https://github.com/ossillate-inc/packj/blob/main/packj/sandbox/README.md). <details> <summary><h4>Afficher un exemple d'exécution/sortie</h4></summary> $ 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: </details> # Notre histoire **TL;DR** Packj a commencé comme projet de recherche doctorale. Il est soutenu par diverses subventions gouvernementales. <details> <summary><h4>Afficher la réponse longue</h4></summary> Packj a commencé comme projet de recherche académique. Plus précisément, les techniques d'analyse statique de code utilisées par Packj sont basées sur une recherche de pointe en cybersécurité : le projet [MalOSS](https://github.com/osssanitizer/maloss) de notre [groupe](http://cyfi.ece.gatech.edu) de recherche à Georgia Tech. <a href="https://arxiv.org/pdf/2002.01139v1.pdf" target="_blank"> <img src="https://assets.kitploit.com/production/public/readmes/5562/c4061028051de04a9aebaf4188c08fdd1bcdb47efa8a818e959d3b3fc7bc5dc7.png" width="300" alt="article académique"> </a> Packj est soutenu par des subventions généreuses de [NSF](https://www.sbir.gov/node/2083473), [GRA](https://gra.org/company/227/OSSPolice.html) et [ALInnovate](https://innovatealabama.org). </details> # Pourquoi Packj **TL;DR** Les scanners de vulnérabilités les plus avancés supposent que le code open-source tiers est BÉNIN. Par conséquent, tous ces outils ne traitent que les menaces provenant de bogues de programmation accidentels dans du code bénin (aussi appelés CVE comme Log4J). Ils NE protègent PAS contre les attaques modernes sur la chaîne d'approvisionnement logicielle de type Solarwinds provenant de code délibérément mauvais (aussi appelé malveillant) qui est propagé par des acteurs malveillants utilisant de nouvelles vulnérabilités dans le canal d'approvisionnement, y compris la confusion de dépendances, le typo-squatting, les protestwares (sabotage), le détournement de compte et l'ingénierie sociale. Un exemple récent (déc. 2022) est le package PyTorch qui a été compromis en utilisant une vulnérabilité de confusion de dépendances (aucun CVE attribué). Packj n'audite pas seulement les CVE, mais effectue également une analyse de code statique + dynamique approfondie ainsi que des vérifications de métadonnées pour détecter tout comportement ou attribut « à risque », comme la création de shell, l'utilisation de clés SSH, la non-concordance entre le code GitHub et le code packagé (provenance), l'absence de 2FA, et bien d'autres. Ces attributs non sécurisés ne sont pas qualifiés de CVE, c'est pourquoi aucun des outils existants ne peut les signaler. Packj peut signaler les dépendances malveillantes, de typo-squatting, abandonnées, vulnérables et autres dépendances non sécurisées (maillons faibles) dans votre chaîne d'approvisionnement logicielle. <details> <summary><h4>Afficher la réponse longue</h4></summary> Le modèle de menace actuel de la chaîne d'approvisionnement logicielle **suppose** que le code open-source tiers est bénin, et donc, les vulnérabilités de sécurité ne sont suivies que pour les bogues de programmation accidentels (aussi appelés CVE). Ainsi, tous les scanners de vulnérabilités open-source existants ne signalent **UNIQUEMENT** que les CVE publiquement connues et traitent les menaces provenant de bogues accidentels dans du code bénin. Un exemple typique de bogue de programmation accidentel est l'absence de vérification des limites sur une entrée utilisateur, ce qui rend le code vulnérable aux attaques par débordement de tampon. Des exemples populaires réels incluent Log4J et HeartBleed. Les attaquants doivent développer une exploitation pour déclencher les CVE (par exemple, un paquet TCP/IP spécialement conçu dans le cas de HeartBleed ou une entrée numériquement élevée pour provoquer un débordement de tampon). Les CVE peuvent être corrigées en appliquant un correctif ou en mettant à niveau vers une version plus récente de la bibliothèque (par exemple, une version plus récente de Log4J corrige la CVE). Le paysage moderne des menaces de la chaîne d'approvisionnement logicielle a **changé** après l'attaque Solarwinds. Les acteurs malveillants ont trouvé de nouvelles vulnérabilités, mais cette fois dans le canal d'approvisionnement, pas dans le code. Ces nouvelles vulnérabilités telles que la confusion de dépendances, le typo-squatting, les protestwares (sabotage), le détournement de compte et l'ingénierie sociale sont exploitées pour propager des logiciels malveillants. Des milliers de packages NPM/PyPI/Ruby compromis ont été signalés. Contrairement aux CVE, les logiciels malveillants sont délibérément mauvais (aussi appelés malveillants). De plus, le logiciel malveillant est lui-même une exploitation et ne peut pas être corrigé ou fixé en mettant à niveau vers une version plus récente. Par exemple, l'[attaque par confusion de dépendances](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) était intentionnellement malveillante ; elle n'exploitait aucun bogue de programmation accidentel dans le code. De même, un auteur d'un package populaire sabotant son propre code pour [protester](https://en.wikipedia.org/wiki/Peacenotwar) contre la guerre est très intentionnel et n'exploite aucune CVE. Le typo-squatting est un autre vecteur d'attaque que les acteurs malveillants utilisent pour propager des logiciels malveillants dans les registres de packages open-source populaires : il exploite les [fautes de frappe et l'inexpérience des développeurs](https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090), et non les bogues de programmation accidentels ou les CVE dans le code. Les scanners existants **ÉCHOUENT** à détecter ces attaques modernes sur la chaîne d'approvisionnement logicielle de type Solarwinds provenant de code délibérément vulnérable (malveillant). Ces outils scannent simplement le code source pour les dépendances open-source, compilent une liste de toutes les dépendances utilisées et recherchent chaque <nom-dépendance, version-dépendance> dans une base de données (par exemple, NVD) pour signaler les versions de packages affectées (par exemple, version vulnérable de Log4J, version de LibSSL affectée par HeartBleed). Packj n'audite pas seulement les CVE, mais effectue également une analyse de code statique + dynamique approfondie ainsi que des vérifications de métadonnées pour détecter tout comportement ou attribut « à risque », comme la création de shell, l'utilisation de clés SSH, la non-concordance entre le code GitHub et le code packagé (provenance), l'absence de 2FA, et bien d'autres. Ces attributs non sécurisés ne sont pas qualifiés de CVE, c'est pourquoi aucun des outils existants ne peut les signaler. Packj peut signaler les dépendances malveillantes, de typo-squatting, abandonnées, vulnérables et autres dépendances non sécurisées (maillons faibles) dans votre chaîne d'approvisionnement logicielle. Veuillez en lire plus dans [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md#faq) </details> # Personnalisation # Packj peut être facilement personnalisé (zéro bruit) selon votre modèle de menace. Ajoutez simplement un fichier [.packj.yaml](https://github.com/ossillate-inc/packj/blob/main/.packj.yaml) dans le répertoire supérieur de votre dépôt/projet et réduisez la fatigue des alertes en commentant les attributs indésirables. # Logiciels malveillants trouvés # Nous avons trouvé plus de 40 et 20 packages malveillants sur PyPI et Rubygems respectivement en utilisant cet outil. Un certain nombre d'entre eux ont été supprimés. Reportez-vous à un exemple ci-dessous : <details> <summary><h4>Afficher un exemple de logiciel malveillant</h4></summary> $ 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 </details> Packj a signalé KrisQian (v0.0.7) comme suspect en raison de l'absence de dépôt source et de l'utilisation d'API sensibles (réseau, génération de code) lors de l'installation du package (dans setup.py). Nous avons décidé d'examiner de plus près et avons trouvé le package malveillant. Veuillez trouver notre analyse détaillée sur [https://packj.dev/malware/krisqian](https://packj.dev/malware/krisqian). Plus d'exemples de logiciels malveillants que nous avons trouvés sont listés sur [https://packj.dev/malware](https://packj.dev/malware). Veuillez nous contacter à [[email protected]](mailto:[email protected]) pour la liste complète. # Ressources # Pour en savoir plus sur l'outil Packj ou les attaques sur la chaîne d'approvisionnement des logiciels open-source, consultez nos [![PyConUS'22 Video](https://assets.kitploit.com/production/public/readmes/5562/216f348346e0f9e5189577944e0b2dc3746f3005eb90d7da890ad8b6e24dc363.jpg)](https://www.youtube.com/watch?v=Rcuqn56uCDk) [![OSSEU'22 Video](https://assets.kitploit.com/production/public/readmes/5562/00da211317b9a2b4205afaf3c10f49721bb104f4229aab18a61e6e894101e36b.jpg)](https://www.youtube.com/watch?v=a7BfDGeW_jY) - [Talk](https://www.youtube.com/watch?v=Rcuqn56uCDk) et [diapositives](https://speakerdeck.com/ashishbijlani/pyconus22-slides) de PyConUS'22. - [Présentation](https://www.blackhat.com/asia-22/arsenal/schedule/#mitigating-open-source-software-supply-chain-attacks-26241) à BlackHAT Asia'22 Arsenal - [Talk](https://www.youtube.com/watch?v=PHfN-NrUCoo) et [diapositives](https://speakerdeck.com/ashishbijlani/mitigating-open-source-software-supply-chain-attacks) de PackagingCon'21 - Talk à BlackHat USA'22 Arsenal [Détection de typo-squatting, de backdoors, de packages abandonnés et autres packages open-source « risqués » à l'aide de Packj](https://www.blackhat.com/us-22/arsenal/schedule/#detecting-typo-squatting-backdoored-abandoned-and-other-risky-open-source-packages-using-packj-28075) - [Thèse](https://cyfi.ece.gatech.edu/publications/DUAN-DISSERTATION-2019.pdf) académique sur la sécurité des logiciels open-source et l'[article](https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B-1_23055_paper.pdf) de notre groupe à Georgia Tech qui a initié cette recherche. - Talk à Open Source Summit, Europe'22 [Scorer les dépendances pour détecter les « maillons faibles » dans votre chaîne d'approvisionnement logicielle open-source](https://osseu2022.sched.com/overview/type/SupplyChainSecurityCon) - vidéo de présentation sur [YouTube](https://www.youtube.com/watch?v=a7BfDGeW_jY) - [Vidéo](https://www.youtube.com/watch?v=PgvlSjl-mrY) et [diapositives](https://drive.google.com/file/d/1qLXIXzsIhRlS0mo8nwWI9KmD12CImZY9/view?usp=sharing) de la présentation à NullCon'22 [Déterrer les packages open-source malveillants et autres « risqués » à l'aide de Packj](https://archive.nullcon.net/website/goa-2022/speakers/unearthing-malicious-and-other-risky-open-source-packages-using-packj.php) # Feuille de route des fonctionnalités # * Ajouter un analyseur Rust. Rust est un travail en cours [ETA : fév. '24]. * Ajouter une fonctionnalité pour détecter plusieurs (TODO) codes « à risque » ainsi que des attributs de métadonnées [ETA : fév. '24]. * Serveur web Packj auto-hébergé et plusieurs intégrations utiles (par exemple, Gitlab runner) [ETA : avr. '24]. Surveillez :eyes: ce dépôt pour rester à jour. Vous avez une demande de fonctionnalité ou de support ? Veuillez visiter notre [page de discussion GitHub](https://github.com/ossillate-inc/packj/discussions/) ou rejoindre notre [communauté Discord](https://discord.gg/qFcqaV2wYa) pour discuter et faire des demandes. # Équipe et contributeurs # Packj a été développé par des chercheurs en cybersécurité chez [Ossillate Inc.](https://packj.dev/team) et des collaborateurs externes pour aider les développeurs à atténuer les risques d'attaques sur la chaîne d'approvisionnement lorsqu'ils utilisent des dépendances logicielles open-source tierces non fiables. Nous remercions nos développeurs et collaborateurs. Montrez votre appréciation en nous donnant une :star: si vous aimez notre travail. Membres fondateurs : * Ashish Bijlani * Devdutt Patnaik * Ajinkya Rajput Nous accueillons les contributions de code à bras ouverts. Voir les directives [CONTRIBUTING.md](https://github.com/ossillate-inc/packj/blob/main/CONTRIBUTING.md). Vous avez trouvé un bogue ? Veuillez ouvrir une issue. Reportez-vous à nos directives [SECURITY.md](https://github.com/ossillate-inc/packj/blob/main/SECURITY.md) pour signaler un problème de sécurité. # FAQ # <details> <summary><b>Quels gestionnaires de packages (registres) sont pris en charge ?</b></summary> Packj peut actuellement auditer les packages NPM, PyPI et RubyGems pour les attributs « à risque ». Nous ajoutons la prise en charge de Rust. </details> <details> <summary><b>Quelles techniques Packj utilise-t-il pour détecter les packages risqués/malveillants ?</b></summary> Packj utilise l'analyse statique de code, le traçage dynamique et l'analyse des métadonnées pour un audit complet. L'analyse statique seule ne suffit pas pour signaler les logiciels malveillants sophistiqués qui peuvent mieux se cacher en utilisant l'obfuscation de code. L'analyse dynamique est effectuée en installant le package sous `strace` et en surveillant son comportement à l'exécution. Veuillez en lire plus dans [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md). </details> <details> <summary><b>Cela fonctionne-t-il sur les appels obfusqués ? Par exemple, une chaîne chiffrée en base64 qui est déchiffrée puis passée à un shell ?</b></summary>Il s'agit d'un comportement malveillant très courant. Packj détecte l'obfuscation de code ainsi que le lancement de commandes shell (appel système exec). Par exemple, Packj peut signaler l'utilisation des API `getattr()` et `eval()` car elles indiquent une "génération de code à l'exécution" ; un développeur peut alors aller jeter un coup d'œil plus approfondi. Voir [main.py](https://github.com/ossillate-inc/packj/blob/main/packj/audit/main.py#L512) pour plus de détails. </details>

packj

Populaires

Contenu

Démarrer

1. Runner GitHub

TODO: replace with your dependency files in the repo

3. Dépôt source