0
0
Embora todas as redes corporativas, grandes e pequenas, se esforcem para implementar políticas de segurança para garantir que os usuários só possam trabalhar com aplicativos e serviços de dados legítimos — quando a própria cadeia de suprimentos de software principal é comprometida, as próprias ameaças ganham um novo nível de legitimidade. Os usuários geralmente são problemáticos, mas as ameaças podem começar no próprio cano.
Os usuários são imprudentes, todo engenheiro de software sabe disso. Talvez em nenhum lugar os usuários sejam mais imprudentes do que em zonas da rede corporativa onde violações de segurança podem ser abertas através do contato com malware, ou quando vulnerabilidades do sistema são involuntariamente expostas.
Ao usar seu próprio dispositivo Bring Your Own Device (BYOD) e mesmo ao usar dispositivos corporativos aprovados e aparentemente bloqueados, os usuários parecem ter uma capacidade dada por Deus de abrir macros desnecessárias em documentos, clicar em links maliciosos, contornar a política da empresa instalando a “TI sombra” ou realmente ir à cidade e começar a conectar unidades USB externas a todos os orifícios disponíveis que puderem encontrar.
Mas por mais cabeça que o usuário mais parecido com galinha possa ser, a fonte e o combustível para ameaças nem sempre se resumem aos funcionários não técnicos de uma organização; às vezes, a fonte do problema é o próprio software.
Uma rachadura no DNA em nível de sistema
Uma maneira pela qual os ataques à cadeia de suprimentos de software ocorrem é quando um agressor é capaz de acessar os sistemas de software usados por uma empresa por meio de malware instalado em uma vulnerabilidade – tecnicamente falando, definida como uma “fraqueza explorável” – no software de um parceiro ou provedor terceirizado confiável. Fraquezas exploitáveis podem ocorrer em qualquer fase do ciclo de vida do software; e embora na maioria das vezes aconteçam como resultado de práticas de desenvolvimento e atualização de baixa qualidade, elas também podem ser o resultado da inserção “proposital” de código malicioso.
Em um mundo onde todos nós estamos tentando mudar para ferramentas de infraestrutura autônomas capazes de realizar atualizações, manutenção, atualizações, patches etc. sem a necessidade de um engenheiro de rede estar sempre fisicamente presente, quando há uma falha de projeto em ferramentas automatizadas de construção e instalação, estamos olhando para uma rachadura no próprio DNA do sistema de software da organização e seu ciclo de vida mais amplo.
Gerente de Marketing de Conteúdo da empresa de plataforma de gerenciamento de conformidade de segurança e licença de código aberto WhiteSource é Julie Peterson. Explicando a mecânica de um ataque à cadeia de suprimentos de software, Peterson diz que atores maliciosos se infiltram em um aplicativo legítimo e depois alteram o código-fonte e ocultam malware em processos de compilação e atualização com a intenção de distribuir esse malware a jusante automaticamente para um público mais amplo.
“Neste tipo de ataque, a vítima original não é o alvo final, mas sim um trampolim para muitas outras redes em potencial. O fornecedor confiável não tem conhecimento de que está enviando código malicioso para seus clientes”, disse Peterson, em um blog de análise descritiva. “Esses tipos de ataques funcionam porque ocorrem quando os usuários atualizam softwares criados por um fornecedor com o qual já têm um relacionamento e confiam. Quando o código malicioso é instalado no site da organização de destino, ele é executado com as mesmas permissões que o aplicativo confiável.”
O ataque de 2020 à plataforma Orion da SolarWinds foi um ataque à cadeia de suprimentos de software. Peterson, da WhiteSource, também explicou como a rotulagem externa e o empacotamento de arquivos e dependências podem dar origem a ataques à cadeia de suprimentos. Ela compara essa técnica a um comprador que visita seu supermercado e pega uma caixa de Fruit Loops, apenas para descobrir que as mercadorias dentro contêm muesli orgânico de mudança intestinal.
Sobredependência de dependências
Um ataque de “teste” da cadeia de suprimentos de software relacionado à dependência foi realizado em fevereiro de 2021 pelo hacker ético Alex Birsan, que detalhou suas táticas em uma explicação pessoalmente escrita.
Sabemos que os programadores usam relações de dependência ‘acopladas’ ao codificar, onde um módulo ou rotina de software dependerá de outro, geralmente para uma parte bastante central e importante de sua operação. Birsan notou que um sistema PayPal usava uma mistura de pacotes npm (Node Package Manager) públicos e privados. Ele carregou um código público malicioso renomeado para parecer que tinha o mesmo rótulo que o código de pacote privado para ver se ele poderia ser mais esperto que o sistema.
Acontece que essa técnica não só funcionou, como também mostrou que esse tipo de software carregaria automaticamente pacotes (público ou privados) simplesmente com base em se eles tinham números de versão mais altos para torná-los mais atualizados.
“Algumas linguagens de programação, como Python, vêm com um método fácil, mais ou menos oficial de instalar dependências para seus projetos. Esses instaladores geralmente estão vinculados a repositórios de código públicos, onde qualquer pessoa pode fazer upload gratuito de pacotes de código para outros usarem. Ao baixar e usar um pacote de qualquer uma dessas fontes, você está essencialmente confiando em seu editor para executar código em sua máquina”, disse Birsan, que questionou se estamos colocando muita confiança cega dentro do tubo da cadeia de suprimentos de software.
O diretor de Segurança da Cadeia de Valor da empresa de qualidade de software Synopsys Emile Monette explica que (com referência a todos os exemplos acima) a SolarWinds expôs o que é claramente um alvo suave para possíveis atacantes. Ele diz que isso ocorre porque muitos provedores de software não verificam rotineiramente a integridade das bibliotecas das quais seu código depende.
“Esse problema talvez seja mais agudo e visível em bibliotecas de código aberto, mas também pode ser um problema significativo com terceiros comerciais ou outros repositórios de código comercial,” disse Monette. “Os fornecedores de software devem tomar nota e tomar medidas para garantir que estejam confiando em bibliotecas de código que têm sido verificadas regularmente em busca de fraquezas e vulnerabilidades conhecidas. Além disso, quando uma fraqueza ou vulnerabilidade é encontrada, deve tomar medidas imediatas para remediar.”
O estado dos ataques patrocinados pelo Estado
O fato é que as organizações precisam trabalhar com práticas de segurança que forneçam evidências objetivas de que a própria empresa e seus fornecedores estão cuidando adequadamente dos ativos de informação. Monette da Synopsys sugere que, do seu ponto de vista, o mundo pode esperar que mais desse tipo de vulnerabilidade surjam.
“Com o aquecimento das guerras comerciais, existe o potencial de que veremos um aumento nos ataques da cadeia de suprimentos patrocinados pelo Estado destinados às indústrias de defesa do Ocidente e de seus aliados e às empresas de tecnologia comercial que o fornecem. Esses atacantes terão muito recursos e terão como alvo ativamente elos fracos na cadeia de suprimentos para obter acesso a parceiros de negócios e clientes nos setores de defesa e tecnologia que buscam obter informações científicas, técnicas e comerciais”, disse Monette.
Parece claro que precisamos lidar com o código do fornecedor que foi levado às pressas para o mercado, sem restrições de segurança suficientes sendo consideradas. Talvez haja um falso senso de garantia de que, ao aplicar patches de fornecedores, eles também garantirão total segurança. Uma boa segurança não é apenas patches – é um processo. Este é o mantra oferecido por Sree Sakamuri é sua capacidade como arquiteto sênior de soluções, Oracle, na Spinnaker Support, um provedor de suporte de terceiros, serviços gerenciados e consultoria.
“Existem três táticas principais que podemos usar aqui. A primeira é a visibilidade – saber exatamente o que está preso a uma pilha, como ela está configurada, onde está e de onde é. Uma vez que tenhamos esse mapa, o segundo passo é endurecer. Lista branca de IPs, restrição de acesso e retirada de qualquer software ou sistema que não esteja certo. O terceiro passo é estar preparado para se adaptar e ficar um passo à frente”, aconselha Sakamuri.
Sakamuri nos lembra ainda que toda vulnerabilidade se enquadra em uma categoria; seja ganhando privilégios elevados ou divulgação de informações. Eles são CWEs – Common Weakness Enumerations – ou CVEs – Common Vulnerabilities and Exposures. “Ao implementar medidas para bloquear CWEs, você também está efetivamente limitando esses ataques à cadeia de suprimentos”, concluiu.
Se aceitarmos que as vulnerabilidades de software não se resumem apenas a usuários aleatórios, colocando cliques em ‘dedo de salsicha’ em links suspeitos, macros e portais carregados de desgraça, talvez possamos pensar em engenharia de software em um nível mais alto, mas também crucialmente, mais profundo que leve em conta os ingredientes que estamos colocando na mistura a partir de um nível de código principal.
Então, talvez então, possamos sentar e aproveitar nossos cafés da manhã e continuar com o nosso dia. Espere, espere – Pensei ter pedido Froot Loops!?
FONTE: INSIDER PRO