ossillate-inc/packjFerramenta de análise estática e dinâmica que audita pacotes de código aberto em busca de atributos maliciosos, vulneráveis e arriscados, com instalação em ambiente isolado para prevenir ataques à cadeia de suprimentos.
Packj sinaliza pacotes de código aberto maliciosos/arriscadosPackj (pronunciado pacote) é uma ferramenta para ajudar a mitigar ataques à cadeia de suprimentos de software. Ela pode detectar pacotes maliciosos, vulneráveis, abandonados, typo-squatting e outros "arriscados" de registros populares de pacotes de código aberto, como NPM, RubyGems e PyPI. Pode ser facilmente personalizada para minimizar ruído. Packj começou como um projeto de pesquisa de doutorado e atualmente está sendo desenvolvido sob várias bolsas governamentais.
Nota Servidor web Packj auto-hospedado e várias integrações chegarão ainda este mês 👊 Assista a este repositório para ficar atualizado.
Suportamos vários modelos de implantação:
Use Packj para auditar dependências em pull requests.```yaml
Ver no GitHub [marketplace](https://github.com/marketplace/actions/packj-security-audit). Exemplo [execução de PR](https://github.com/ossillate-inc/packj-github-action-demo/pull/3#issuecomment-1274797138).
### 2. Imagem Docker (recomendado)
A maneira mais rápida de experimentar/testar o Packj é usando o Docker. O Podman também é suportado para execuções conteinerizadas (isoladas).```
docker run -v /tmp:/tmp/packj -it ossillate/packj:latest --help
Clone este repositório,``` git clone https://github.com/ossillate-inc/packj.git && cd packj
Instalar dependências```
bundle install && pip3 install -r requirements.txt
Comece com ajuda:``` python3 main.py --help
# Ecossistemas suportados #
Packj pode auditar pacotes publicados dos registros de pacotes NPM, PyPI, Rust, PHP e Rubygems. O suporte para Rust e PHP está em desenvolvimento (WIP). Estamos ativamente adicionando suporte para registros.
Também suporta auditoria de pacotes NPM e PyPI locais (não publicados).
| Registro | Ecossistema | Suportado |
| ---------- | ----------- | ----------------- |
| 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: |
# Funcionalidade #
Packj oferece as seguintes ferramentas:
* [Auditoria](#auditoria-de-um-pacote) - para auditar um pacote quanto a atributos "de risco".
* [Sandbox](#instalação-de-pacote-em-sandbox) - para instalação segura de um pacote.
## Auditoria de um pacote ##
Packj audita pacotes de software de código aberto quanto a atributos "de risco" que os tornam vulneráveis a ataques à cadeia de suprimentos. Por exemplo, pacotes com domínios de e-mail expirados (sem 2FA), grande lacuna de tempo de lançamento, APIs sensíveis ou permissões de acesso, etc., são sinalizados como arriscados.
É suportada a auditoria do seguinte:
- multiple packages: `python3 main.py audit -p pypi:requests rubygems:overcommit`
- dependency files: `python3 main.py audit -f npm:package.json pypi:requirements.txt`
Por padrão, `audit` realiza apenas análise estática de código para detectar código arriscado. Você pode passar a flag `-t` ou `--trace` para realizar também análise dinâmica de código, que instalará todos os pacotes solicitados sob strace e monitorará o comportamento durante a instalação dos pacotes. Veja o exemplo de saída abaixo.
<details>
<summary><h4>Mostrar execução/saída de exemplo</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>
> AVISO: como os pacotes podem executar código malicioso durante a instalação, recomenda-se usar `-t` ou `--trace` SOMENTE quando executado dentro de um contêiner Docker ou uma Máquina Virtual.
A auditoria também pode ser realizada em contêineres Docker/Podman. Encontre detalhes sobre atributos de risco e como usar em [README da Auditoria](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md).
## Instalação de pacote em sandbox ##
Packj oferece uma sandbox leve para `instalação segura` de um pacote. Especificamente, impede que pacotes maliciosos exfiltrem dados sensíveis, acessem arquivos sensíveis (por exemplo, chaves SSH) e persistam malware.
Ele coloca em sandbox scripts de tempo de instalação, incluindo qualquer compilação nativa. Usa **strace** (ou seja, **NÃO** requer VM/Contêiner).
Encontre detalhes sobre o mecanismo de sandbox e como usar em [README da Sandbox](https://github.com/ossillate-inc/packj/blob/main/packj/sandbox/README.md).
<details>
<summary><h4>Mostrar execução/saída de exemplo</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>
# Nossa história
**Resumo** Packj começou como um projeto de pesquisa de doutorado. É apoiado por várias bolsas governamentais.
<details>
<summary><h4>Mostrar resposta longa</h4></summary>
Packj começou como um projeto de pesquisa acadêmica. Especificamente, as técnicas de análise estática de código usadas pelo Packj são baseadas em pesquisa de ponta em Segurança Cibernética: projeto [MalOSS](https://github.com/osssanitizer/maloss) do nosso [grupo](http://cyfi.ece.gatech.edu) de pesquisa na 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="artigo acadêmico">
</a>
Packj é apoiado por generosos subsídios da [NSF](https://www.sbir.gov/node/2083473), [GRA](https://gra.org/company/227/OSSPolice.html) e [ALInnovate](https://innovatealabama.org).
</details>
# Por que Packj
**Resumo** Os scanners de vulnerabilidade de última geração assumem que o código de terceiros de código aberto é BENIGNO. Portanto, todas essas ferramentas tratam APENAS ameaças de bugs de programação acidentais em código benigno (também conhecidos como CVEs, como Log4J). Elas NÃO protegem contra ataques modernos à cadeia de suprimentos de software, semelhantes ao Solarwinds, provenientes de código deliberadamente ruim (também conhecido como malicioso) que é propagado por atores maliciosos usando novas vulnerabilidades no canal de fornecimento, incluindo confusão de dependência, typo-squatting, protestware (sabotagem), sequestro de contas e engenharia social. Um exemplo recente (dez'22) é o pacote PyTorch que foi comprometido usando vulnerabilidade de confusão de dependência (nenhum CVE atribuído).
Packj não apenas audita CVEs, mas também realiza análise profunda de código estática+dinâmica, além de verificações de metadados para detectar qualquer comportamento e atributo "de risco", como spawn de shell, uso de chaves SSH, incompatibilidade entre o código do GitHub e o código empacotado (proveniência), falta de 2FA, e vários outros. Esses atributos inseguros não se qualificam como CVEs, e é por isso que nenhuma das ferramentas existentes pode sinalizá-los. Packj pode sinalizar dependências maliciosas, typo-squatting, abandonadas, vulneráveis e outras dependências inseguras (elos fracos) em sua cadeia de suprimentos de software.
<details>
<summary><h4>Mostrar resposta longa</h4></summary>
O modelo de ameaça atual da cadeia de suprimentos de software **assume** que o código de terceiros de código aberto é benigno e, portanto, as vulnerabilidades de segurança são rastreadas apenas para bugs de programação acidentais (também conhecidos como CVEs). Como tal, todos os scanners de vulnerabilidade de código aberto existentes **APENAS** relatam CVEs publicamente conhecidos e tratam ameaças de bugs acidentais em código benigno.
Um exemplo típico de bug de programação acidental é a falta de verificação de limites na entrada do usuário, o que torna o código vulnerável a ataques de estouro de buffer. Exemplos populares do mundo real incluem Log4J e HeartBleed. Os atacantes precisam desenvolver um exploit para acionar CVEs (por exemplo, um pacote TCP/IP personalizado no caso do HeartBleed ou uma entrada numericamente alta para causar estouro de buffer). Os CVEs podem ser corrigidos aplicando patches ou atualizando para uma versão mais recente da biblioteca (por exemplo, a versão mais recente do Log4J corrige o CVE).
O cenário moderno de ameaças à cadeia de suprimentos de software **mudou** após o ataque Solarwinds. Atores maliciosos encontraram novas vulnerabilidades, mas desta vez no canal de fornecimento, não no código. Essas novas vulnerabilidades, como confusão de dependência, typo-squatting, protestware (sabotagem), sequestro de contas e engenharia social, estão sendo exploradas para propagar malware. Milhares de pacotes NPM/PyPI/Ruby comprometidos foram relatados.
Em contraste com os CVEs, o malware é código deliberadamente ruim (também conhecido como malicioso). Além disso, o malware em si é um exploit e não pode ser corrigido ou corrigido atualizando para uma versão mais recente. Por exemplo, [ataque de confusão de dependência](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) foi intencionalmente malicioso; não explorou nenhum bug de programação acidental no código. Da mesma forma, um autor de um pacote popular sabotando seu próprio código para [protestar](https://en.wikipedia.org/wiki/Peacenotwar) contra a guerra é bastante intencional e não explora nenhum CVE. Typo-squatting é outro vetor de ataque que atores maliciosos usam para propagar malware em registros populares de pacotes de código aberto: explora [erros de digitação e inexperiência de desenvolvedores](https://discuss.python.org/t/improving-risks-and-consequences-against-typosquatting-on-pypi/5090), não bugs de programação acidentais ou CVEs no código.
Os scanners existentes **FALHAM** em detectar esses ataques modernos à cadeia de suprimentos de software, semelhantes ao Solarwinds, provenientes de código deliberadamente vulnerável (malicioso). Essas ferramentas simplesmente escaneiam o código-fonte em busca de dependências de código aberto, compilam uma lista de todas as dependências usadas e consultam cada <nome-da-dependência, versão-da-dependência> em um banco de dados (por exemplo, NVD) para relatar versões de pacotes afetadas (por exemplo, versão vulnerável do Log4J, versão do LibSSL afetada pelo HeartBleed).
Packj não apenas audita CVEs, mas também realiza análise profunda de código estática+dinâmica, além de verificações de metadados para detectar qualquer comportamento e atributo "de risco", como spawn de shell, uso de chaves SSH, incompatibilidade entre o código do GitHub e o código empacotado (proveniência), falta de 2FA, e vários outros. Esses atributos inseguros não se qualificam como CVEs, e é por isso que nenhuma das ferramentas existentes pode sinalizá-los. Packj pode sinalizar dependências maliciosas, typo-squatting, abandonadas, vulneráveis e outras dependências inseguras (elos fracos) em sua cadeia de suprimentos de software. Leia mais em [README da Auditoria](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md#faq)
</details>
# Personalização #
Packj pode ser facilmente personalizado (ruído zero) para o seu modelo de ameaça. Basta adicionar um arquivo [.packj.yaml](https://github.com/ossillate-inc/packj/blob/main/.packj.yaml) no diretório raiz do seu repositório/projeto e reduzir a fadiga de alertas comentando atributos indesejados.
# Malware encontrado #
Encontramos mais de 40 e 20 pacotes maliciosos no PyPI e Rubygems, respectivamente, usando esta ferramenta. Vários deles foram removidos. Consulte um exemplo abaixo:
<details>
<summary><h4>Mostrar exemplo 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 sinalizou KrisQian (v0.0.7) como suspeito devido à ausência de repositório de origem e uso de APIs sensíveis (rede, geração de código) durante a instalação do pacote (em setup.py). Decidimos dar uma olhada mais aprofundada e descobrimos que o pacote era malicioso. Encontre nossa análise detalhada em [https://packj.dev/malware/krisqian](https://packj.dev/malware/krisqian).
Mais exemplos de malware que encontramos estão listados em [https://packj.dev/malware](https://packj.dev/malware). Entre em contato conosco em [[email protected]](mailto:[email protected]) para obter a lista completa.
# Recursos #
Para saber mais sobre a ferramenta Packj ou ataques à cadeia de suprimentos de software de código aberto, consulte nossos
[](https://www.youtube.com/watch?v=Rcuqn56uCDk)
[](https://www.youtube.com/watch?v=a7BfDGeW_jY)
- [palestra](https://www.youtube.com/watch?v=Rcuqn56uCDk) e [slides](https://speakerdeck.com/ashishbijlani/pyconus22-slides) do PyConUS'22.
- [apresentação](https://www.blackhat.com/asia-22/arsenal/schedule/#mitigating-open-source-software-supply-chain-attacks-26241) do BlackHAT Asia'22 Arsenal
- [palestra](https://www.youtube.com/watch?v=PHfN-NrUCoo) e [slides](https://speakerdeck.com/ashishbijlani/mitigating-open-source-software-supply-chain-attacks) do PackagingCon'21
- Palestra do BlackHat USA'22 Arsenal [Detectando typo-squatting, backdoor, abandonados e outros pacotes de código aberto "de risco" usando Packj](https://www.blackhat.com/us-22/arsenal/schedule/#detecting-typo-squatting-backdoored-abandoned-and-other-risky-open-source-packages-using-packj-28075)
- [Dissertação](https://cyfi.ece.gatech.edu/publications/DUAN-DISSERTATION-2019.pdf) acadêmica sobre segurança de software de código aberto e o [artigo](https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B-1_23055_paper.pdf) do nosso grupo na Georgia Tech que iniciou esta pesquisa.
- Palestra do Open Source Summit, Europe'22 [Pontuando dependências para detectar "elos fracos" em sua cadeia de suprimentos de software de código aberto](https://osseu2022.sched.com/overview/type/SupplyChainSecurityCon) - vídeo da apresentação no [YouTube](https://www.youtube.com/watch?v=a7BfDGeW_jY)
- [Vídeo](https://www.youtube.com/watch?v=PgvlSjl-mrY) e [slides](https://drive.google.com/file/d/1qLXIXzsIhRlS0mo8nwWI9KmD12CImZY9/view?usp=sharing) da apresentação no NullCon'22 [Desenterrando Pacotes Maliciosos e Outros "de Risco" de Código Aberto Usando Packj](https://archive.nullcon.net/website/goa-2022/speakers/unearthing-malicious-and-other-risky-open-source-packages-using-packj.php)
# Roteiro de funcionalidades #
* Adicionar analisador Rust. Rust está em andamento [ETA: Fev '24].
* Adicionar funcionalidade para detectar vários (TODO) códigos "de risco", bem como atributos de metadados [ETA: Fev '24].
* Servidor web Packj auto-hospedado e várias integrações úteis (ex: Gitlab runner) [ETA: Abr '24].
Assista :eyes: este repositório para se manter atualizado.
Tem uma solicitação de funcionalidade ou suporte? Visite nossa [página de discussão no GitHub](https://github.com/ossillate-inc/packj/discussions/) ou entre em nossa [comunidade discord](https://discord.gg/qFcqaV2wYa) para discussão e solicitações.
# Equipe e colaboradores #
Packj foi desenvolvido por pesquisadores de Segurança Cibernética na [Ossillate Inc.](https://packj.dev/team) e colaboradores externos para ajudar desenvolvedores a mitigar riscos de ataques à cadeia de suprimentos ao obter dependências de software de código aberto de terceiros não confiáveis. Agradecemos nossos desenvolvedores e colaboradores. Mostre seu apreço nos dando uma :star: se você gostou do nosso trabalho.
Membros fundadores:
* Ashish Bijlani
* Devdutt Patnaik
* Ajinkya Rajput
Aceitamos contribuições de código de braços abertos. Veja as diretrizes em [CONTRIBUTING.md](https://github.com/ossillate-inc/packj/blob/HEAD/CONTRIBUTING.md). Encontrou um bug? Por favor, abra uma issue. Consulte nossas diretrizes em [SECURITY.md](https://github.com/ossillate-inc/packj/blob/HEAD/SECURITY.md) para relatar um problema de segurança.
# FAQ #
<details>
<summary><b>Quais Gerenciadores de Pacotes (Registros) são suportados?</b></summary>
Packj atualmente pode auditar pacotes NPM, PyPI e RubyGems quanto a atributos "de risco". Estamos adicionando suporte para Rust.
</details>
<details>
<summary><b>Quais técnicas o Packj emprega para detectar pacotes arriscados/maliciosos?</b></summary>
Packj usa análise estática de código, rastreamento dinâmico e análise de metadados para uma auditoria abrangente. A análise estática por si só não é suficiente para sinalizar malware sofisticado que pode se esconder melhor usando ofuscação de código. A análise dinâmica é realizada instalando o pacote sob `strace` e monitorando seu comportamento em tempo de execução. Leia mais em [README da Auditoria](https://github.com/ossillate-inc/packj/blob/main/packj/audit/README.md).
</details>
<details>
<summary><b>Funciona em chamadas ofuscadas? Por exemplo, uma string criptografada em base64 que é descriptografada e depois passada para um shell?</b></summary>Este é um comportamento malicioso muito comum. O Packj detecta ofuscação de código, bem como a criação de comandos shell (chamada de sistema exec). Por exemplo, o Packj pode sinalizar o uso das APIs `getattr()` e `eval()`, pois indicam "geração de código em tempo de execução"; um desenvolvedor pode então analisar mais a fundo. Veja [main.py](https://github.com/ossillate-inc/packj/blob/main/packj/audit/main.py#L512) para detalhes.
</details>