CVE-2022-22536

Falha de request smuggling/desync no Internet Communication Manager (ICM), o componente HTTP central do SAP NetWeaver AS ABAP, AS Java, ABAP Platform, SAP Web Dispatcher e SAP Content Server 7.53. Um atacante sem autenticação consegue prepender dados arbitrários à requisição de outro usuário, executando funções em nome dele ou envenenando caches web intermediários. É a mais grave de um trio de CVEs ("ICMAD", batizada pela Onapsis) e está no catálogo KEV da CISA com exploração confirmada.

O ICM é o processo SAP responsável por receber conexões HTTP(S)/SMTP e distribuí-las internamente via "memory pipes" (mecanismo de comunicação em memória compartilhada) para os work processes que de fato processam a requisição — no AS ABAP, no AS Java, ou dentro do próprio Web Dispatcher/Content Server que embarcam o mesmo componente ICM. A falha está em como o ICM interpreta e delimita os limites de uma requisição HTTP dentro dessa memory pipe.

Quando o atacante envia uma requisição HTTP malformada de forma específica, o ICM perde a sincronia entre o que considera o fim de uma requisição e o início da próxima. O resultado é que bytes controlados pelo atacante ficam concatenados/prependados à requisição seguinte que trafega pela mesma conexão ou pipe interna — a definição clássica de HTTP request smuggling, classificada como CWE-444 (neutralização inadequada de elementos especiais em cabeçalhos HTTP).

O atacante controla o conteúdo bruto da requisição HTTP enviada ao ICM (cabeçalhos, corpo, framing). Não precisa de credenciais nem de conhecimento prévio da sessão da vítima: a exploração ocorre no nível de protocolo, antes de qualquer autenticação de aplicação acontecer. Por isso o vetor CVSS marca PR:N e UI:N.

O fato de o mesmo defeito atravessar ABAP, Java, Web Dispatcher e Content Server confirma que o bug está no código compartilhado do ICM, não em lógica específica de uma pilha de aplicação — o que explica a superfície de exposição incomumente ampla para uma CVE da SAP.

O vetor é rede: qualquer cliente capaz de estabelecer uma conexão HTTP(S) com a porta exposta pelo ICM (tipicamente as portas de serviço do AS ABAP/Java, ou a porta pública do Web Dispatcher quando este atua como reverse proxy de entrada) pode tentar a exploração. Não há pré-condição de autenticação, configuração não padrão ou acesso interno — é isso que justifica o CVSS 9.8 e a inclusão em produção quase imediata no catálogo KEV.

Na prática, o atacante envia uma requisição desenhada para deixar "resíduo" na memory pipe do ICM; esse resíduo é interpretado pelo ICM como parte da próxima requisição processada na mesma conexão/pipe. Se a vítima seguinte for outro usuário autenticado (ou um processo de cache), o atacante consegue fazer o sistema executar uma ação com o contexto de sessão da vítima ou fazer com que um cache intermediário (reverse proxy, CDN, o próprio Web Dispatcher) armazene e sirva a resposta manipulada para outros usuários — cache poisoning.

Existem PoC públicas e template Nuclei documentados, e a CISA confirma exploração ativa (data de adição ao KEV: 18/08/2022, prazo de correção 08/09/2022). A Onapsis, que coordenou a divulgação com a SAP, relatou atividade de varredura e tentativas de exploração logo após a publicação em fevereiro de 2022. O impacto final documentado pela SAP é comprometimento total de confidencialidade, integridade e disponibilidade do sistema afetado.

A correção oficial está na SAP Security Note 3123396 (Patch Day de fevereiro de 2022, classificada como prioridade máxima/HotNews), que atualiza os binários do ICM — kernel do AS ABAP/Java, executável do Web Dispatcher (wdisp/icman) e o patch correspondente do Content Server 7.53. A nota lista as versões de kernel e de Web Dispatcher afetadas release a release; não foi possível confirmar aqui os números exatos de build para cada linha de kernel a partir das fontes disponíveis — consulte a nota diretamente (requer conta SAP para acesso ao patch).

Se a atualização não puder ser aplicada imediatamente, a própria SAP Note traz orientações de mitigação temporária específicas por componente; não há, nas fontes analisadas, confirmação de um parâmetro de perfil único e seguro para desativar a função vulnerável sem impacto — evite aplicar ajustes de configuração "por analogia" sem seguir a nota, pois o ICM é componente crítico de disponibilidade. Colocar um WAF genérico na frente do sistema não é mitigação confiável: o desync ocorre na camada de parsing interno do ICM, abaixo do que a maioria dos WAFs de borda inspeciona, e o Web Dispatcher em si é um dos componentes vulneráveis.

Como não há como restringir a exploração por autenticação (a falha ocorre antes da autenticação de aplicação), a única mitigação eficaz de fato é o patch do kernel/ICM. Segmentação de rede que reduza a exposição direta das portas HTTP do ICM à internet diminui a superfície, mas não elimina o risco em ambientes com Web Dispatcher publicamente exposto — que é justamente o caso mais comum de exploração.

Sinal de tentativa de exploração é difícil de confirmar apenas por log de aplicação, porque o desync ocorre na camada de parsing HTTP interno do ICM, antes do log de aplicação registrar a requisição de forma normal. Indicadores possíveis incluem respostas HTTP inesperadas para o cliente errado, entradas de log do ICM com erros de parsing/framing incomuns, ou comportamento anômalo de cache (conteúdo de um usuário aparecendo para outro) em Web Dispatcher/proxies na frente do ambiente SAP.

Como há template Nuclei e PoC pública circulando, ambientes expostos devem considerar qualquer tráfego com codificação chunked malformada ou cabeçalhos de framing HTTP inconsistentes dirigido às portas do ICM/Web Dispatcher como suspeito, mas não existe assinatura de rede confiável e amplamente publicada nas fontes analisadas — trate a ausência de log claro como esperada, não como evidência de que não houve tentativa.