O que os desenvolvedores podem fazer com o ataque de pacote PyPI mais recente

Um novo ataque cibernético malicioso usando grandes espaços em branco enganosos dentro de linhas de código em um pacote Python Package Index (PyPI) foi descoberto recentemente por pesquisadores de segurança e oferece lições importantes para desenvolvedores sobre como evitar ataques e vulnerabilidades semelhantes.

O código PyPI malicioso, denominado “pytoileur”, foi encontrado por pesquisadores da Sonatype, um fornecedor de otimização da cadeia de suprimentos de software, depois que um comportamento incomum foi notado no código, de acordo com uma postagem no blog Sonatype de 29 de maio. O pacote pytoileur esconde código “que baixa e instala binários trojanizados do Windows capazes de vigilância, persistência e roubo de criptografia”, de acordo com o post. “Nossa descoberta do malware nos levou a investigar pacotes semelhantes que fazem parte de uma campanha mais ampla de ‘pacote legal’ que dura meses”, continua o post.

O que torna o ataque tão astuto é que os hackers se esforçaram para incluir muitos espaços em branco para que o código errado ficasse “escondido” fora da margem direita e fosse muito mais difícil de detectar. A descoberta do código manipulado foi encontrada na linha 17 do pacote malicioso pytoileur PyPI pelo pesquisador de segurança de vulnerabilidades de código aberto da Sonatype, Jeff Thornhill, que percebeu o código oculto, de acordo com a postagem do blog.

Então, aumentando o engano, os hackers trabalharam ainda mais para esconder seu ataque, criando uma conta StackOverflow enganosa sob o nome “EstAYA G” e com o objetivo de manipular os membros da comunidade que procuravam ajuda de depuração e fazer com que instalassem o pacote malicioso para supostamente corrigiu seus problemas, continuou a postagem. Uma vez descoberta, a conta StackOverflow manipulada foi suspensa.

O pacote malicioso foi aparentemente baixado 264 vezes antes que os administradores do PyPI fossem alertados sobre sua presença, disse o post.

É necessária melhor supervisão de códigos e pacotes nas empresas

A descoberta relativamente rápida do código Pytoileur PyPI malicioso foi uma sorte, disse Katie Norton, analista de DevSecOps e segurança da cadeia de suprimentos de software da IDC, ao The New Stack, mas demonstra que as empresas devem ter políticas claras sobre o uso seguro de tais pacotes pelos desenvolvedores, ela acrescentou.

“Prevenir o download e o uso de pacotes de código aberto deve ser um esforço organizacional e não pode ser uma responsabilidade deixada a desenvolvedores individuais”, disse Norton. “Na ‘Pesquisa de adoção, técnicas e ferramentas de DevSecOps de 2023’ da IDC, os entrevistados identificaram o conhecimento de segurança do desenvolvedor como seu principal desafio organizacional na adoção de DevSecOps.”

A maioria dos desenvolvedores não apenas não possui o conjunto de habilidades para identificar pacotes maliciosos, disse ela, mas também enfrenta uma tarefa quase impossível de fazer isso manual e individualmente. De acordo com um relatório Sonatype State of the Software Supply Chain de 2023, houve mais de 245.032 ataques de pacotes maliciosos registrados, disse ela.

Para combater esses enganos, disse Norton, uma ampla gama de ferramentas comerciais e de código aberto pode ajudar nessa luta. Isso inclui ferramentas baseadas em políticas, incluindo JFrog Curation, OpenText Open Source Select e Sonatype Firewall, que impedem os desenvolvedores de usar pacotes de código aberto que não estejam alinhados com as políticas de segurança da empresa.

Catálogos de código aberto selecionados ou gerenciados como Tidelift, Chainguard Images, Google Assured Open Source e VMware by Broadcom Tanzu Application Catalog também podem ser usados ​​para fornecer aos desenvolvedores código seguro para seu trabalho, disse Norton.

“Em vez de ir para um repositório público, os desenvolvedores obtêm seu código aberto diretamente desses catálogos que são pré-avaliados e muitas vezes têm SLAs para remediar vulnerabilidades ou fortalecer o componente”, disse ela. “Isso também poderia ser feito internamente se a organização tiver recursos suficientes”.

Outras ferramentas como Snyk Advisor, Open Source Insights e Trusty by Stacklok também podem ser usadas para agregar metadados de pacotes e métricas de segurança em um banco de dados pesquisável que pode ajudar os desenvolvedores a identificar o pacote de código aberto mais seguro para usar, disse Norton. “Existem extensões de navegador, como o Socket e o Overlay, que permitem aos desenvolvedores ver essas informações enquanto procuram pacotes nos registros públicos, em vez de pesquisar em um banco de dados. Também vimos IA generativa usada aqui, como o DroidGPT da Endor Labs, onde os desenvolvedores podem usar linguagem natural para pedir sugestões de pacotes seguros para usar.”

Existem até esforços em nível governamental para ajudar a melhorar o uso seguro de pacotes e códigos baseados na comunidade pelos desenvolvedores, disse Norton. Isso inclui esforços da Agência Federal de Segurança Cibernética e de Infraestrutura (CISA) para trabalhar em estreita colaboração com repositórios de pacotes para adotar as diretrizes dos Princípios para Segurança de Repositórios de Pacotes e do Grupo de Trabalho de Proteção de Repositórios de Software da Open Source Security Foundation (OpenSSF), disse ela.

Cinco repositórios de pacotes se comprometeram no Open Source Software Summit deste ano a trabalhar no sentido de atender às diretrizes da CISA e do OpenSSF sobre este problema, disse Norton. Eles incluíam a Rust Foundation, a Python Software Foundation, npm (JavaScript), Packagist and Composer (PHP) e Maven Central (Java), observou ela. Exemplos desses esforços de segurança incluem autenticação multifator (MFA), geração de proveniência de pacotes por meio de assinatura criptográfica e verificação de vulnerabilidades.

As regras de higiene de software devem sempre ser seguidas

Outro analista, Jack Gold, presidente e analista principal da J. Gold Associates, concordou que os desenvolvedores só podem evitar o uso de código problemático sabendo absolutamente que o código e os pacotes são comprovadamente seguros.

“O problema básico é simples”, disse Gold. “Como você sabe que o código que está usando para construir seu programa é confiável, seguro e protegido? Os programas que você baixa para facilitar sua vida são realmente seguros? O repositório de código do qual você está obtendo é realmente capaz de verificar e proteger esse código? Pelo menos com o código comercial, você tem uma empresa para perseguir. Com coisas como essa, não há recurso e nenhuma maneira real de saber, a menos que uma empresa como a Sonatype faça uma triagem para você.”

Em última análise, “as regras de higiene de software devem sempre ser seguidas”, disse Gold. “Suspeite de tudo que você baixa de um código aberto. Nunca presuma que alguém que escreveu algo que você pode usar não tem segundas intenções.”

Rob Enderle, analista principal do Enderle Group, também aconselha que os desenvolvedores tenham muito mais cautela e ceticismo em relação ao código que estão usando, submetendo-o à verificação adequada.

“Muitas vezes, olhamos para ataques como este como eventos isolados e não como uma nova tendência, sugerindo que provavelmente existem outras explorações como esta que se concentram em desenvolvedores que ainda não encontramos”, disse Enderle. “No centro desta questão estão as pessoas que entram em um processo colaborativo que são maus atores, sugerindo que os desenvolvedores deveriam sair de qualquer colaboração onde os outros membros do esforço não tenham sido avaliados e garantidos como confiáveis ​​e confiáveis”.

O que é necessário, disse ele, é implementar uma supervisão agressiva para garantir que os promotores envolvidos nestes projectos não sejam comprometidos. “Isso também sugere que mesmo membros confiáveis ​​precisam ser verificados aleatoriamente para garantir que não foram comprometidos”, disse Enderle.

Os riscos são grandes, especialmente em relação à confiança e confiabilidade na comunidade de código aberto, disse Enderle. “O perigo real aqui é que um ataque grande o suficiente e eficaz poderia matar o código aberto como prática, o que teria um impacto adverso significativo na capacidade dos desenvolvedores de fazer seu trabalho da maneira que desejam”, disse ele.

O grande desafio, acrescentou, é que os hackers estão sempre trabalhando para esconder seus truques das verificações e ferramentas que tentam encontrá-los.

Ferramentas de IA podem ser agentes de mudanças drásticas para resolver esses problemas

O que poderia ajudar a combater esses tipos de ataques, disse Enderle, são ferramentas avançadas de IA que poderiam ser projetadas para verificar agressivamente cada linha de código e sinalizar quaisquer anomalias incomuns. Também poderiam ser criadas ferramentas de IA que executem automaticamente novo código em uma sandbox por um período fixo para identificar qualquer comportamento hostil que possa ser revelado em revisões de qualidade de código, acrescentou.

Essas ameaças constantes de hackers tornam ainda mais difícil para os desenvolvedores construir seus códigos de forma eficiente e adicionam uma pressão intensa que pode ser debilitante à sua criatividade, disse Enderle.

“As pessoas não podem trabalhar constantemente sob esse tipo de pressão, então a solução é automatizar essas verificações tanto quanto possível e validar totalmente todos os participantes inicialmente e, em seguida, verificar aleatoriamente seu trabalho para garantir que um malfeitor não entre no processo”. disse Enderle.

“Isso é tanto um problema de pessoas quanto de prática de código”, disse Enderle. “A correção do componente de pessoas deve ter o maior impacto positivo inicial, mas isso também precisa ser apoiado por uma revisão de código agressiva e abrangente, sugerindo um processo de controle de qualidade orientado por IA.”

A postagem O que os desenvolvedores podem entender do último ataque ao pacote PyPI apareceu pela primeira vez em The New Stack.