Flock Camera Invadida: 1,6 Milhão de Imagens e a Lição de Segurança de 2026

Olá HaWkers, uma câmera da Flock Safety retirada de uma via pública revelou muito mais que placas. Em 16 de setembro de 2026, uma investigação conjunta da WIRED e da 404 Media relatou que o coletivo stegan0gram copiou quase todo o armazenamento do equipamento e recuperou vídeos, imagens, aplicativos e logs. Em apenas 21 dias, o dispositivo havia produzido 1,6 milhão de imagens de aproximadamente 50 mil veículos.

Mas o caso não foi uma invasão remota da nuvem: houve acesso físico ao hardware. Então, o que ele realmente prova sobre criptografia, privacidade e segurança de sistemas na borda? Neste artigo, vamos separar os fatos das conclusões apressadas e transformar a investigação em uma prática útil para qualquer equipe que instale câmeras, sensores, totens ou outros dispositivos fora do próprio escritório.

O que aconteceu com a Flock Camera

Segundo a investigação da WIRED, integrantes do stegan0gram removeram uma câmera automática de leitura de placas, desmontaram o conjunto e fizeram engenharia reversa do armazenamento e do software. O material foi compartilhado com a 404 Media e com a organização de transparência Distributed Denial of Secrets antes de ser analisado pelos jornalistas.

Os pesquisadores encontraram um sistema Android dividido em partições. Algumas áreas continuaram criptografadas e inacessíveis, inclusive parte do conteúdo mais sensível. Porém, uma partição chamada media continha uma chave que permitiu abrir outra área e visualizar milhares de vídeos e imagens. Essa nuance é essencial: não houve prova de que toda a plataforma da Flock foi aberta, mas a promessa de que o acesso físico não daria acesso às imagens deixou de parecer suficiente.

A câmera executava cerca de 20 aplicativos construídos pela Flock. Eles cuidavam de movimento, captura, classificação de objetos, envio de dados e atualizações remotas. Os arquivos também mostraram que o software detectava pessoas, veículos, placas e bicicletas. A análise não encontrou reconhecimento facial ativo, e a Flock continua afirmando que seu sistema de leitura de placas não usa essa tecnologia.

O incidente exige outra precisão. Remover ou adulterar equipamento instalado em via pública pode ser crime, e a empresa declarou que não recebeu o material por seu programa de divulgação de vulnerabilidades. Estudar o resultado jornalístico é legítimo; reproduzir a retirada de uma câmera não é uma recomendação técnica nem ética.

Como uma câmera produziu 1,6 milhão de imagens

Uma Flock Camera não precisa transmitir vídeo contínuo em alta resolução durante o dia inteiro. Ela pode detectar movimento localmente, registrar clipes curtos, fazer rajadas de fotos quando um veículo passa, classificar o conteúdo e enviar somente os eventos relevantes. Esse desenho reduz banda, mas concentra responsabilidade no equipamento instalado na rua.

Nos 21 dias recuperados, os logs indicavam cerca de 50.200 veículos e 1,6 milhão de imagens. A média simples fica perto de 32 imagens por veículo e 76 mil imagens por dia. Isso não significa que todo veículo sempre gere exatamente 32 arquivos: posição, velocidade, iluminação, repetição, erros e políticas de descarte mudam o resultado. O cálculo serve para revelar a escala.

const periodo = {
  dias: 21,
  veiculos: 50_200,
  imagens: 1_600_000,
}

const imagensPorVeiculo = periodo.imagens / periodo.veiculos
const imagensPorDia = periodo.imagens / periodo.dias

// As médias descrevem o conjunto; não são uma regra fixa da câmera.
console.log(`Imagens por veículo: ${imagensPorVeiculo.toFixed(1)}`)
console.log(`Imagens por dia: ${Math.round(imagensPorDia).toLocaleString('pt-BR')}`)

Os jornalistas também rodaram os modelos recuperados sobre 27.321 clipes MP4, cada um com um a dois segundos e resolução de 1.024 por 768 pixels. Pessoas apareceram em 11 clipes, todas em motocicletas. A posição da câmera, apontada para a pista, ajuda a explicar o número pequeno. Ainda assim, o código tinha uma classe explícita para pessoas e registrava a posição e a confiança de cada detecção.

O detector de placas também cometeu falsos positivos. Em alguns casos, recortou adesivos, molduras e até uma bandeira americana numa bolsa de motocicleta como se fossem placas. Isso mostra por que uma saída probabilística deve ser tratada como pista, não como verdade. A própria Flock diz que alertas precisam de confirmação humana.

Criptografia não resolve quando a chave viaja junto

Criptografar o disco é indispensável, mas não basta escrever “dados protegidos em repouso” numa apresentação. Um dispositivo autônomo precisa iniciar sem um operador digitando senha. Em algum ponto, ele recebe ou deriva uma chave. Se armazenamento, chave e processo de abertura estiverem todos no mesmo equipamento e puderem ser extraídos, a criptografia vira uma barreira de atraso, não uma fronteira absoluta.

O problema lembra guardar a chave do cofre em uma gaveta colada ao cofre. A fechadura continua real, porém o modelo de ameaça ignorou o atacante que leva o móvel inteiro. Para dispositivos na borda, a equipe deve assumir que alguém poderá tocar, abrir, desligar ou transportar o hardware.

Uma revisão simples pode transformar essa hipótese em requisitos verificáveis:

const controles = [
  { nome: 'boot verificado', presente: true, peso: 3 },
  { nome: 'chave em secure element', presente: false, peso: 5 },
  { nome: 'apagamento após violação física', presente: false, peso: 4 },
  { nome: 'rotação remota de credenciais', presente: true, peso: 3 },
  { nome: 'dados locais com vida curta', presente: true, peso: 5 },
]

const riscoResidual = controles
  .filter((controle) => !controle.presente)
  .reduce((total, controle) => total + controle.peso, 0)

// Pontuação interna: use-a para priorizar trabalho, não como certificação pública.
console.log({ riscoResidual, ausentes: controles.filter((c) => !c.presente) })

Na prática, um projeto robusto combina inicialização verificada, chave presa a um componente seguro, identidade única por dispositivo, rotação de credenciais, revogação rápida e retenção local mínima. Dados efêmeros reduzem o prêmio disponível para quem obtiver o hardware. E nenhuma chave do equipamento deveria abrir dados de outras unidades ou da nuvem.

Essa é uma versão física do problema de cadeia de suprimentos discutido no artigo sobre o zero-day do V8 em Chrome e Electron: a fronteira de confiança precisa incluir o runtime, as atualizações, as credenciais e o lugar onde o software realmente executa.

Os logs revelaram falhas operacionais além da privacidade

O armazenamento não apenas continha dados; ele mostrava a saúde do produto. A investigação encontrou mais de 27 mil mensagens “no space left on device” enquanto a câmera tentava salvar imagens em resolução completa, além de dezenas de milhares de erros relacionados, travamentos e reinicializações. Um processo verificava a atividade aproximadamente a cada dois minutos e gravou mais de 12 mil mensagens de funcionamento.

Logs assim são úteis durante desenvolvimento, mas custam espaço, criam ruído e podem revelar detalhes internos. Em um equipamento remoto, o sistema precisa limitar arquivos, exportar métricas agregadas e reagir antes de atingir capacidade crítica. Reiniciar após o disco lotar pode restaurar o serviço por pouco tempo sem resolver a causa.

Este analisador pequeno ilustra como uma equipe poderia resumir eventos sem guardar indefinidamente todas as linhas brutas:

function resumirEventos(linhas) {
  const resumo = { discoCheio: 0, reinicios: 0, saudavel: 0 }

  for (const linha of linhas) {
    if (linha.includes('no space left on device')) resumo.discoCheio++
    if (linha.includes('reboot was requested')) resumo.reinicios++
    if (linha.includes("who's a good boy")) resumo.saudavel++
  }

  // Em produção, envie contadores e retenha só uma amostra necessária para diagnóstico.
  return resumo
}

console.log(resumirEventos([
  'no space left on device',
  "who's a good boy",
  'a reboot was requested',
]))

O alerta importante não é somente discoCheio > 0. É a combinação de crescimento da fila, espaço restante, taxa de falhas e reinícios. Uma política pode reduzir resolução temporariamente, interromper novas capturas não essenciais, confirmar o envio antes do descarte e abrir um incidente. O comportamento precisa ser definido antes que a unidade fique sem espaço em campo.

O conflito entre o discurso e o que o software detecta

No seu Trust Center, a Flock afirma que o produto de leitura de placas captura imagens de placas, características do veículo, horário e localização, e que não coleta informação do motorista nem dados de reconhecimento facial. A análise recuperada não mostrou reconhecimento facial. Entretanto, mostrou uma categoria computacional de pessoa e a capacidade de registrar onde uma pessoa apareceu na imagem.

Detectar uma pessoa não é o mesmo que identificá-la. Essa diferença técnica importa, mas não encerra a discussão de privacidade. Um sistema pode acompanhar roupas, trajetos, associações entre veículos e padrões de movimento sem saber o nome de alguém. A WIRED já havia reconstruído ferramentas de busca da Flock que permitem procurar pessoas por descrição em alguns produtos de vídeo, embora a empresa diga que essa busca não funciona por atributos pessoais nas câmeras de placas.

Por isso, documentos públicos devem descrever capacidades, não apenas finalidades. “Não usamos para vigiar pessoas” é uma política; “o modelo possui uma classe person” é uma propriedade do software. Boas práticas conectam as duas com controles: quem pode pesquisar, por qual motivo, em qual produto, por quanto tempo e com qual auditoria.

Em agosto de 2026, a Flock anunciou mudanças: recomendação e padrão de retenção reduzidos de 30 para 7 dias para novas configurações, códigos de caso, detecção de uso indevido, autenticação multifator e uma revisão independente da Bishop Fox. Clientes existentes podem manter períodos definidos localmente. A Associated Press informou que milhares de órgãos em 49 estados usam ou compartilham dados da rede, o que torna configuração e governança tão importantes quanto o algoritmo.

Como testar um dispositivo de borda sem tocar no hardware de terceiros

Você não precisa desmontar equipamento alheio para aplicar a lição. Comece num laboratório autorizado com uma unidade de teste, dados sintéticos e um roteiro de perda física. O objetivo é responder o que acontece quando o dispositivo desaparece, não provar habilidade de invasão.

Uma matriz mínima deve cobrir desligamento inesperado, remoção do armazenamento, cópia bit a bit, restauração de firmware antigo, ausência de rede e credencial revogada. Cada cenário precisa ter resultado esperado, evidência e responsável. “Não conseguimos ler o volume” é melhor que “usamos AES-256”, porque testa o efeito, não o rótulo.

const cenarios = [
  { evento: 'armazenamento removido', esperado: 'dados ilegíveis', passou: true },
  { evento: 'dispositivo roubado', esperado: 'credencial revogada em 15 min', passou: false },
  { evento: 'firmware antigo', esperado: 'boot bloqueado', passou: true },
  { evento: 'rede ausente', esperado: 'retenção local limitada a 24 h', passou: true },
]

const falhas = cenarios.filter((cenario) => !cenario.passou)

if (falhas.length) {
  process.exitCode = 1
  console.error('Gate de segurança reprovado:', falhas)
} else {
  console.log('Todos os cenários físicos passaram')
}

O teste deve confirmar também que uma unidade comprometida não permite se passar por outra. Certificados únicos, escopo pequeno e revogação individual evitam que um incidente local se torne acesso sistêmico. Atualizações precisam de assinatura, proteção contra downgrade e inventário de versão. A telemetria deve avisar sobre abertura, mudança de orientação, reinícios incomuns e silêncio prolongado.

Finalmente, simule o prazo de resposta. Quem recebe o alerta? Quem pode revogar a identidade? Como preservar evidências sem conservar dados pessoais desnecessários? Quanto tempo leva para informar o cliente? Segurança operacional aparece nessas respostas, não apenas numa lista de algoritmos.

Checklist para comprar câmeras, sensores e totens conectados

Equipes públicas e privadas deveriam pedir evidências antes de instalar milhares de unidades. Primeiro, qual é o modelo de ameaça física? A resposta precisa explicar proteção de chave, boot, debug, portas expostas e destino dos dados quando a conectividade cai. “O gabinete fica alto” não é controle criptográfico.

Segundo, qual é a retenção real em cada camada? Nuvem, cache local, logs, backups, evidências preservadas e ambientes de suporte podem ter prazos diferentes. A política de 7 dias anunciada pela Flock é um passo mensurável, mas clientes antigos podem manter outra configuração e casos ativos podem preservar registros. O contrato deve dizer quem autoriza exceções e quem consegue auditá-las.

Terceiro, exija transparência sobre modelos de visão. Quais classes são detectadas? Quais atributos são pesquisáveis? Quais falsos positivos foram medidos? Um modelo treinado para placas pode recortar adesivos; um modelo que detecta pessoas pode ter usos futuros além do fluxo atual. Atualizações que ampliem categorias deveriam acionar nova avaliação de privacidade.

Quarto, verifique o processo de vulnerabilidades: canal público, prazo de resposta, proteção para pesquisa de boa-fé, atualização assinada e histórico de correções. A divulgação coordenada não elimina conflitos, mas cria uma alternativa responsável à publicação surpresa.

Por último, trate compartilhamento como produto, não como caixa marcada. Acesso entre milhares de órgãos aumenta o valor investigativo e o impacto de abuso. Menor privilégio, MFA, código de caso, justificativa, alerta de comportamento anômalo e revisão humana precisam estar ativos por padrão.

Perspectivas: a segurança começa quando o dispositivo sai do prédio

O caso da Flock Camera não prova que qualquer pessoa na internet consegue assistir a todas as câmeras. Também não pode ser reduzido a “alguém roubou o equipamento, então não conta”. Dispositivos instalados em postes e vias públicas vivem num ambiente hostil por definição. O acesso físico faz parte do modelo de ameaça.

O achado mais útil é a distância entre criptografia declarada e resistência comprovada. Parte sensível permaneceu inacessível, o que mostra que controles funcionaram. Ao mesmo tempo, uma chave local abriu milhares de registros, os logs revelaram falhas de armazenamento e o software mostrou capacidades mais amplas que a imagem pública de um simples leitor de placas.

Para desenvolvedores, a resposta não é abandonar processamento na borda. É projetar como se a caixa pudesse sumir amanhã: reduzir dados, separar chaves, limitar credenciais, registrar o necessário, testar perda física e dar ao operador meios rápidos de revogação. Privacidade não depende de um controle heroico, mas de camadas que continuam úteis quando uma delas falha.

Em 2026, a pergunta madura não é “o disco está criptografado?”. É: “quais dados ainda ficam expostos quando o atacante possui o dispositivo, quanto tempo eles vivem e até onde uma identidade comprometida consegue chegar?”. Se sua equipe consegue responder com um teste repetível, ela já aprendeu a principal lição desta câmera.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Ai?

Este artigo cobriu a invasão física de uma Flock Camera e a segurança de dispositivos na borda, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue La

👉 Seguir @jeffbruchado no X

💡 Conteudo diario sobre desenvolvimento, carreira e as ferramentas que eu realmente uso