Ofuscação Dinâmica de Endpoints via Criptografia Simétrica: Estudo de Caso OneBlinc

Contexto

Em 2025, a OneBlinc — uma fintech mobile-first de crescimento acelerado — enfrentava um problema crítico de segurança: agentes maliciosos estavam mapeando os endpoints de sua API Gateway e, combinando esse mapa com credenciais vazadas em grupos do dark web, conduzindo ataques de fuzzing que exploravam vulnerabilidades não corrigidas.

A Imara Trust foi contratada para projetar uma solução de mitigação rápida. A resposta veio em dois componentes complementares que formam uma arquitetura única: ofuscação dinâmica de endpoints via criptografia simétrica, que torna os endpoints completamente opacos para qualquer ator externo, e um mecanismo de identificação semântica do tráfego via X-Crypto-Alias, que preserva a observabilidade operacional mesmo com URLs ofuscadas. O resultado foi a eliminação total dos ataques dentro de 30 dias.

O Problema

A superfície de ataque da OneBlinc era ampla por dois motivos independentes.

Primeiro, os endpoints da API eram estáticos e previsíveis. Uma vez que um atacante mapeasse /v1/loan/apply, /v1/payment/process ou /v1/user/validate, ele podia construir payloads direcionados e testar variações de entrada indefinidamente. Ferramentas como Burp Suite e nuclei fazem exatamente isso de forma automatizada.

Segundo, credenciais de usuários legítimos estavam disponíveis no dark web. Isso significava que os atacantes não precisavam contornar a autenticação: podiam usar tokens válidos para acessar endpoints documentados e testar variações de payload a partir de uma sessão autenticada.

A combinação de endpoints previsíveis e credenciais vazadas criava um vetor de ataque difícil de detectar via WAF convencional, porque o tráfego malicioso tinha aparência legítima.

Arquitetura da Solução

A solução opera em três camadas integradas, onde a ofuscação e a identificação semântica são projetadas juntas desde o início.

Camada 1 — Nonce de build e proteção do app mobile

No momento do build do app, um nonce único (UUID v4) é gerado e armazenado de forma protegida no bundle pelo AppDome ou DexProtector (Licel). Essas ferramentas aplicam ofuscação de bytecode, detecção de emulador, anti-tamper e root/jailbreak detection. O nonce não é visível no tráfego de rede e não pode ser extraído por engenharia reversa sem violar as proteções do runtime.

O servidor também valida sinais de integridade do dispositivo no momento da emissão da chave: attestation do SafetyNet/Play Integrity (Android) ou DeviceCheck/AppAttest (iOS). Dispositivos comprometidos não recebem chave.

Camada 2 — Distribuição de chave simétrica

Quando o app inicia, ele chama o único endpoint permanente e público do sistema: /resolve/key. Esse endpoint valida o JWT de autenticação, verifica o build nonce e emite uma chave simétrica com TTL curto (tipicamente 15 minutos). A resposta também inclui o mapa de aliases válidos para a sessão, vinculando identidade semântica à chave criptográfica.

def resolve_key(request):
    verify_jwt(request.headers["Authorization"])
    verify_build_nonce(request.headers["X-Build-Nonce"])
    key = generate_symmetric_key(ttl=900)
    aliases = get_session_aliases(request.user)
    return {"key": key, "aliases": aliases, "expires_at": utcnow() + 900}

Camada 3 — Ofuscação do endpoint e identificação semântica

Com a chave em mãos, o app calcula o endpoint real em runtime usando dois modelos possíveis conforme o nível de segurança desejado. Em paralelo, toda requisição carrega o header X-Crypto-Alias com o identificador semântico da operação.

No modelo HMAC, o endpoint é derivado como hash do path real concatenado com um timestamp de janela fixa. É determinístico e eficiente, mas o endpoint calculado é o mesmo para todos os clientes dentro da mesma janela de tempo.

No modelo AES-GCM, o path é cifrado com a chave distribuída e um IV aleatório. O resultado é enviado como path da requisição. Esse modelo gera um endpoint diferente a cada chamada, mesmo para o mesmo path real.

// Cliente Flutter — requisição com endpoint ofuscado e alias semântico
final iv = generateRandomIV();
final encryptedPath = aesGcmEncrypt(realPath, sessionKey, iv);
final obfuscatedPath = base64url(iv + encryptedPath);

await http.post(
  Uri.parse('$baseUrl/$obfuscatedPath'),
  headers: {
    'Authorization': 'Bearer $token',
    'X-Crypto-Alias': 'loan.apply',
  },
  body: payload,
);

No servidor, o middleware de ofuscação decifra o path e o middleware de alias valida a correspondência entre alias e operação real, rejeitando requisições onde divergem.

class ObfuscationMiddleware:
    def __call__(self, request):
        raw = base64url_decode(request.path.lstrip('/'))
        iv, ciphertext = raw[:12], raw[12:]
        request.path = aes_gcm_decrypt(ciphertext, session_key, iv)
        return self.get_response(request)

ALIAS_MAP = {
    'loan.apply': '/v1/loan/apply',
    'payment.process': '/v1/payment/process',
    'user.validate': '/v1/user/validate',
}

class AliasRoutingMiddleware:
    def __call__(self, request):
        alias = request.headers.get('X-Crypto-Alias')
        if ALIAS_MAP.get(alias) != request.path:
            return HttpResponse(status=400)
        return self.get_response(request)

Por que o X-Crypto-Alias é parte da solução de segurança

A ofuscação resolve o problema de exposição dos endpoints, mas cria um segundo problema: logs do CloudWatch, regras do WAF e dashboards do API Gateway passam a registrar apenas hashes ou ciphertext como path da requisição. Fica impossível distinguir um POST /v1/loan/apply de um POST /v1/payment/process nos logs, o que inviabiliza alertas de anomalia, rate limiting granular e análise de incidentes.

Uma solução ingênua seria descriptografar os paths em um pipeline de log intermediário — mas isso aumenta a complexidade operacional, cria um ponto de falha e expõe os endpoints reais em outro contexto.

O X-Crypto-Alias resolve isso de forma elegante: o cliente declara semanticamente o que está fazendo sem revelar o endpoint real. O servidor valida que a declaração é verdadeira (alias ↔ path decifrado). Logs e sistemas de observabilidade usam o alias diretamente.

Tipos de Alias

O sistema suporta três modelos de alias, escolhidos conforme a necessidade operacional de cada endpoint.

No modelo 1-para-1, um alias fixo corresponde sempre ao mesmo endpoint real. Adequado para operações de alto valor com volume previsível, como /v1/loan/apply.

No modelo 1-para-N, um alias corresponde a um grupo de endpoints relacionados. Útil quando a granularidade exata do endpoint não é necessária nos logs, como agrupar todas as operações de leitura de perfil sob user.read.

No modelo dinâmico, o alias é gerado pelo servidor no momento da distribuição da chave e rotacionado junto com ela. Não há alias fixo que um atacante possa tentar reproduzir.

Observabilidade com o Stack Completo

Com X-Crypto-Alias nos logs, toda a stack de observabilidade funciona normalmente sem descriptografar nada.

Template de log do API Gateway:

{
  "requestId": "$context.requestId",
  "alias": "$context.requestOverride.header.x-crypto-alias",
  "status": "$context.status",
  "ip": "$context.identity.sourceIp"
}

Query no CloudWatch Logs Insights para latência por operação:

fields @timestamp, httpMethod, xCryptoAlias, status, @duration
| filter xCryptoAlias = "loan.apply"
| stats avg(@duration) by bin(5m)

Regra de rate limiting no WAF, escopo por alias:

{
  "Name": "RateLimit-LoanApply",
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "HEADER",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "FieldToMatch": {"SingleHeader": {"Name": "x-crypto-alias"}},
          "SearchString": "loan.apply"
        }
      }
    }
  }
}

Resultados

Após 30 dias da implementação:

• Ataques de fuzzing: eliminados em 100%. Sem o endpoint real, ferramentas automatizadas não conseguem construir payloads válidos.
• Ataques com credenciais vazadas: ineficazes. Credenciais válidas não são suficientes sem o endpoint calculado em runtime.
• Overhead de latência: inferior a 2ms por requisição para HMAC; inferior a 4ms para AES-GCM.
• Observabilidade: mantida integralmente. Logs, dashboards e regras WAF funcionam com aliases sem necessidade de decifragem nos sistemas de monitoramento.

A arquitetura demonstrou que segurança e observabilidade não são objetivos conflitantes: projetados juntos desde o início, o componente criptográfico e o identificador semântico se reforçam mutuamente.