Malware & Ameaças
QUANTUMINSERT: como GCHQ e NSA exploravam uma corrida TCP
Uma análise de QUANTUMINSERT por camadas: resposta concorrente, números de sequência, sobreposição de bytes e um detector didático sem envio de tráfego.
QUANTUMINSERT transforma uma corrida de rede em uma decisão de confiança: qual resposta o cliente aceita como se tivesse vindo do servidor? O tema é interessante porque a técnica não começa com acesso à senha da vítima nem com a substituição completa de um roteador. Ela explora a diferença entre observar uma comunicação e conseguir inserir dados nela antes da resposta legítima.
Esta análise trata de uma capacidade histórica discutida no acervo Snowden e de uma reprodução independente. A declaração técnica de Eric King ao tribunal britânico relaciona QUANTUM ao uso por NSA e GCHQ. Isso não atribui a ferramenta ao MI6. O SIS participa hoje do National Cyber Force, mas parceria institucional não transfere a autoria de cada ferramenta entre agências.
O que está documentado e o que é reconstrução
A pesquisa da Fox-IT, publicada em 2015, descreve um monitor que observa requests HTTP e um emissor que tenta entregar uma resposta falsa antes do servidor. A equipe publicou capturas e código de reprodução e detecção. Esse material é uma implementação de pesquisadores, não o código-fonte original da ferramenta de inteligência.
A distinção importa: um documento pode descrever intenção, uma captura pode demonstrar comportamento e um experimento pode provar viabilidade em um laboratório. Nenhum desses objetos, isoladamente, comprova que uma agência operou uma conexão observada em 2026. As seções de cálculo e o exemplo Python abaixo são modelos didáticos originais, usados para explicar propriedades do protocolo.
Man-on-the-side: o atacante acrescenta uma resposta
Em um modelo man-on-the-side, a resposta legítima pode continuar chegando. O atacante observa dados suficientes da sessão e injeta uma resposta concorrente. Isso difere de um intermediário que controla o caminho inteiro e substitui ou descarta o tráfego original. A existência de duas versões conflitantes do mesmo intervalo de bytes é uma pista dessa diferença.
Cliente envia uma request HTTP
↓
Monitor observa a sessão
↓
Resposta concorrente ──┐
├── cliente recebe duas versões
Resposta legítima ─────┘
↓
Reconstrução do fluxo e interpretação HTTPOs limites estão em camadas diferentes. IP identifica origem e destino; portas selecionam sockets; TCP organiza o fluxo; HTTP interpreta status, headers e corpo. Se a aplicação aceita texto HTTP sobre um canal sem autenticação criptográfica, a aparência de um endereço de origem não prova quem produziu os dados.
Números de sequência representam bytes, não pacotes
Considere uma sessão fictícia em que o cliente espera bytes a partir da posição 5.000. Um segmento carrega 20 bytes e cobre o intervalo de 5.000 a 5.019. Outro pode começar em 5.010 e cobrir somente parte desse intervalo. Não basta comparar números iniciais iguais: sobreposições parciais também precisam ser analisadas.
A especificação TCP atual é a referência para sequência, confirmação e processamento do fluxo. Em uma análise real, inclua estabelecimento da sessão, direção, janelas, retransmissões e wrap dos números de sequência. Um relatório que trata número de pacote do Wireshark como sequência TCP compara objetos diferentes.
A pergunta técnica é: dois segmentos propõem bytes diferentes para a mesma posição do fluxo? Uma retransmissão pode repetir bytes legítimos ou segmentá-los de outro modo. Logo, diferenças de tamanho não equivalem automaticamente a diferenças de conteúdo. O detector deve comparar a região comum e preservar a evidência original.
Detector local de sobreposição, sem enviar tráfego
O código abaixo trabalha em memória com duas mensagens sintéticas. Não abre sockets e não implementa injeção. A posição foi simplificada para um intervalo curto que não atravessa o wrap de 32 bits; também não representa SYN ou FIN. Ele demonstra apenas a comparação dos bytes na interseção de dois segmentos.
def comparar(primeiro, segundo):
seq_a, dados_a = primeiro
seq_b, dados_b = segundo
inicio = max(seq_a, seq_b)
fim = min(seq_a + len(dados_a), seq_b + len(dados_b))
if inicio >= fim:
return 'SEM_SOBREPOSICAO'
parte_a = dados_a[inicio - seq_a:fim - seq_a]
parte_b = dados_b[inicio - seq_b:fim - seq_b]
return 'CONFLITO' if parte_a != parte_b else 'REPETICAO_COMPATIVEL'
legitimo = (5000, b'HTTP/1.1 200 OK\r\n')
concorrente = (5000, b'HTTP/1.1 302 Found\r\n')
assert comparar(legitimo, concorrente) == 'CONFLITO'
assert comparar(legitimo, legitimo) == 'REPETICAO_COMPATIVEL'
assert comparar((100, b'abc'), (101, b'bc')) == 'REPETICAO_COMPATIVEL'
assert comparar((100, b'abc'), (101, b'XX')) == 'CONFLITO'
print('quatro controles locais aprovados')max encontra o início comum; min encontra o fim comum. Os slices transformam posições do fluxo em offsets dentro de cada payload. A comparação final decide se a retransmissão é compatível ou se existe conflito. É uma explicação mais precisa do que alertar sobre qualquer segmento duplicado.
Para evoluir o detector, use um parser de captura existente, limite memória por conexão e trate gaps e encerramento da sessão. Não elimine os pacotes conflitantes ao normalizar a captura. A reconstrução escolhida pelo IDS pode divergir da escolhida pelo cliente; justamente essa diferença precisa ficar disponível ao analista.
HTTP, TLS e HSTS protegem fronteiras diferentes
Uma resposta HTTP concorrente pode tentar mudar a navegação do cliente. Isso não demonstra, por si, exploração do navegador. Redirecionamento, chegada a um conteúdo e execução de código são eventos diferentes. A cadeia de evidências deve mostrar qual dessas fronteiras foi efetivamente atravessada.
Com TLS autenticado, bytes inseridos no transporte não se tornam automaticamente mensagens de aplicação válidas: precisam satisfazer as verificações do canal. A RFC 8446 descreve o modelo de TLS 1.3. Erros de validação, aceitação de certificados indevidos ou comprometimento do endpoint mudam o cenário, mas não devem ser presumidos para explicar um caso histórico de HTTP.
HSTS, definido na RFC 6797, ajuda o navegador a exigir HTTPS segundo a política conhecida para o domínio. Verifique aquisição da política e cobertura dos domínios realmente usados. Um redirect de HTTP para HTTPS protege uma etapa posterior; a primeira request HTTP ainda precisa ser considerada no modelo de ameaça.
Como interpretar os sinais sem atribuição apressada
| Sinal | Hipótese inicial | Validação necessária |
|---|---|---|
| Mesma região TCP com bytes diferentes | Conflito de reconstrução ou resposta concorrente | Direção, posição da captura e comportamento do cliente |
| TTL diferente | Caminho ou origem diferente | Baseline, rota e balanceamento |
| Redirect inesperado | Alteração da navegação | Request original, cadeia de redirects e destino |
| Somente resposta falsa no ponto observado | Visibilidade incompleta ou controle do caminho | Outra posição de captura e perdas |
TTL é uma característica de contexto. Roteamento e infraestrutura legítima também mudam essa observação. Um sistema de detecção deve conservar as explicações alternativas em vez de transformar uma anomalia em assinatura de agência. Para estudar detectores históricos, consulte o material de detecção publicado pela Fox-IT.
Um laboratório profissional precisa de resultado esperado
Comece com fixtures: retransmissão idêntica, segmentação diferente com bytes iguais, conflito total e conflito parcial. O exemplo acima cobre essas classes básicas. Em seguida, use capturas autorizadas com hashes, horários e um cliente conhecido. Defina qual interpretação o cliente teve; a simples existência de um alerta não comprova que o conteúdo concorrente foi aceito.
Meça também falsos negativos provocados por captura truncada, offload e perda. Um sensor que recebe só uma versão da resposta não pode detectar a disputa a partir daquele material. Registre a posição e as limitações do sensor. Isso transforma a ausência de alerta em uma observação delimitada, em vez de uma garantia sem fundamento.
Por que o caso continua útil em 2026
O valor do caso é ensinar a seguir confiança entre transporte e aplicação. APIs internas, consoles administrativos e integrações antigas podem manter caminhos sem autenticação adequada mesmo quando o site público usa HTTPS. A revisão deve seguir a conexão inteira, inclusive redirects e políticas do cliente.
QUANTUMINSERT é uma aula sobre corrida, reconstrução e autenticação do canal. Sua atribuição histórica precisa de documentos; sua análise técnica precisa de bytes; a avaliação de impacto precisa observar o cliente. Essa separação permite estudar uma ferramenta de inteligência sem inventar capacidades modernas ou resultados que a captura não demonstrou.
