technology

O malware PyPI aumenta a ameaça ao repositório de código • Strong The One

.

Pesquisadores descobriram recentemente o seguinte novo ataque ao Python Package Index (PyPI).

A ReversingLabs detectou um pacote Python em abril que misturava malware com código compilado como uma forma de evitar a detecção por ferramentas de segurança que verificam apenas os arquivos de código-fonte e não a saída compilada.

“Pode ser o primeiro ataque à cadeia de suprimentos a tirar proveito do fato de que os arquivos Python byte code (PYC) podem ser executados diretamente e ocorre em meio a um aumento nos envios maliciosos ao Python Package Index”, disse Karlo Zanki, engenheiro reverso. na ReversingLabs, escreveu em um relatório na quinta feira.

“Se assim for, isso representa mais um risco para a cadeia de suprimentos daqui para frente, já que esse tipo de ataque provavelmente passará despercebido pela maioria das ferramentas de segurança, que verificam apenas arquivos de código-fonte (PY) Python”.

É uma ameaça preocupante dado o número crescente de ataques não apenas no PyPI mas outros repositórios de código aberto como GitHub, NPMe RubyGems. Os malfeitores estão tentando inserir códigos maliciosos em pacotes por meio dessas plataformas, na esperança de que os desenvolvedores peguem um e inadvertidamente coloquem o código ruim em seu software.

Os desenvolvedores que usam o PyPI agora precisam lidar com uma possível ameaça projetada para passar despercebida pelas ferramentas de segurança populares.

Uma nova técnica de ataque

Por enquanto, o pacote descoberto pela ReversingLabs – chamado fshec2 – parece estar fora da mistura. Em 17 de abril, o biz notificou a equipe de segurança do PyPI sobre a ameaça, e ela foi prontamente removida do repositório. No entanto, a equipe do PyPI disse à ReversingLabs que nunca havia visto esse tipo de ataque antes e outros criminosos podem usar técnicas semelhantes, aparentemente.

Zanki escreveu que o ReversingLabs verifica rotineiramente os repositórios em busca de arquivos suspeitos, que tendem a se mostrar por meio de qualidades e comportamentos incomuns. O pacote fshec2 não foi diferente, mantendo URLs que referenciam um host remoto misterioso por endereço IP, criando novos processos e executando arquivos.

Um mergulho mais profundo no pacote descobriu que ele continha apenas três arquivos, dois dos quais eram benignos. No entanto, o terceiro arquivo – full.pyc – despertou o interesse dos pesquisadores. O que eles encontraram foi um carregador de malware que não seguia os padrões típicos de ataques vistos em incidentes PyPI.

A maioria desses ataques usa medidas de ofuscação para ocultar malware publicado no repositório de analistas ou ferramentas de detecção – e essas técnicas estão ficando melhores e mais abundantes. No entanto, o fschec2 não se preocupou com a ofuscação. Em vez disso, ele colocou todo o código malicioso e as funções em um único arquivo que continha o bytecode Python compilado.

Colocar tudo isso no arquivo e enviá-lo pela web também era incomum. Normalmente, os invasores obtêm a entrada inicial comprometendo um sistema e, em seguida, fazem com que as ferramentas dentro do código se comuniquem com um servidor de comando e controle (C2), que enviará o malware para ser executado.

Funções maliciosas em bytecode

Olhando mais para o arquivo full.pyc, ReversingLabs encontrou um método chamado get_path que executa as funções maliciosas esperadas vistas em outros pacotes PyPI malévolos – incluindo a coleta de nomes de usuários, nomes de host e listagens de diretórios. No entanto, get_path não é encontrado “em forma legível” dentro de fshec2 porque está no arquivo full.pyc – que contém bytecode em vez de código-fonte.

Bytecode é uma representação do código Python usado como um conjunto de instruções para a máquina virtual Python. Ao contrário do código-fonte escrito por humanos, o bytecode é um código convertido que pode ser interpretado facilmente por uma máquina, mas é difícil de ser entendido por humanos. Por isso, get_path não foi visto em formato legível e o Inspector – a ferramenta fornecida pela equipe de segurança do PyPI para escanear pacotes PyPI – não pode analisar arquivos binários em busca de conteúdo ou comportamento malicioso.

“O código compilado do arquivo .pyc precisava ser descompilado para analisar seu conteúdo”, escreveu Zanki. “Uma vez que isso foi feito, a funcionalidade suspeita e maliciosa foi fácil de ver. A descoberta de código malicioso no pacote fshec2 ressalta porque a capacidade de detectar funções maliciosas como get_path está se tornando mais importante para as equipes de segurança e DevSecOps.”

A maioria das ferramentas de segurança também não costuma executar a análise de código-fonte ao inspecionar pacotes, o que é “o motivo pelo qual o malware oculto no código de bytes compilado em Python pode passar despercebido pelo radar das soluções de segurança tradicionais”, de acordo com Zanki.

Repositórios sob ataque

PyPI, GitHub e outros repositórios foram sob ataque constante por anos. No mês passado, o PyPI – que tem mais de 455.000 repositórios de código Python – viu tantas tentativas de criar contas maliciosas e bibliotecas de código que parou de permitir novos usuários e projetos por um tempo.

Dito isso, o PyPI está trabalhando para fortalecer sua segurança. Isso significa remover o suporte automático à assinatura PGP, anunciar a Amazon Web Services como o patrocinador de segurança do grupo – incluindo um investimento de US$ 144.000 para financiar projetos de segurança – e criar uma função de engenheiro de segurança.

Mais recentemente, a organização disse que está tornando a autenticação de dois fatores um requerimento para todas as contas até o final do ano. O grupo falou sobre isso pela primeira vez em 2019 e no ano passado tornou obrigatório para projetos no top 1% dos downloads.

Outros repositórios estão fazendo o mesmo. Em março, o GitHub lançou o 2FA requisitos para desenvolvedores que contribuem para projetos públicos. No ano passado, tornou obrigatório para os mantenedores dos 100 principais pacotes npm e, posteriormente, em 2022, expandiu-o para abranger todos os mantenedores de pacotes com mais de um milhão de downloads semanais ou pacotes com mais de 500 dependentes.

RubyGems no ano passado começou exigindo autenticação multifator para proprietários de pacotes com mais de 180 milhões de downloads. ®

.

Mostrar mais

Artigos relacionados

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Botão Voltar ao topo