Caméra Flock piratée : 1,6 million d’images et la leçon de sécurité de 2026

Salut HaWkers, une caméra de Flock Safety retirée de la voie publique a révélé bien plus que des plaques d’immatriculation. Le 16 septembre 2026, une enquête conjointe de WIRED et de 404 Media a rapporté que le collectif stegan0gram avait copié la quasi-totalité du stockage de l’appareil et récupéré des vidéos, des images, des applications et des journaux. En seulement 21 jours, l’équipement avait produit 1,6 million d’images d’environ 50 000 véhicules.

Mais il ne s’agissait pas d’une intrusion à distance dans le cloud : les chercheurs ont eu un accès physique au matériel. Alors, que prouve réellement cette affaire sur le chiffrement, la confidentialité et la sécurité des systèmes en périphérie ? Dans cet article, nous allons distinguer les faits des conclusions hâtives et transformer l’enquête en une pratique utile pour toute équipe qui installe des caméras, des capteurs, des bornes ou d’autres appareils hors de ses propres locaux.

Ce qui est arrivé à la caméra Flock

Selon l’enquête de WIRED, des membres de stegan0gram ont retiré une caméra automatique de lecture de plaques, démonté l’ensemble et procédé à la rétro-ingénierie du stockage et du logiciel. Le matériel a été partagé avec 404 Media et avec l’organisation de transparence Distributed Denial of Secrets avant d’être analysé par les journalistes.

Les chercheurs ont découvert un système Android divisé en partitions. Certaines zones sont restées chiffrées et inaccessibles, notamment une partie du contenu le plus sensible. Cependant, une partition appelée media contenait une clé qui a permis d’ouvrir une autre zone et de consulter des milliers de vidéos et d’images. Cette nuance est essentielle : rien ne prouve que toute la plateforme de Flock ait été ouverte, mais la promesse selon laquelle l’accès physique ne donnerait pas accès aux images ne paraît plus suffisante.

La caméra exécutait une vingtaine d’applications développées par Flock. Elles géraient le mouvement, la capture, la classification des objets, l’envoi des données et les mises à jour à distance. Les fichiers montraient également que le logiciel détectait les personnes, les véhicules, les plaques et les vélos. L’analyse n’a trouvé aucune reconnaissance faciale active, et Flock continue d’affirmer que son système de lecture de plaques n’utilise pas cette technologie.

L’incident exige une autre précision. Retirer ou altérer un équipement installé sur la voie publique peut constituer une infraction, et l’entreprise a déclaré ne pas avoir reçu le matériel par l’intermédiaire de son programme de divulgation des vulnérabilités. Étudier le résultat journalistique est légitime ; reproduire le retrait d’une caméra n’est ni une recommandation technique ni une recommandation éthique.

Comment une caméra a produit 1,6 million d’images

Une caméra Flock n’a pas besoin de transmettre en continu une vidéo haute résolution toute la journée. Elle peut détecter les mouvements localement, enregistrer de courts extraits, prendre des rafales de photos au passage d’un véhicule, classer le contenu et n’envoyer que les événements pertinents. Cette conception réduit la bande passante, mais concentre la responsabilité dans l’équipement installé dans la rue.

Sur les 21 jours récupérés, les journaux indiquaient environ 50 200 véhicules et 1,6 million d’images. La moyenne simple est proche de 32 images par véhicule et de 76 000 images par jour. Cela ne signifie pas que chaque véhicule génère toujours exactement 32 fichiers : la position, la vitesse, l’éclairage, les répétitions, les erreurs et les politiques de suppression modifient le résultat. Le calcul sert à révéler l’échelle.

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

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

// Les moyennes décrivent l’ensemble ; elles ne constituent pas une règle fixe de la caméra.
console.log(`Imagens por veículo: ${imagensPorVeiculo.toFixed(1)}`)
console.log(`Imagens por dia: ${Math.round(imagensPorDia).toLocaleString('pt-BR')}`)

Les journalistes ont également exécuté les modèles récupérés sur 27 321 extraits MP4, chacun d’une à deux secondes et d’une résolution de 1 024 par 768 pixels. Des personnes apparaissaient dans 11 extraits, toutes à moto. La position de la caméra, orientée vers la chaussée, contribue à expliquer ce faible nombre. Le code comportait néanmoins une classe explicite pour les personnes et enregistrait la position et le niveau de confiance de chaque détection.

Le détecteur de plaques a également produit des faux positifs. Dans certains cas, il a recadré des autocollants, des cadres et même un drapeau américain sur une sacoche de moto comme s’il s’agissait de plaques. Cela montre pourquoi une sortie probabiliste doit être considérée comme un indice, et non comme une vérité. Flock elle-même affirme que les alertes doivent faire l’objet d’une confirmation humaine.

Le chiffrement ne suffit pas lorsque la clé voyage avec les données

Chiffrer le disque est indispensable, mais il ne suffit pas d’écrire « données protégées au repos » dans une présentation. Un appareil autonome doit démarrer sans qu’un opérateur saisisse un mot de passe. À un moment donné, il reçoit ou dérive une clé. Si le stockage, la clé et le processus d’ouverture se trouvent tous dans le même équipement et peuvent être extraits, le chiffrement devient un obstacle qui retarde l’attaquant, et non une frontière absolue.

Le problème revient à ranger la clé d’un coffre-fort dans un tiroir fixé au coffre. La serrure reste bien réelle, mais le modèle de menace a ignoré l’attaquant qui emporte tout le meuble. Pour les appareils en périphérie, l’équipe doit partir du principe que quelqu’un pourra toucher, ouvrir, éteindre ou transporter le matériel.

Un examen simple permet de transformer cette hypothèse en exigences vérifiables :

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)

// Score interne : utilisez-le pour prioriser le travail, et non comme certification publique.
console.log({ riscoResidual, ausentes: controles.filter((c) => !c.presente) })

En pratique, une conception robuste associe démarrage vérifié, clé liée à un composant sécurisé, identité unique pour chaque appareil, rotation des identifiants, révocation rapide et rétention locale minimale. Les données éphémères réduisent la récompense accessible à celui qui s’empare du matériel. Et aucune clé de l’équipement ne devrait ouvrir les données d’autres unités ou du cloud.

Il s’agit d’une version physique du problème de chaîne d’approvisionnement abordé dans l’article sur le zero-day de V8 dans Chrome et Electron : la frontière de confiance doit inclure le runtime, les mises à jour, les identifiants et l’endroit où le logiciel s’exécute réellement.

Les journaux ont révélé des défaillances opérationnelles au-delà de la confidentialité

Le stockage ne contenait pas seulement des données ; il révélait l’état de santé du produit. L’enquête a découvert plus de 27 000 messages « no space left on device » pendant que la caméra tentait d’enregistrer des images en pleine résolution, ainsi que des dizaines de milliers d’erreurs associées, de plantages et de redémarrages. Un processus vérifiait l’activité environ toutes les deux minutes et avait enregistré plus de 12 000 messages de fonctionnement.

De tels journaux sont utiles pendant le développement, mais ils occupent de l’espace, créent du bruit et peuvent révéler des détails internes. Dans un équipement distant, le système doit limiter la taille des fichiers, exporter des métriques agrégées et réagir avant d’atteindre une capacité critique. Redémarrer après saturation du disque peut rétablir brièvement le service sans résoudre la cause.

Ce petit analyseur illustre comment une équipe pourrait résumer les événements sans conserver indéfiniment toutes les lignes brutes :

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++
  }

  // En production, envoyez des compteurs et ne conservez que l’échantillon nécessaire au diagnostic.
  return resumo
}

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

L’alerte importante n’est pas seulement discoCheio > 0. C’est la combinaison de l’augmentation de la file d’attente, de l’espace restant, du taux d’échec et des redémarrages. Une politique peut réduire temporairement la résolution, interrompre les nouvelles captures non essentielles, confirmer l’envoi avant la suppression et ouvrir un incident. Le comportement doit être défini avant que l’unité ne manque d’espace sur le terrain.

Le conflit entre le discours et ce que le logiciel détecte

Dans son Trust Center, Flock affirme que le produit de lecture de plaques capture des images de plaques, les caractéristiques du véhicule, l’heure et le lieu, et qu’il ne collecte ni informations sur le conducteur ni données de reconnaissance faciale. L’analyse des éléments récupérés n’a montré aucune reconnaissance faciale. Elle a toutefois révélé une catégorie informatique « personne » et la capacité d’enregistrer l’endroit où une personne apparaît dans l’image.

Détecter une personne ne revient pas à l’identifier. Cette différence technique est importante, mais elle ne met pas fin au débat sur la confidentialité. Un système peut suivre des vêtements, des trajets, des associations entre véhicules et des habitudes de déplacement sans connaître le nom d’une personne. WIRED avait déjà reconstitué des outils de recherche de Flock permettant, dans certains produits vidéo, de rechercher des personnes à partir d’une description, même si l’entreprise affirme que cette recherche ne fonctionne pas à partir d’attributs personnels dans les caméras de lecture de plaques.

C’est pourquoi les documents publics doivent décrire les capacités, et pas seulement les finalités. « Nous ne l’utilisons pas pour surveiller les personnes » est une politique ; « le modèle possède une classe person » est une propriété du logiciel. Les bonnes pratiques relient les deux par des contrôles : qui peut effectuer une recherche, pour quelle raison, dans quel produit, pendant combien de temps et avec quel audit.

En août 2026, Flock a annoncé des changements : une recommandation et une durée de rétention par défaut ramenées de 30 à 7 jours pour les nouvelles configurations, des codes de dossier, la détection des usages abusifs, l’authentification multifacteur et un examen indépendant de Bishop Fox. Les clients existants peuvent conserver des durées définies localement. L’Associated Press a rapporté que des milliers d’organismes dans 49 États utilisent ou partagent des données du réseau, ce qui rend la configuration et la gouvernance aussi importantes que l’algorithme.

Comment tester un appareil en périphérie sans toucher au matériel d’un tiers

Vous n’avez pas besoin de démonter l’équipement d’autrui pour appliquer cette leçon. Commencez dans un laboratoire autorisé avec une unité de test, des données synthétiques et un scénario de perte physique. L’objectif est de déterminer ce qui se passe lorsque l’appareil disparaît, et non de démontrer des compétences d’intrusion.

Une matrice minimale doit couvrir l’arrêt inattendu, le retrait du stockage, la copie bit à bit, la restauration d’un ancien firmware, l’absence de réseau et la révocation des identifiants. Chaque scénario doit avoir un résultat attendu, une preuve et un responsable. « Nous ne pouvons pas lire le volume » est préférable à « nous utilisons AES-256 », car cette formulation teste l’effet plutôt que l’étiquette.

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')
}

Le test doit également confirmer qu’une unité compromise ne peut pas se faire passer pour une autre. Des certificats uniques, un périmètre restreint et une révocation individuelle empêchent qu’un incident local se transforme en accès systémique. Les mises à jour nécessitent une signature, une protection contre le retour à une ancienne version et un inventaire des versions. La télémétrie doit signaler l’ouverture, le changement d’orientation, les redémarrages inhabituels et le silence prolongé.

Enfin, simulez le délai de réponse. Qui reçoit l’alerte ? Qui peut révoquer l’identité ? Comment préserver les preuves sans conserver de données personnelles inutiles ? Combien de temps faut-il pour informer le client ? La sécurité opérationnelle se manifeste dans ces réponses, pas seulement dans une liste d’algorithmes.

Liste de contrôle pour acheter des caméras, des capteurs et des bornes connectées

Les équipes publiques et privées devraient exiger des preuves avant d’installer des milliers d’unités. Premièrement, quel est le modèle de menace physique ? La réponse doit expliquer la protection de la clé, le démarrage, le débogage, les ports exposés et le sort des données lorsque la connexion est interrompue. « Le boîtier est placé en hauteur » n’est pas un contrôle cryptographique.

Deuxièmement, quelle est la durée de rétention réelle dans chaque couche ? Le cloud, le cache local, les journaux, les sauvegardes, les preuves préservées et les environnements d’assistance peuvent avoir des durées différentes. La politique de 7 jours annoncée par Flock constitue une mesure quantifiable, mais les anciens clients peuvent conserver une autre configuration et les dossiers actifs peuvent préserver des enregistrements. Le contrat doit indiquer qui autorise les exceptions et qui peut les auditer.

Troisièmement, exigez de la transparence sur les modèles de vision. Quelles classes sont détectées ? Quels attributs peuvent faire l’objet d’une recherche ? Quels faux positifs ont été mesurés ? Un modèle entraîné pour les plaques peut recadrer des autocollants ; un modèle qui détecte les personnes peut avoir des usages futurs au-delà du flux actuel. Les mises à jour qui élargissent les catégories devraient déclencher une nouvelle évaluation de la confidentialité.

Quatrièmement, vérifiez le processus de traitement des vulnérabilités : canal public, délai de réponse, protection de la recherche menée de bonne foi, mise à jour signée et historique des correctifs. La divulgation coordonnée n’élimine pas les conflits, mais elle offre une solution responsable face à une publication surprise.

Enfin, considérez le partage comme un produit, et non comme une case à cocher. L’accès entre des milliers d’organismes augmente la valeur pour les enquêtes et l’impact des abus. Le moindre privilège, la MFA, le code de dossier, la justification, l’alerte en cas de comportement anormal et l’examen humain doivent être activés par défaut.

Perspectives : la sécurité commence lorsque l’appareil quitte le bâtiment

L’affaire de la caméra Flock ne prouve pas que n’importe qui sur Internet peut regarder toutes les caméras. Elle ne peut pas non plus être réduite à « quelqu’un a volé l’équipement, donc cela ne compte pas ». Les appareils installés sur des poteaux et sur la voie publique vivent par définition dans un environnement hostile. L’accès physique fait partie du modèle de menace.

La conclusion la plus utile est l’écart entre le chiffrement annoncé et la résistance démontrée. Une partie sensible est restée inaccessible, ce qui montre que certains contrôles ont fonctionné. Dans le même temps, une clé locale a ouvert des milliers d’enregistrements, les journaux ont révélé des défaillances de stockage et le logiciel a montré des capacités plus larges que l’image publique d’un simple lecteur de plaques.

Pour les développeurs, la réponse n’est pas d’abandonner le traitement en périphérie. Il faut concevoir le système comme si le boîtier pouvait disparaître dès demain : réduire les données, séparer les clés, limiter les identifiants, consigner uniquement le nécessaire, tester la perte physique et donner à l’opérateur des moyens rapides de révocation. La confidentialité ne dépend pas d’un contrôle héroïque, mais de couches qui restent utiles lorsque l’une d’elles échoue.

En 2026, la question pertinente n’est pas « le disque est-il chiffré ? ». C’est plutôt : « quelles données restent exposées lorsque l’attaquant possède l’appareil, combien de temps vivent-elles et jusqu’où une identité compromise peut-elle aller ? ». Si votre équipe peut y répondre au moyen d’un test reproductible, elle a déjà retenu la principale leçon de cette caméra.

Allez, on y va! 🦅

📚 Vous Voulez Suivre Ce Qui Arrive?

Cet article a présenté l’intrusion physique dans une caméra Flock et la sécurité des appareils en périphérie, mais l’écosystème évolue chaque semaine et tout ne devient pas un article ici.

Sur X, je partage ce que je teste, les coulisses de mes projets et les nouveautés qui apparaissent avant de devenir des articles.

Suivez-Moi La-Bas

👉 Suivre @jeffbruchado sur X

💡 Du contenu quotidien sur le développement, la carrière et les outils que j’utilise réellement