CitrixBleed: quando corrigir a senha não resolveu porque a senha estava em todo lugar

Em outubro de 2023, a Citrix publicou uma correção para uma falha em vários de seus appliances de acesso, e a recommendation foi trocar a senha de todos os usuários, redefinir a configuração e reiniciar os serviços. A maior parte das organisations fez exatamente isso. E, em dezembro, a Check Point publicou um relatório mostrando que a troca de senha não tinha resolvido o problema.

A CVE-2023-4966, conhecida como CitrixBleed, permitia a um atacante extrair sessões ativas dos servidores, sem precisar de senha, e montar sua própria sessão com elas. A falha estava na memória do processo, no mesmo padrão do Heartbleed, e oTokens roubado continuava válido mesmo depois que o usuário trocava a senha, porque a sessão já estava criada.

Esse detalhe é o que transformou o caso em aviso de emergência. Trocar a senha é a resposta que todo mundo dá por hábito, e ela não funciona quando o problema é o token, e não a credencial. Quem entendeu isso a tempo teve que revogar todas as sessões, o que significa forçar o logout de todo mundo, em todas as aplicações que usam aquele appliance.

A lição é sobre a diferença entre identifier e sessão. Senha é o que identifica; sessão é o que autoriza. Quando a falha expõe a sessão, trocar a senha não serve de nada. E a segunda lição é sobre prazo: a Citrix criou um site de microserviço para rastrear a exposição, e a contagem de Knox expostos continuou crescendo por semanas depois da correção, o que mostra que a inventory de quais equipamentos estão afetados é o que realmente demora.