Falha no n8n expõe contas: como evitar roubo de identidade

Uma vulnerabilidade crítica no mecanismo de troca de tokens da plataforma de automação n8n expôs contas de usuários a acessos indevidos. A falha, reportada pelo The Hacker News, permitia que um atacante autenticado em um emissor de tokens confiável realizasse login como outro usuário, simplesmente manipulando o campo sub do JWT. Em ambientes corporativos que utilizam múltiplos provedores de identidade, o n8n ignorava o campo iss (issuer), validando apenas o sub (subject). Isso criava uma janela perigosa para escalada de privilégios e roubo de identidade digital, com potencial para comprometer fluxos de trabalho automatizados e dados sensíveis. A correção já foi disponibilizada, mas o incidente reacende o debate sobre a higiene de autenticação em plataformas de orquestração.

O problema não é isolado: a confiança excessiva em tokens sem validação completa de claims é um vetor recorrente em vazamentos de dados. Em um cenário onde a superfície de ataque se expande com a adoção de SaaS e APIs, a negligência na verificação de identidade pode ser catastrófica. Este artigo disseca a falha, seus indicadores de comprometimento e a relação direta com táticas de engenharia social por telefone, um método cada vez mais usado para obter credenciais iniciais e explorar brechas como essa.

Anatomia da falha: troca de tokens sem verificação de issuer

O cerne da vulnerabilidade reside na implementação do fluxo de autenticação OAuth2/OIDC no n8n Enterprise. Quando uma instância é configurada para confiar em mais de um provedor de identidade (por exemplo, Azure AD e Okta), a aplicação deve validar não apenas a assinatura do token, mas também claims críticas como iss e aud. No caso reportado, o n8n utilizava exclusivamente o campo sub para mapear o token a um usuário local, desprezando completamente o iss.

Isso significa que um token JWT válido emitido pelo Provedor A, mas com um sub que coincidia com o identificador de um usuário do Provedor B, permitia o login como esse usuário no n8n. O atacante não precisava violar a criptografia ou obter a senha da vítima; bastava um token legítimo de qualquer emissor confiável e o conhecimento do identificador do alvo. A falha foi classificada como de alta severidade, pois quebra a premissa fundamental de isolamento entre domínios de identidade.

Pré-requisitos para exploração

• Instância n8n Enterprise configurada com múltiplos emissores de token (ex.: SAML, OIDC).
• Atacante possui uma conta válida em ao menos um dos provedores confiáveis.
• Conhecimento do sub (identificador) do usuário alvo sob outro emissor.
• Capacidade de forjar ou obter um token JWT assinado pelo emissor onde possui conta.

Embora os pré-requisitos pareçam restritivos, em organizações de médio e grande porte é comum a coexistência de múltiplos IdPs, especialmente durante migrações ou fusões. Além disso, o identificador sub muitas vezes segue padrões previsíveis, como e-mail ou UPN, facilitando a enumeração.

Consequências para a segurança corporativa e vazamentos de dados

O impacto de uma autenticação indevida no n8n vai além do simples acesso à interface de administração. A plataforma é utilizada para orquestrar fluxos de trabalho que frequentemente manipulam dados sensíveis: integrações com bancos de dados, APIs de CRM, sistemas financeiros e pipelines de CI/CD. Um invasor autenticado como um usuário legítimo poderia:

• Exfiltrar dados confidenciais através de workflows maliciosos.
• Modificar automações para injetar código ou redirecionar saídas.
• Utilizar credenciais armazenadas no n8n para pivotar para outros sistemas.
• Apagar registros de auditoria para encobrir a atividade.

Essa cadeia de eventos caracteriza um vazamento de dados de alto impacto, pois a violação inicial pode permanecer oculta por semanas. A falta de validação de issuer é um exemplo clássico de falha de lógica de negócio que contorna controles de perímetro. Em 2023, um estudo da IBM apontou que o tempo médio para identificar uma violação de dados é de 207 dias; falhas como a do n8n reduzem drasticamente a probabilidade de detecção precoce.

Indicadores de comprometimento (IOCs) e monitoramento

Para organizações que utilizam n8n Enterprise com múltiplos IdPs, é crucial revisar logs de autenticação em busca de anomalias. A tabela abaixo lista indicadores de comprometimento que podem sugerir exploração da falha ou atividades maliciosas relacionadas.

Recomenda-se a implementação de alertas em tempo real para esses padrões, integrando os logs do n8n a um SIEM. A correlação com eventos de outros sistemas pode revelar movimentação lateral a partir da plataforma comprometida.

Engenharia social por telefone: o elo humano na cadeia de ataque

A exploração da falha no n8n não requer, necessariamente, uma vulnerabilidade técnica inicial. O vetor de entrada mais provável é a engenharia social por telefone, frequentemente subestimada em ambientes corporativos. Um atacante poderia obter o token JWT ou o identificador sub de um usuário através de uma ligação persuasiva, fingindo ser do suporte de TI e solicitando "confirmação de identidade".

Considere o seguinte cenário: um funcionário recebe uma chamada de um número aparentemente interno, com o interlocutor alegando ser da equipe de segurança e reportando uma "atividade suspeita na conta". Sob pressão, a vítima fornece detalhes como seu e-mail corporativo ou até mesmo um código de verificação. Esse e-mail, muitas vezes, é exatamente o valor do campo sub no JWT. Com essa informação e um token válido de qualquer emissor (obtido através de phishing ou comprado em mercados clandestinos), o atacante pode realizar o login indevido no n8n.

Esse tipo de ataque é particularmente eficaz porque contorna a autenticação multifator (MFA) tradicional: o token JWT já representa uma sessão autenticada. A engenharia social por telefone é o catalisador que transforma uma falha de configuração em uma violação completa. Leia também nosso artigo sobre Registros DNS Estranhos e Golpes de Phishing: Proteja-se, onde detalhamos como ataques de phishing muitas vezes precedem a obtenção de credenciais usadas nesse tipo de exploração.

Medidas de proteção contra engenharia social telefônica

• Verificação de identidade reversa: nunca forneça informações pessoais ou códigos a chamadas recebidas. Desligue e ligue para o número oficial da empresa.
• Treinamento contínuo: simulações de phishing por voz (vishing) para conscientizar colaboradores sobre táticas de pressão e urgência.
• Política de senhas e tokens: proíba estritamente o compartilhamento de tokens, códigos OTP ou credenciais por telefone.
• Monitoramento de chamadas: em ambientes críticos, grave e audite aleatoriamente chamadas de suporte para identificar padrões de engenharia social.

A integridade da identidade digital depende tanto de controles técnicos quanto da resiliência humana. A falha do n8n é um lembrete de que a autenticação federada exige validação rigorosa de todos os atributos do token, mas também de que a superfície de ataque inclui o elemento humano.

Lições aprendidas e resposta a incidentes

Este incidente oferece lições valiosas para equipes de segurança e arquitetos de identidade. A resposta a incidentes deve começar com a aplicação imediata do patch disponibilizado pelo n8n (versão 1.91.1 ou superior). Contudo, a remediação completa exige uma revisão arquitetural:

• Validação explícita de issuer: garanta que todas as aplicações que consomem JWTs validem os campos iss, aud, exp e nbf de acordo com a RFC 7519.
• Mapeamento restrito de identidades: utilize identificadores únicos e não previsíveis para sub, como UUIDs, em vez de e-mails.
• Segregação de ambientes: evite que múltiplos IdPs compartilhem o mesmo namespace de usuários sem uma camada de abstração.
• Logging e auditoria: habilite logs detalhados de autenticação, incluindo todas as claims do token, e armazene-os em local seguro e imutável.

Além disso, é fundamental considerar o impacto de vazamentos de dados prévios. Mesmo com a falha corrigida, credenciais ou tokens obtidos anteriormente podem ser usados em ataques futuros. Nesse contexto, a vigilância sobre a exposição de identidades na dark web é essencial. Como abordamos em Vigilância por IA: Como proteger suas contas de redes sociais, a inteligência artificial está sendo usada para automatizar a coleta de dados vazados e potencializar ataques de sequestro de conta.

FAQ - Perguntas Frequentes

O que é a falha de troca de tokens do n8n?

É uma vulnerabilidade em instâncias Enterprise do n8n configuradas com múltiplos provedores de identidade, onde o sistema validava apenas o campo sub do JWT, ignorando o emissor (iss). Isso permitia que um token de um emissor confiável autenticasse como um usuário de outro emissor.

Como posso saber se minha instância n8n foi afetada?

Verifique a versão do n8n: versões anteriores à 1.91.1 são vulneráveis. Analise logs de autenticação em busca de inconsistências entre o emissor do token e o domínio do usuário, ou acessos de IPs não reconhecidos.

A falha já foi corrigida? O que devo fazer?

Sim, a correção está disponível na versão 1.91.1 e superiores. Atualize imediatamente e force a rotação de todas as sessões e tokens de acesso. Revogue credenciais de serviço que possam ter sido comprometidas.

Qual a relação entre essa falha e vazamentos de dados?

Um invasor que explore a falha pode acessar workflows que manipulam dados sensíveis, levando à exfiltração de informações confidenciais. Além disso, o acesso indevido pode ser usado para persistência e movimentação lateral, ampliando o escopo do vazamento.

Como a engenharia social por telefone pode ser usada nesse ataque?

Atacantes podem ligar para funcionários se passando por suporte de TI para obter o identificador sub (geralmente o e-mail) ou até mesmo tokens de acesso. Com essas informações, exploram a falha para assumir a conta da vítima no n8n.

Como a Kzarka pode ajudar a proteger minha identidade digital?

A Kzarka monitora continuamente a dark web e fontes de vazamentos de dados em busca de suas credenciais expostas. Se seus dados aparecerem em uma violação, você é alertado imediatamente, permitindo ações de remediação antes que sejam usados em ataques como o descrito. Acesse Kzarka e verifique agora se sua identidade digital está segura.