Manuel Roccon:14 novembro 2025 11:55
De todas as vulnerabilidades, a mais temida pelas vítimas e a mais procurada pelos invasores é a execução remota de código, ou RCE. Esta vulnerabilidade permite que comandos arbitrários sejam executados no sistema atacado. Esses comandos podem ser enviados por meio de scripts: considere uma página PHP carregada em um servidor web, comandos de shell do Windows ou até mesmo instruções de máquina no caso de estouros de buffer.
Esse tipo de vulnerabilidade permite uma rápida aquisição da vítima, e esse ataque é realizado remotamente sem acesso físico. Essas vulnerabilidades são exploradas por vários motivos, desde o acesso não autorizado ao sistema até a instalação de software não autorizado.
Mas não termina aí: alguns recursos amplificam o efeito, por exemplo, quando a vulnerabilidade é “não autenticada” (chamada RCE não autenticada) ou quando permissões elevadas são obtidas imediatamente (como “sistema” em sistemas Windows ou “root” no Linux). Vulnerabilidades como essa podem facilmente atingir pontuações CVSS de 9,8 a 10.
Que impacto uma vulnerabilidade RCE pode ter?
Aqui estão alguns exemplos do que essa vulnerabilidade pode causar:
Penetração: Os invasores podem obter acesso à rede ou ao sistema.
- Escalonamento de privilégios: Depois de obter acesso por meio de um RCE, o invasor pode tentar aumentar seus privilégios no sistema para aumentar seu impacto e obter mais acesso.
- Movimento lateral: Os invasores podem usar vulnerabilidades RCE para se mover lateralmente, comprometendo sistemas adicionais e expandindo seu controle e acesso pela rede. Isso pode levar a uma violação maior e a danos maiores.
- Exfiltração: Os invasores podem interceptar, acessar e exfiltrar informações confidenciais. Isso ocorre por vários meios, incluindo malware de roubo de dados e software de raspagem de memória que procura credenciais.
- DOS e DDOS: Os sistemas podem ser derrubados por meio de ataques RCE que esgotam os recursos da rede ou do aplicativo, negando assim o serviço legítimo do aplicativo aos usuários.
- Ransomware: Por meio dessas vulnerabilidades RCE, os invasores impedem que as vítimas acessem seus sistemas e dados em troca de dinheiro/resgate.
- Backdoors, botnets e persistência: Um invasor que comprometeu a máquina por meio de um RCE pode criar um backdoor para se reconectar à máquina sem precisar explorar a vulnerabilidade novamente. Isso é conhecido como persistência. Isso pode ser útil, por exemplo, para incorporar a máquina comprometida em um botnet.
- Danos à reputação: Um ataque RCE bem-sucedido pode prejudicar a reputação de uma organização, levando à perda de confiança do cliente. Isso pode ter efeitos de longo prazo nas relações comerciais e na posição no mercado.
- Disrupção de negócios: As vulnerabilidades RCE podem interromper as operações normais de negócios, causando interrupções no sistema, corrupção de dados e interrupções de serviço.
Essa interrupção pode afetar a produtividade, o atendimento ao cliente e a continuidade geral dos negócios.
Algumas distinções e exemplos
Um exemplo é uma vulnerabilidade encontrada há alguns anos. Era março de 2021 e uma manhã começou com um ataque devastador, inicialmente desconhecido, que afetou os sistemas de e-mail do Exchange por meio de uma vulnerabilidade de dia zero mais tarde apelidada de Proxy Logon (CVE-2021-26855 + CVE-2021-27065).
Os invasores tentaram fazer upload de código ao vivo para comprometer os servidores de e-mail, que felizmente foram detectados pelos EDRs instalados. Esse tipo de ataque é um Exemplo de execução remota de código e foi classificado como 9.8 CVSS v3. Para mais informações: https://proxylogon.com/
A maioria dos RCEs está encadeada a outras vulnerabilidades ou explorada por meio de outras fraquezas inseridas no código ou nas configurações. Vamos ver alguns deles com alguns exemplos simples:
Estouro de buffer
Na segurança de desenvolvimento de software, um estouro de buffer é uma anomalia na qual um programa, ao gravar dados de entrada excessivamente grandes em um buffer, transborda para áreas de memória adjacentes.
Assim, o programa mais tarde se verá acessando ponteiros de memória inválidos porque eles foram substituídos. Não tendo mais uma referência válida à próxima área de memória contendo a próxima instrução a ser executada, ele travará ou executará um acesso não autorizado a outra área de memória.
Um invasor, identificando e manipulando as áreas que levariam ao comportamento explicado acima, pode modificar o fluxo de execução por meio de entradas especialmente criadas, forçando o programa a executar código arbitrário injetado pelo invasor.
Tomar CVE-2017-14980, por exemplo, que afeta o Sync Breeze Enterprise 10.0.28, um programa de software de sincronização de arquivos. Este software possui uma interface da web protegida por login.
Descobriu-se que passar um nome de usuário muito longo na chamada de login fazia com que o software gerasse um estouro de buffer.
Portanto, como mencionado anteriormente, ao gerar uma carga útil especial passada na entrada do nome de usuário na solicitação de login, esse estouro de buffer pode ser explorado para executar código remoto.
Tivemos Já falei sobre isso aqui com um Exemplo prático da equipe Hackerhood
Falta de validação de entrada
Quando os dados transmitidos do cliente para o servidor não são suficientemente limpos de caracteres que podem modificar o comportamento do aplicativo, levando à execução de código arbitrário.
Uma injeção de SQL (ou SQLi) é uma vulnerabilidade de segurança do computador que permite que um invasor interfira nas consultas SQL que um aplicativo envia a um banco de dados. Essencialmente, o invasor “injeta” código SQL malicioso na entrada do usuário (como campos de texto em um formulário da web) para manipular a consulta original e obter resultados não intencionais.
Por exemplo, no MySQL, se a concessão FILE estiver habilitada nas permissões do usuário que executa as consultas, é possível executar o código remoto.
Vamos supor neste trecho de código que ele manipule a solicitação ao banco de dados para uma página antes de executá-la:
$sql = 'SELECT * FROM user WHERE username = "' + $username '"'
O aplicativo esperaria que um nome de usuário verificasse se ele existe ou não, como “Mario” . Em vez de Mario passamos este trecho de SQL:
1" union all select 1, 2, "" into OUTFILE "c:/xampp/htdocs/backdoor.php" #
Isso será adicionado ao QUERY original antes de criar um novo que o mecanismo de banco de dados executará.
SELECT * FROM user WHERE username = "1" union all select 1, 2, "" into OUTFILE "c:/xampp/htdocs/backdoor.php" #
O processo é extremamente simplificado, mas dessa forma teríamos induzido a consulta sql a gravar conteúdo em um caminho arbitrário.
http://example.local/backdoor.php?cmd=ls
Se, em vez disso, estivéssemos no ambiente do Microsoft SQL Server, poderíamos até enviar comandos shell para o mecanismo de banco de dados prontos para serem executados adicionando estes comandos à consulta original:
EXEC sp_configure 'Show Advanced Options', 1; reconfigure; sp_configure; EXEC sp_configure 'xp_cmdshell', 1; reconfigure; xp_cmdshell "whoami";
A vítima executará whoami em seu console. Uma razão para isso é a concatenação desmarcada de código e variáveis SQL, além de permitir comandos que podem ser desabilitados como FILE.
Sob algumas condições, o uso de usuários de banco de dados com privilégios elevados (como root ou sa) pode amplificar o poder do ataque e permitir, por exemplo, a execução de comandos como xp_cmdshell no mssql.
INJEÇÃO DE MODELO DO LADO DO SERVIDOR PARA RCE
Assim como na injeção de SQL, quando a entrada do usuário não filtrada é passada para um mecanismo de modelagem e isso é concatenado em modelos em vez de passado como dados, pode resultar em uma condição de execução remota de código. Vejamos um exemplo aplicado a uma versão mais antiga do Twig (1.9.0).
Os modelos estáticos que simplesmente fornecem espaços reservados para os quais o conteúdo dinâmico é redirecionado geralmente não são vulneráveis à injeção de modelo do lado do servidor, como no exemplo abaixo:
$output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );
Mas se, em vez disso, a entrada do usuário for concatenada no modelo antes de renderizar, como neste exemplo:
$output = $twig->render("Dear " . $_GET['name']);
Desta vez, os usuários podem personalizar partes do código antes de enviá-lo para renderização.
Portanto, em vez de passar um valor estático, como “mario”, passamos {{payload}} como um parâmetro GET, podendo executar código arbitrário:
http://example.com/?name={{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("ls")}}
Nesse caso, acessando o ambiente Twig e usando a função registerUndefinedFilterCallback, você pode registrar um alias para a função exec. Em seguida, chame getFilter com o comando desejado ls [call_user_func(‘exec’,’id’);].
Neste ponto, veremos a saída do comando.
Desserialização não segura
Esse método facilita a transmissão de dados empacotando-os em uma única sequência de bits, que o sistema receptor pode decodificar.
Se a estrutura dos dados serializados não estiver bem definida, um invasor poderá criar uma entrada que seria mal interpretada durante a descompactação.
Essa interpretação errônea pode levar à execução remota de código, dependendo de como os dados são processados e armazenados.
O código a seguir é um exemplo simples de como usar cPickle para gerar um auth_token, que é um objeto de usuário serializado, e salvá-lo em um cookie.
import cPickle
from base64 import b64encode, b64decode
class User:
def __init__(self):
self.username = "anonymous"
self.password = "anonymous"
self.rank = "guest"
h = User()
auth_token = b64encode(cPickle.dumps(h))
cookie = {'auth_token': auth_token}
pickle.dumps() em Python é uma função usada para serializar um objeto em um fluxo de bytes. A saída resultante pode então ser usada, por exemplo, em cookies para gerenciar processos de autenticação.
A cada solicitação, a vítima será desserializadae o objeto para reconstruí-lo.
token = cPickle.loads(b64decode(new_token))
A vulnerabilidade ocorre quando o invasor consegue manipular esse fluxo de dados, neste caso modificando o objeto serializado presente no cookie, por exemplo, do navegador.
Portanto, ao criar um novo objeto serializado ad-hoc, podemos executar código remoto na vítima assim que ele for desserializado para ler o conteúdo.
import cPickle, os
from base64 import b64encode, b64decode
class Evil(object):
def __reduce__(self):
return (os.system,("whoami",))
e = Evil()
evil_token = b64encode(cPickle.dumps(e))
Quando o objeto for desserializado no servidor, o método __reduce__ será invocado e executará o comando remoto “whoami”.
RCE VIA CONDIÇÃO DE CORRIDA
Uma condição de corrida ocorre quando o resultado final depende da ordem precisa em que esses processos/threads executam suas operações. Em outras palavras, o resultado se torna imprevisível e pode variar dependendo de qual processo “vence a corrida” para acessar o recurso primeiro.
Pegue