Inlead Funnel Disclosure

1. Visão geral da plataforma

A Inlead é uma plataforma SaaS brasileira que permite a criação e hospedagem de funis interativos no formato quiz — uma alternativa nacional ao Typeform com foco em conversão (não coleta). Funis típicos têm 20–75 etapas e seguem o padrão metodológico de info-produto low-ticket: bloco de perguntas que qualificam e engajam → diagnóstico personalizado → captação de lead (nome + WhatsApp) → pitch de oferta com ancoragem.

Arquitetura observada:

• Aplicação Next.js servida via Vercel (header x-vercel-id) com camada de borda Cloudflare
• Páginas geradas via Static Site Generation (SSG) ou Server-Side Rendering (SSR) — em ambos os casos, o conteúdo do funil vai embutido no HTML inicial
• Hospedagem padrão em inlead.digital/{slug}; domínios personalizados disponíveis para planos superiores
• Assets servidos por media.inlead.cloud (CDN próprio em CloudFront)
• Painel administrativo do cliente em app.inlead.digital

O modelo de monetização é por assinatura mensal por usuário; quizzes públicos são identificados por user_id interno (campo user no payload do funil).

2. Vulnerabilidade identificada

2.1. Natureza técnica

A vulnerabilidade é classificada como Information Disclosure (CWE-200) agravada por distribuição insegura de chave criptográfica (CWE-321 / CWE-321-like). O comportamento técnico:

1. Quando um usuário acessa inlead.digital/{slug} (ou o domínio personalizado equivalente), a Inlead retorna um documento HTML com um bloco <script id="__NEXT_DATA__"> contendo o estado serializado do componente Next.js.
2. Esse estado inclui um campo props.pageProps.f — uma string de 10KB a 600KB — que contém todo o conteúdo do funil (perguntas, layers, lógica, ofertas, métricas, webhook, pixels) criptografado.
3. A criptografia é AES-CBC no formato CryptoJS (prefixo Salted__ + salt de 8 bytes), com derivação de chave via EVP_BytesToKey + MD5.
4. A chave de criptografia é enviada na mesma string, embaralhada em um esquema posicional reversível (6 caracteres extraídos de uma janela predefinida do payload).
5. O código JavaScript que executa a descriptografia no navegador é servido publicamente como um chunk Next.js (path /_next/static/chunks/pages/[...all]-*.js) — qualquer um pode lê-lo via View Source ou requisição HTTP simples.

2.2. Vetor de ataque

Ataque é executável remotamente, sem autenticação, sem interação do usuário-vítima, e sem ferramentas especializadas. As capacidades necessárias resumem-se a:

• Fazer uma requisição HTTP GET para a URL pública do funil
• Parsear o HTML retornado (qualquer cliente HTTP)
• Executar um decifrador AES-CBC com derivação MD5 (suportado nativamente em qualquer linguagem moderna)

O esforço para descobrir e implementar o algoritmo a partir do chunk JS público foi de aproximadamente 15 minutos para um engenheiro com familiaridade básica em criptografia simétrica e ferramentas web.

2.3. Algoritmo (visão de alto nível)

Sem expor código copy-paste, o algoritmo segue o padrão:

1. Descarta-se um prefixo fixo de N bytes do payload
2. Lê-se um único caractere como offset numérico
3. Extrai-se uma janela contígua de 26 caracteres logo após o offset
4. A chave AES é uma sub-string de 6 caracteres dessa janela, indexada pelo offset
5. O ciphertext começa imediatamente após a janela
6. Decodifica-se o ciphertext em base64, valida-se o prefixo Salted__, extrai-se o salt de 8 bytes
7. Deriva-se key (32 bytes) + IV (16 bytes) usando EVP_BytesToKey + MD5
8. AES-CBC decrypt + PKCS7 unpadding entrega o JSON cru do funil

O esquema é uma forma de security through obscurity. A literatura de segurança é unânime em desencorajar essa estratégia há mais de 130 anos (Princípio de Kerckhoffs, 1883).

2.4. Dados expostos

O JSON descriptografado contém:

3. Impacto e severidade

3.1. Análise CVSS v3.1

Vetor: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N · Base Score: 7.5 (HIGH)

3.2. Impacto para clientes-operadores

• Perda de propriedade intelectual: meses de iteração em copy, ordem de perguntas, ofertas, ancoragem e timing são extraídos em minutos por concorrentes.
• Vazamento de inteligência operacional: volume real do funil, taxa de conversão por step e ROI são visíveis a qualquer terceiro.
• Endpoint do webhook exposto: URLs de n8n self-hosted ou serviços terceiros (Make, Zapier, ActiveCampaign) ficam acessíveis. Ataques de spam, descoberta de stack interno e tentativas de injeção tornam-se viáveis.
• Risco regulatório (LGPD): embora os leads em si não sejam expostos (apenas contagens agregadas), a exposição de pixels e webhooks pode complicar auditorias de fluxo de dados pessoais — especialmente se o webhook for hospedado em jurisdições com regimes distintos.

3.3. Impacto para o fornecedor (Inlead)

• Diferenciação competitiva comprometida: a propriedade intelectual que os clientes investem na plataforma é parte do que justifica a assinatura. Quando ela é facilmente replicável, a proposta de valor enfraquece.
• Risco reputacional: uma vez publicizada (em fóruns técnicos, redes sociais ou pela imprensa), a percepção de "plataforma vazada" é difícil de reverter.
• Sinais internos públicos: as flags has_fraud_keywords e is_validated são expostas, dando a qualquer pessoa acesso ao critério de moderação interna do produto.

3.4. Impacto para usuários finais (leads)

• Indireto e baixo, mas existe. Como o webhook é exposto, leads capturados podem ser direcionados a sistemas terceiros sem que o usuário tenha forma trivial de verificar.

4. Prova de conceito (alto nível)

Por princípio de disclosure responsável, este documento não inclui código pronto para exploração. O processo, descrito de forma genérica, é:

1. Identificar funis Inlead em escala. O Internet Archive (Wayback Machine) expõe, via API pública CDX, todos os slugs já indexados no domínio inlead.digital/*. Em nossa análise, isso retornou ~916 slugs únicos.
2. Para cada slug ativo, requisitar a página HTML. O HTML retorna em ~100 KB com o payload embutido.
3. Extrair o campo props.pageProps.f do __NEXT_DATA__.
4. Aplicar o algoritmo descrito em §2.3 para obter o JSON cru.

Sem qualquer captcha, rate limiting agressivo ou bot detection observado durante a coleta. Foi possível processar 81 funis em ~3 minutos com paralelismo modesto (4 workers concorrentes).

6. Disclosure responsável

Sugerimos o seguinte processo de divulgação ao fornecedor:

Apêndice A — Classificação CWE/CVSS

CWE primário

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

CWE secundário

CWE-321: Use of Hard-coded Cryptographic Key (efeito equivalente)

CWE terciário

CWE-922: Insecure Storage of Sensitive Information (chave + cipher coabitam)

CWE quaternário

CWE-656: Reliance on Security Through Obscurity

CVSS v3.1 Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Base Score

7.5 (HIGH)

Temporal Score

7.2 (HIGH) — assumindo exploit code disponível em chunk JS público (E:F = Functional)

Environmental Score

varia por cliente; tipicamente HIGH

Apêndice B — Glossário técnico

SSG / SSR

Static Site Generation / Server-Side Rendering — modelos de entrega de página Next.js onde o HTML é montado antes ou no momento da requisição

AES-CBC

Advanced Encryption Standard em modo Cipher Block Chaining — cifra de bloco simétrica padrão

EVP_BytesToKey

Função de derivação de chave da OpenSSL (compatível com CryptoJS), usa hash iterado a partir de senha + salt

PKCS7 padding

Padrão de preenchimento de bloco usado com cifras simétricas

Princípio de Kerckhoffs

Princípio de criptografia (1883) segundo o qual a segurança de um sistema deve depender apenas da chave, não da obscuridade do algoritmo

Information Disclosure

Categoria de vulnerabilidade onde um sistema revela informações que não deveriam ser acessíveis a um ator não autorizado

Responsible Disclosure

Prática de reportar vulnerabilidades ao fornecedor antes de divulgá-las publicamente, dando prazo para correção

Wayback CDX

API do Internet Archive que lista todas as URLs já capturadas para um domínio