Porque a Auditoria de Rede Importa

Dispositivos IoT são essencialmente pequenos computadores que transmitem dados continuamente. A questão não é "se" comunicam, mas "com quem" e "o quê" enviam. Políticas de privacidade podem ser vagas ou enganadoras — a auditoria de rede revela a verdade objetiva.

A nossa abordagem forense baseia-se em três princípios: captura passiva (observamos sem modificar o dispositivo), análise quantitativa (medimos bytes, não impressões), e reprodutibilidade (qualquer pessoa com as ferramentas certas pode repetir os testes).

Passo 1: DNS Sniff — Descobrir Quem Está a Ouvir

Objetivo: Identificar todos os servidores que o dispositivo tenta contactar, capturando consultas DNS (Domain Name System).

Duração: 5-10 minutos durante configuração inicial e primeiro uso.

Como funciona: Criamos um ponto de acesso Wi-Fi isolado no nosso Mac (Internet Sharing). O dispositivo conecta-se a esta rede. Usando `tcpdump`, capturamos todo o tráfego na porta 53 (DNS). Cada vez que o dispositivo quer contactar um servidor, precisa primeiro resolver o nome de domínio — e nós registamos isso.

O que procuramos:

  • Domínios do fabricante (esperado e benigno)
  • Serviços de analytics comportamental (Mixpanel, Amplitude, Firebase)
  • Servidores chineses (.cn, .aliyuncs.com, .qq.com, .baidu.com)
  • Domínios desconhecidos sem documentação clara

Bandeiras vermelhas: Mais de 3 serviços de analytics em paralelo, domínios .cn não mencionados na política de privacidade, servidores de tracking de terceiros.

Passo 2: Traffic Watch — Monitorizar Comportamento Real

Objetivo: Quantificar exatamente quanto dados o dispositivo transmite em diferentes cenários: configuração, uso ativo, e (crucialmente) modo inativo.

Duração: 1-8 horas, dependendo do dispositivo. Smartwatches testamos durante 6 horas. Óculos inteligentes testamos overnight (8 horas).

Como funciona: Capturamos todos os pacotes IP (não apenas DNS) usando `tcpdump` no interface de bridge. Registamos timestamps, endereços de destino, e tamanhos de pacotes. Depois analisamos:

  • Volume total upstream vs downstream
  • Frequência de transmissões (constante vs event-driven)
  • Correlação entre ações do utilizador e uploads

O teste crítico: Modo Inativo

Deixamos o dispositivo ligado mas sem uso durante 4-8 horas. Um dispositivo respeitador de privacidade deveria transmitir apenas heartbeat pings (< 500 KB em 6 horas). Se vemos uploads constantes de megabytes, algo está errado.

Exemplo real: HeyCyan AI Glasses: 340 KB em 6h inativo (excelente). AI Glasses 8MP: 18.7 MB em 6h inativo (falha grave).

Passo 3: Deep Inspect — Tentar Ver Dentro do Tráfego

Objetivo: Desencriptar tráfego HTTPS para ver o conteúdo exato das comunicações.

Limitações: A maioria dos dispositivos IoT modernos usa certificate pinning — rejeita certificados que não sejam do fabricante. Isto é bom para segurança, mas impede inspeção profunda. Conseguimos sucesso em apenas ~20% dos dispositivos testados.

Como funciona: Usamos `mitmproxy` para criar um proxy HTTPS com certificado personalizado. Instalamos o certificado root no dispositivo (quando possível). O proxy intercepta e desencripta o tráfego, permitindo-nos ver URLs completos, headers HTTP, e payloads JSON.

Quando é útil: Quando o Passo 2 revela tráfego suspeito mas não conseguimos determinar o conteúdo. Por exemplo, se vemos 5 MB uploadados mas o dispositivo não tem fotos novas, queremos saber o quê está a ser enviado.

Ferramentas que Usamos

  • tcpdump: Ferramenta de linha de comando para captura de pacotes (built-in no macOS)
  • Wireshark: Interface visual para analisar capturas PCAP
  • mitmproxy: Proxy HTTPS para inspeção profunda (opcional)
  • Python scripts personalizados: Para processar logs DNS, calcular estatísticas, classificar domínios
  • Listas de referência: Base de dados de domínios conhecidos (benignos, analytics, suspeitos)

Como Calcular o Risco (0-100)

Usamos um sistema de pontuação objetiva baseado em múltiplos fatores:

Tráfego Inativo: +0-30 pontos

  • < 500 KB/6h: 0 pontos (excelente)
  • 500 KB-2 MB: +10 pontos (aceitável para smartwatches)
  • 2-10 MB: +20 pontos (preocupante)
  • > 10 MB: +30 pontos (falha automática)

Domínios Suspeitos: +10-40 pontos

  • Cada serviço de analytics: +5 pontos
  • Cada domínio chinês (.cn, Alibaba, Tencent): +10 pontos
  • Domínios não divulgados na política: +15 pontos

Comportamento da App: +0-20 pontos

  • Permissões invasivas desnecessárias: +10 pontos
  • Requer conta obrigatória: +5 pontos
  • Sem opção de desativar telemetria: +5 pontos

Política de Privacidade: +0-10 pontos

  • Não disponível em PT: +5 pontos
  • Vaga ou contraditória: +5 pontos

Classificação Final:

  • 0-25: Risco Baixo (recomendado)
  • 26-50: Risco Médio (aprovado com ressalvas)
  • 51-75: Risco Alto (não recomendado)
  • > 75: Risco Crítico (evitar)

Faça Você Mesmo: Auditoria Caseira Básica

Não precisa das nossas ferramentas profissionais para fazer verificações básicas. Aqui está uma auditoria simplificada que qualquer utilizador técnico pode fazer:

1. Verifique Permissões da App

iOS: Definições → Privacidade → [tipo de permissão]
Android: Definições → Apps → [nome da app] → Permissões

Pergunte-se: esta permissão é necessária para a funcionalidade principal? Óculos inteligentes não precisam de acesso aos seus Contactos.

2. Leia a Política de Privacidade (5 minutos)

Procure especificamente:

  • Onde os dados são armazenados (EU vs China vs EUA)?
  • Partilham dados com terceiros?
  • Pode eliminar os seus dados?
  • Mencionam analytics ou telemetria?

3. Teste de "Modo Avião"

Ative modo avião no telefone. O dispositivo IoT continua a funcionar? Se sim, processa localmente. Se deixa de funcionar completamente, depende de cloud.

4. Monitorize Uso de Dados

iOS: Definições → Dados Móveis → [app]
Android: Definições → Rede → Uso de dados

Se a app companion usa gigabytes de dados sem você saber porquê, investigue.

Limitações da Nossa Metodologia

Transparência total: há coisas que não conseguimos detetar:

  • Conteúdo encriptado: Se o Passo 3 falha, não sabemos o quê está dentro dos pacotes.
  • Comportamento futuro: Um dispositivo benigno hoje pode mudar com firmware updates.
  • Processamento server-side: Podemos ver que dados saem, mas não o que acontece depois nos servidores.
  • Testes limitados: Testamos 24-48h por dispositivo. Comportamentos sazonais ou triggers específicos podem escapar.

Por isto, os nossos veredictos são baseados no comportamento observado, não em garantias absolutas. Complementamos sempre com análise da política de privacidade e contexto regulatório (GDPR).