ossillate-inc/packjHerramienta de análisis estático y dinámico que audita paquetes de código abierto en busca de atributos maliciosos, vulnerables y riesgosos, con instalación en entorno aislado para prevenir ataques a la cadena de suministro.
Packj señala paquetes de código abierto maliciosos/riesgososPackj (pronunciado 'paquete') es una herramienta para ayudar a mitigar los ataques a la cadena de suministro de software. Puede detectar paquetes maliciosos, vulnerables, abandonados, de typo-squatting y otros 'riesgosos' de registros de paquetes de código abierto populares, como NPM, RubyGems y PyPI. Se puede personalizar fácilmente para minimizar el ruido. Packj comenzó como un proyecto de investigación de doctorado y actualmente se desarrolla con diversas subvenciones gubernamentales.
Nota El servidor web autoalojado de Packj y varias integraciones llegarán a finales de este mes 👊 Observa este repositorio para mantenerte actualizado.
Admitimos múltiples modelos de despliegue:
Usa Packj para auditar dependencias en pull requests.```yaml
Ver en GitHub [marketplace](https://github.com/marketplace/actions/packj-security-audit). Ejemplo [PR run](https://github.com/ossillate-inc/packj-github-action-demo/pull/3#issuecomment-1274797138).
### 2. Imagen Docker (recomendada)
La forma más rápida de probar/testear Packj es usando Docker. Podman también es compatible para ejecuciones contenedorizadas (aisladas).```
docker run -v /tmp:/tmp/packj -it ossillate/packj:latest --help
Clona este repositorio,``` git clone https://github.com/ossillate-inc/packj.git && cd packj
Instalar dependencias```
bundle install && pip3 install -r requirements.txt
Comienza con ayuda:``` python3 main.py --help
# Ecosistemas compatibles #
Packj puede evaluar paquetes publicados de los registros de paquetes NPM, PyPI, Rust, PHP y Rubygems. El soporte para Rust y PHP está en desarrollo. Estamos agregando soporte activamente para registros.
También admite la evaluación de paquetes NPM y PyPI locales (no publicados).
| Registro | Ecosistema | Compatible |
| --------- | ---------- | ------------------- |
| 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: |
# Funcionalidad #
Packj ofrece las siguientes herramientas:
* [Auditoría](#auditoría-de-un-paquete) - para evaluar un paquete en busca de atributos "riesgosos".
* [Sandbox](#instalación-aislada-de-paquetes) - para la instalación segura de un paquete.
## Auditoría de un paquete ##
Packj audita paquetes de software de código abierto en busca de atributos "riesgosos" que los hacen vulnerables a ataques a la cadena de suministro. Por ejemplo, paquetes con dominios de correo electrónico caducados (falta de 2FA), gran brecha de tiempo entre versiones, APIs sensibles o permisos de acceso, etc., son marcados como riesgosos.
Se admite la auditoría de:
- múltiples paquetes: `python3 main.py audit -p pypi:requests rubygems:overcommit`
- archivos de dependencias: `python3 main.py audit -f npm:package.json pypi:requirements.txt`
Por defecto, `audit` solo realiza análisis estático de código para detectar código riesgoso. Puede pasar el indicador `-t` o `--trace` para realizar también análisis dinámico de código, que instalará todos los paquetes solicitados bajo `strace` y monitoreará el comportamiento de los paquetes durante la instalación. Vea el ejemplo de salida a continuación.
<details>
<summary><h4>Mostrar ejemplo de ejecución/salida</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>
> ADVERTENCIA: dado que los paquetes podrían ejecutar código malicioso durante la instalación, se recomienda usar `-t` o `--trace` SOLO cuando se ejecute dentro de un contenedor Docker o una Máquina Virtual.
La auditoría también se puede realizar en contenedores Docker/Podman. Encuentre detalles sobre los atributos riesgosos y cómo usarlos en [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md).
## Instalación aislada de paquetes ##
Packj ofrece un sandboxing ligero para la "instalación segura" de un paquete. Específicamente, evita que paquetes maliciosos exfiltren datos sensibles, accedan a archivos sensibles (por ejemplo, claves SSH) y persistan malware.
Aísla los scripts de tiempo de instalación, incluyendo cualquier compilación nativa. Utiliza **strace** (es decir, **NO** se requiere VM/Contenedor).
Encuentre detalles sobre el mecanismo de sandboxing y cómo usarlo en [Sandbox README](https://github.com/ossillate-inc/packj/blob/main/packj/sandbox/README.md).
<details>
<summary><h4>Mostrar ejemplo de ejecución/salida</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>
# Nuestra historia
**TL;DR** Packj comenzó como un proyecto de investigación de doctorado. Está respaldado por diversas subvenciones gubernamentales.
<details>
<summary><h4>Mostrar respuesta larga</h4></summary>
Packj comenzó como un proyecto de investigación académica. Específicamente, las técnicas de análisis estático de código utilizadas por Packj se basan en investigación de vanguardia en Ciberseguridad: el proyecto [MalOSS](https://github.com/osssanitizer/maloss) de nuestro [grupo de investigación](http://cyfi.ece.gatech.edu) en 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="artículo académico">
</a>
Packj está respaldado por generosas subvenciones de [NSF](https://www.sbir.gov/node/2083473), [GRA](https://gra.org/company/227/OSSPolice.html) y [ALInnovate](https://innovatealabama.org).
</details>
# Por qué Packj
**TL;DR** Los escáneres de vulnerabilidades del estado del arte asumen que el código de terceros de código abierto es BENIGNO. Por lo tanto, todos estos escáneres SOLO abordan las amenazas de errores de programación accidentales en código benigno (también conocidos como CVEs, como Log4J). NO protegen contra ataques modernos a la cadena de suministro de software similares a Solarwinds, provenientes de código deliberadamente malo (también conocido como malicioso) que es propagado por actores malintencionados utilizando nuevas vulnerabilidades en el canal de suministro, incluyendo confusión de dependencias, typosquatting, protestware (sabotaje), secuestro de cuentas e ingeniería social. Un ejemplo reciente (dic'22) es el paquete PyTorch que fue comprometido utilizando una vulnerabilidad de confusión de dependencias (sin CVE asignado).
Packj no solo audita CVEs, sino que también realiza un análisis profundo de código estático + dinámico, así como verificaciones de metadatos para detectar cualquier comportamiento y atributo "riesgoso", como la ejecución de shell, uso de claves SSH, discrepancia entre el código de GitHub y el empaquetado (procedencia), falta de 2FA y varios más. Estos atributos inseguros no califican como CVEs, por lo que ninguna de las herramientas existentes puede marcarlos. Packj puede marcar dependencias maliciosas, de typosquatting, abandonadas, vulnerables y otras inseguras (eslabones débiles) en su cadena de suministro de software.
<details>
<summary><h4>Mostrar respuesta larga</h4></summary>
El modelo de amenaza actual de la cadena de suministro de software **asume** que el código de terceros de código abierto es benigno, y por lo tanto, las vulnerabilidades de seguridad solo se rastrean por errores de programación accidentales (también conocidos como CVEs). Como tal, todos los escáneres de vulnerabilidades de código abierto existentes **SOLO** reportan CVEs conocidos públicamente y abordan amenazas de errores accidentales en código benigno.
Un ejemplo típico de un error de programación accidental es la falta de comprobación de límites en la entrada del usuario, lo que hace que el código sea vulnerable a ataques de desbordamiento de búfer. Ejemplos populares del mundo real incluyen Log4J y HeartBleed. Los atacantes necesitan desarrollar un exploit para desencadenar CVEs (por ejemplo, un paquete TCP/IP manipulado en el caso de HeartBleed o una entrada numéricamente alta para causar un desbordamiento de búfer). Los CVEs pueden solucionarse parcheando o actualizando a una versión más reciente de la biblioteca (por ejemplo, una versión más nueva de Log4J corrige el CVE).
El panorama de amenazas moderno de la cadena de suministro de software **cambió** después del ataque de Solarwinds. Los actores malintencionados han encontrado nuevas vulnerabilidades, pero esta vez en el canal de suministro, no en el código. Estas nuevas vulnerabilidades, como la confusión de dependencias, el typosquatting, el protestware (sabotaje), el secuestro de cuentas y la ingeniería social, se están explotando para propagar malware. Se han reportado miles de paquetes NPM/PyPI/Ruby comprometidos.
En contraste con los CVEs, el malware es código deliberadamente malo (también conocido como malicioso). Además, el malware en sí mismo es un exploit y no puede parchearse ni corregirse actualizando a una versión más nueva. Por ejemplo, el [ataque de confusión de dependencias](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) fue intencionalmente malicioso; no explotó ningún error de programación accidental en el código. De manera similar, un autor de un paquete popular que sabotea su propio código para [protestar](https://en.wikipedia.org/wiki/Peacenotwar) contra la guerra es muy intencional y no explota ningún CVE. El typosquatting es otro vector de ataque que los actores malintencionados utilizan para propagar malware en registros de paquetes de código abierto populares: explota [erratas e inexperiencia de los desarrolladores](https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090), no errores de programación accidentales o CVEs en el código.
Los escáneres existentes **FALLAN** en detectar estos ataques modernos a la cadena de suministro de software similares a Solarwinds provenientes de código deliberadamente vulnerable (malicioso). Estas herramientas simplemente escanean el código fuente en busca de dependencias de código abierto, compilan una lista de todas las dependencias utilizadas y buscan cada <NOMBRE-DEPENDENCIA, VERSIÓN-DEPENDENCIA> en una base de datos (por ejemplo, NVD) para reportar las versiones de paquetes afectadas (por ejemplo, la versión vulnerable de Log4J, la versión de LibSSL afectada por HeartBleed).
Packj no solo audita CVEs, sino que también realiza un análisis profundo de código estático + dinámico, así como verificaciones de metadatos para detectar cualquier comportamiento y atributo "riesgoso", como la ejecución de shell, uso de claves SSH, discrepancia entre el código de GitHub y el empaquetado (procedencia), falta de 2FA y varios más. Estos atributos inseguros no califican como CVEs, por lo que ninguna de las herramientas existentes puede marcarlos. Packj puede marcar dependencias maliciosas, de typosquatting, abandonadas, vulnerables y otras inseguras (eslabones débiles) en su cadena de suministro de software. Por favor, lea más en [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md#faq)
</details>
# Personalización #
Packj se puede personalizar fácilmente (sin ruido) según su modelo de amenaza. Simplemente agregue un archivo [.packj.yaml](https://github.com/ossillate-inc/packj/blob/main/.packj.yaml) en el directorio superior de su repositorio/proyecto y reduzca la fatiga de alertas comentando los atributos no deseados.
# Malware encontrado #
Encontramos más de 40 y 20 paquetes maliciosos en PyPI y Rubygems, respectivamente, utilizando esta herramienta. Varios de ellos han sido eliminados. Consulte un ejemplo a continuación:
<details>
<summary><h4>Mostrar ejemplo de malware</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 marcó KrisQian (v0.0.7) como sospechoso debido a la ausencia de repositorio fuente y el uso de APIs sensibles (red, generación de código) durante la instalación del paquete (en setup.py). Decidimos echar un vistazo más profundo y encontramos que el paquete era malicioso. Encuentre nuestro análisis detallado en [https://packj.dev/malware/krisqian](https://packj.dev/malware/krisqian).
Más ejemplos de malware que encontramos se enumeran en [https://packj.dev/malware](https://packj.dev/malware). Comuníquese con nosotros en [[email protected]](mailto:[email protected]) para obtener la lista completa.
# Recursos #
Para obtener más información sobre la herramienta Packj o los ataques a la cadena de suministro de software de código abierto, consulte nuestros
[](https://www.youtube.com/watch?v=Rcuqn56uCDk)
[](https://www.youtube.com/watch?v=a7BfDGeW_jY)
- [Charla](https://www.youtube.com/watch?v=Rcuqn56uCDk) y [diapositivas](https://speakerdeck.com/ashishbijlani/pyconus22-slides) de PyConUS'22.
- [Presentación](https://www.blackhat.com/asia-22/arsenal/schedule/#mitigating-open-source-software-supply-chain-attacks-26241) de BlackHAT Asia'22 Arsenal.
- [Charla](https://www.youtube.com/watch?v=PHfN-NrUCoo) y [diapositivas](https://speakerdeck.com/ashishbijlani/mitigating-open-source-software-supply-chain-attacks) de PackagingCon'21.
- Charla BlackHat USA'22 Arsenal [Detecting typo-squatting, backdoored, abandoned, and other "risky" open-source packages using Packj](https://www.blackhat.com/us-22/arsenal/schedule/#detecting-typo-squatting-backdoored-abandoned-and-other-risky-open-source-packages-using-packj-28075)
- [Tesis](https://cyfi.ece.gatech.edu/publications/DUAN-DISSERTATION-2019.pdf) académica sobre seguridad de software de código abierto y el [artículo](https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B-1_23055_paper.pdf) de nuestro grupo en Georgia Tech que inició esta investigación.
- Charla Open Source Summit, Europe'22 [Scoring dependencies to detect “weak links” in your open-source software supply chain](https://osseu2022.sched.com/overview/type/SupplyChainSecurityCon) - video de presentación en [YouTube](https://www.youtube.com/watch?v=a7BfDGeW_jY)
- [Video](https://www.youtube.com/watch?v=PgvlSjl-mrY) de presentación y [diapositivas](https://drive.google.com/file/d/1qLXIXzsIhRlS0mo8nwWI9KmD12CImZY9/view?usp=sharing) en NullCon'22 [Unearthing Malicious And Other “Risky” Open-Source Packages Using Packj](https://archive.nullcon.net/website/goa-2022/speakers/unearthing-malicious-and-other-risky-open-source-packages-using-packj.php)
# Hoja de ruta de funciones #
* Agregar analizador de Rust. Rust es un trabajo en progreso [ETA: Feb '24].
* Agregar funcionalidad para detectar varios (TODO) atributos "riesgosos" de código y metadatos [ETA: Feb '24].
* Servidor web Packj autoalojado y varias integraciones útiles (por ejemplo, Gitlab runner) [ETA: Abr'24].
Vigile :eyes: este repositorio para mantenerse actualizado.
¿Tiene una solicitud de función o soporte? Visite nuestra [página de discusión de GitHub](https://github.com/ossillate-inc/packj/discussions/) o únase a nuestra [comunidad de discord](https://discord.gg/qFcqaV2wYa) para discusiones y solicitudes.
# Equipo y colaboradores #
Packj ha sido desarrollado por investigadores en Ciberseguridad de [Ossillate Inc.](https://packj.dev/team) y colaboradores externos para ayudar a los desarrolladores a mitigar los riesgos de ataques a la cadena de suministro al obtener dependencias de software de código abierto de terceros no confiables. Agradecemos a nuestros desarrolladores y colaboradores. Muestre su aprecio dándonos una :star: si le gusta nuestro trabajo.
Miembros fundadores:
* Ashish Bijlani
* Devdutt Patnaik
* Ajinkya Rajput
Damos la bienvenida a contribuciones de código con los brazos abiertos. Consulte las pautas en [CONTRIBUTING.md](https://github.com/ossillate-inc/packj/blob/HEAD/CONTRIBUTING.md). ¿Encontró un error? Por favor, abra un issue. Consulte nuestras pautas en [SECURITY.md](https://github.com/ossillate-inc/packj/blob/HEAD/SECURITY.md) para reportar un problema de seguridad.
# FAQ #
<details>
<summary><b>¿Qué gestores de paquetes (registros) son compatibles?</b></summary>
Packj actualmente puede evaluar paquetes NPM, PyPI y RubyGems en busca de atributos "riesgosos". Estamos agregando soporte para Rust.
</details>
<details>
<summary><b>¿Qué técnicas emplea Packj para detectar paquetes riesgosos/maliciosos?</b></summary>
Packj utiliza análisis estático de código, trazado dinámico y análisis de metadatos para una auditoría exhaustiva. El análisis estático por sí solo no es suficiente para marcar malware sofisticado que puede ocultarse mejor mediante ofuscación de código. El análisis dinámico se realiza instalando el paquete bajo `strace` y monitoreando su comportamiento en tiempo de ejecución. Lea más en [Audit README](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md).
</details>
<details>
<summary><b>¿Funciona en llamadas ofuscadas? Por ejemplo, una cadena cifrada en base 64 que se descifra y luego se pasa a un shell?</b></summary>Este es un comportamiento malicioso muy común. Packj detecta la ofuscación de código, así como la ejecución de comandos de shell (llamada al sistema exec). Por ejemplo, Packj puede marcar el uso de las API `getattr()` y `eval()` ya que indican 'generación de código en tiempo de ejecución'; un desarrollador puede entonces revisar más a fondo. Consulte [main.py](https://github.com/ossillate-inc/packj/blob/main/packj/audit/main.py#L512) para más detalles.
</details>