Por que a reutilização de código ainda é um pesadelo para a segurança

Os aplicativos de software modernos são costurados a partir de milhares de componentes de terceiros buscados em repositórios públicos. Essa reutilização de código traz grandes benefícios para a indústria de software, reduzindo o tempo e os custos de desenvolvimento e permitindo que os desenvolvedores adicionem funcionalidades mais rapidamente, mas também gera grandes problemas de gerenciamento de vulnerabilidade devido ao sistema complexo de dependências que muitas vezes são difíceis de rastrear.

Vulnerabilidades herdadas de códigos de terceiros têm atormentado aplicativos por anos, mas na era dos ataques ao supply chain de software patrocinados pelo governo, o problema é mais relevante do que nunca. As ferramentas de análise de composição de software podem ajudar a descobrir alguns desses riscos, mas ainda existem pontos cegos de dependência sutis que tornam difícil até mesmo para os desenvolvedores preocupados com a segurança detectar todas as falhas herdadas.

Uma varredura recente do repositório NuGet por pesquisadores de segurança da ReversingLabs descobriu 50.000 pacotes que estavam usando uma versão desatualizada e vulnerável de uma biblioteca popular chamada zlib. Muitos deles não o listaram explicitamente como uma dependência.

O rastreamento de dependência é um acerto e erro

Para descobrir todas as vulnerabilidades, os desenvolvedores precisam rastrear não apenas quais componentes usam em seus próprios aplicativos, mas também as bibliotecas e pacotes de terceiros nos quais esses componentes se baseiam. As cadeias de dependência podem atingir muitas camadas de profundidade. Uma análise realizada em 2019 por pesquisadores da Darmstadt University no repositório npm descobriu que, em média, a importação de um pacote JavaScript introduziu confiança implícita para 79 outros pacotes de 39 mantenedores diferentes. Na época, os pesquisadores também descobriram que quase 40% dos pacotes dependiam de código com pelo menos uma vulnerabilidade conhecida publicamente.

Um problema é que apenas as dependências relacionadas a pacotes no mesmo repositório são rastreadas por repositórios de pacotes e suas ferramentas de gerenciamento de pacotes correspondentes. Mas essa não é a única maneira pela qual o código de terceiros se transforma em projetos. Alguns desenvolvedores vinculam bibliotecas estaticamente ou compilam manualmente o código de outros projetos que residem fora dos repositórios de pacotes e essas informações não são fáceis de encontrar com ferramentas de varredura automatizadas.

A ReversingLabs encontrou mais de 50 pacotes NuGet que continham vulnerabilidades exploradas ativamente porque empacotavam versões desatualizadas e vulneráveis de 7Zip, WinSCP e PuTTYgen. Esses são programas populares de compactação ou conectividade de rede que não são hospedados diretamente no NuGet, mas podem ter pacotes de invólucro disponíveis para eles no NuGet criados por outros desenvolvedores.

NuGet é o principal repositório da linguagem de programação .NET e a maioria dos componentes hospedados lá são enviados como arquivos ZIP com a extensão .nupkg e contêm bibliotecas Windows .DLL pré-compiladas que devem ser importadas para outros projetos de software.

Um pacote NuGet vulnerável encontrado por ReversingLabs é chamado WinSCPHelper e é uma biblioteca de wrapper para WinSCP. Ele permite que aplicativos que o integram gerenciem arquivos em servidores remotos por meio do protocolo SFTP. O WinSCPHelper não foi atualizado no NuGet desde 2017, mas a última versão foi baixada mais de 34.000 vezes desde que foi lançada e cerca de 700 vezes nas últimas 6 semanas. A versão mais recente do WinSCP é 5.17.10 e contém um patch para uma vulnerabilidade crítica de execução remota de código, mas a versão empacotada com WinSCPHelper é muito mais antiga — 5.11.2.

“Embora, neste caso, o pacote analisado indique claramente que usa WinSCP, ele não divulga a versão na lista de dependências e não é possível descobrir facilmente quais vulnerabilidades afetam sua dependência subjacente”, disseram os pesquisadores. “É um trabalho manual, ainda realizável, mas requer algum esforço”.

Identificando vulnerabilidades silenciosas

Mas rastrear dependências pode ser ainda mais difícil do que isso. Veja o caso da zlib, uma das bibliotecas de compactação de dados de código aberto mais amplamente usadas, originalmente escrita em 1995. Essa biblioteca se tornou um padrão quase de fato e é fornecida por seus mantenedores como código-fonte. Isso significa que os desenvolvedores tendem a compilá-lo por conta própria e vinculá-lo estaticamente em seus projetos, geralmente sem mencionar sua presença, por ser tão onipresente.

Por meio da análise de arquivos estáticos, o ReversingLabs identificou mais de 50.000 pacotes NuGet que usam zlib versão 1.2.8, que foi lançado em 2013 e contém quatro vulnerabilidades de gravidade alta ou crítica. Alguns dos pacotes identificados herdaram esta versão antiga do zlib e suas vulnerabilidades por meio de outros componentes de terceiros que não estão claramente listados como dependências, levando os pesquisadores a se referir a eles como vulnerabilidades silenciosas.

Um exemplo fornecido pelo ReversingLabs é um pacote NuGet chamado DicomObjects que implementa o protocolo Digital Imaging and Communications in Medicine (DICOM). DICOM é um padrão usado para transmitir e gerenciar dados de imagens médicas. É amplamente utilizado em hospitais e é compatível com muitos dispositivos de imagem, como scanners médicos, impressoras, servidores e estações de trabalho.

O DicomObjects, que é usado por desenvolvedores de software de saúde para construir facilmente soluções DICOM, tem quase 54.000 downloads e é mantido por uma empresa sediada no Reino Unido chamada Medical Connections. O pacote lista Microsoft.AspNet.WebApi.Client, Newtonsoft.Json e System.Net.Http como dependências, mas de acordo com ReversingLabs, ele também inclui uma biblioteca PDF comercial chamada ceTe.DynamicPDF.Viewer.40.x86.dll que não é explicitamente mencionado em qualquer lugar. DynamicPDF Viewer está listado no NuGet como um pacote separado, mas a versão empacotada em DicomObjects é muito mais antiga que inclui zlib 1.2.8.

“Este é um dos problemas mais comuns de manutenção de software”, disseram os pesquisadores. “Os desenvolvedores criam um pacote de software, decidem usar software de terceiros, mas durante as atualizações subsequentes, as dependências são ignoradas. Nesse caso, as coisas são ainda piores porque não é mencionado explicitamente em nenhum lugar que o pacote DicomObjects depende de DynamicPDF.Viewer. Não há como saber se DynamicPDF.Viewer depende da biblioteca zlib vulnerável. Empilhar dependências ocultas dessa forma leva a vários níveis de vulnerabilidades silenciosas e torna a manutenção e auditoria de software significativamente mais difícil”.

A Medical Connections não respondeu imediatamente a um pedido de comentário.

Outro exemplo é um pacote altamente popular chamado librdkafka.redist, uma biblioteca C que implementa o protocolo Apache Kafka. Apache Kafka é uma estrutura de processamento de fluxo de alto desempenho de código aberto para lidar com feeds de dados em tempo real. O pacote librdkafka.redist tem 18,9 milhões de downloads, dos quais 312.000 são para a versão mais recente, 1.7.0, lançada há 2 meses. Esta versão do librdkafka.redist usa zlib 1.2.8, mas isso não é explicitamente declarado na lista de dependências do projeto no NuGet ou no GitHub.

O problema foi relatado no rastreador de bug do projeto no GitHub há mais de um ano e atualmente está sinalizado para correção na versão 1.8.0. O desenvolvedor principal do projeto, Magnus Edenhill, analisou as quatro vulnerabilidades do zlib e disse que apenas duas delas se aplicam ao librdkafka e que o risco de explorá-las com sucesso por meio de mensagens consumidas pelo Kafka parece muito baixo. Edenhill não respondeu imediatamente a um pedido de comentário.

Treze outros pacotes NuGet dependem do librdkafka.redist, incluindo alguns desenvolvidos por uma empresa de infraestrutura de dados chamada Confluent, que tem muitos clientes corporativos de grande porte.

“O desenvolvimento seguro de software é um problema complexo, pois envolve muitos participantes em vários estágios de desenvolvimento”, disseram os pesquisadores do ReversingLabs. “Independentemente do tipo de software que sua empresa produz, mais cedo ou mais tarde, haverá a necessidade de incluir dependências de terceiros em sua solução. Isso introduzirá a necessidade de gerenciar os riscos de segurança e de qualidade de código. Os ataques à cadeia de suprimentos de software são uma ameaça crescente para a comunidade cibernética. Eles são o análogo de DDoS para violações tradicionais”.

Riscos de supply chain

O NuGet não é o único repositório de pacotes onde existe esse problema de dependência vulnerável e pode-se argumentar que não cabe ao NuGet ou a outros repositórios forçar os desenvolvedores a prestar mais atenção a esses problemas. No entanto, algumas plataformas são mais proativas do que outras. O GitHub verifica ativamente os repositórios de código públicos hospedados em sua plataforma, analisa suas dependências e notifica seus proprietários se alguma dessas dependências tiver vulnerabilidades conhecidas. A empresa mantém um banco de dados consultivo público com vulnerabilidades conhecidas em npm (JavaScript), RubyGems (Ruby), NuGet (.NET), pip (Python), Maven (Java) e acaba de anunciar suporte para módulos Go.

Em seu relatório Software Supply Chain Report 2020, a empresa de governança de código aberto Sonatype observou um crescimento ano a ano de 430% no número de ataques de próxima geração em que os hackers tentaram injetar malware ativamente em projetos de software de código aberto na tentativa de envenenar projetos e aplicativos adicionais em níveis mais altos em sua cadeia de dependências. Os ataques tradicionais em que os hackers exploram vulnerabilidades conhecidas em componentes de código aberto continuaram fortes, mas o tempo de exploração diminuiu com invasores explorando vulnerabilidades recém-descobertas poucos dias após sua divulgação pública. Enquanto isso, metade das empresas leva mais de uma semana para aprender sobre essas falhas e uma semana ou mais depois para implementar as mitigações.

Os invasores estão claramente interessados em explorar a cadeia de suprimentos de software, mas milhares de pacotes de software com vulnerabilidades herdadas ainda permanecem em repositórios públicos e servem como blocos de base para software corporativo.