Cisco ISE API Unauthenticated Remote Code Execution Vulnerability
Corrige ahora. Ella está bajo explotación confirmada por CISA y tiene exploit funcional público.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumen
Falha crítica (CVSS 10.0) no Cisco ISE e ISE-PIC que permite execução remota de código como root sem autenticação, através de uma API interna usada para configuração de túneis IPsec/StrongSwan. Está no catálogo KEV da CISA com exploração confirmada e PoC pública — qualquer instância exposta nas versões afetadas deve ser tratada como comprometida ou a um passo de sê-lo.
Detalle técnico
A falha está no método enableStrongSwanTunnel da classe DescriptionRegistrationListener, exposto via endpoint /deployment-rpc/enableStrongSwanTunnel. O endpoint aceita um array de String Java serializado como corpo da requisição POST, sem autenticação. Pesquisadores da ZDI (Kentaro Kawane, GMO Cybersecurity by Ierae, e Bobby Gould) identificaram duas falhas distintas no mesmo método: uma deserialização de dados não confiáveis (o achado original reportado à ZDI) e uma injeção de comando (CWE-74) que a Cisco tratou inicialmente sob o mesmo CVE-2025-20281 antes de desdobrar parte da correção em CVE-2025-20337.
O primeiro elemento do array desserializado é passado como parâmetro IKE_ID para a função invokeStrongSwanShellScript, que monta e executa um comando via sudo chamando o script configureStrongSwan.sh com privilégios de root. O valor do IKE_ID, totalmente controlado pelo atacante, é concatenado na construção do comando sem sanitização.
A exploração inicial não é trivial porque a chamada exec() do Java 8 usa a classe StringTokenizer para dividir o comando em argumentos, e essa classe não respeita aspas nem backticks — ela simplesmente separa por espaços/tabs. Isso quebra tentativas ingênuas de injeção com espaços e aspas, porque o shell recebe o payload já fragmentado em múltiplos argumentos pelo Java antes mesmo de chegar ao bash. O atacante contorna isso substituindo espaços pela variável de ambiente ${IFS} do bash, forçando o Java a tratar o payload inteiro como um único token que, ao chegar no shell, é interpretado corretamente como comando único.
A execução inicial do comando injetado ocorre dentro de um container Docker (strongswan-container) e não diretamente no host — a ZDI documentou uma técnica adicional de escape de container para obter shell root na máquina hospedeira do ISE, elevando o impacto de comprometimento do container para comprometimento total do appliance.