Flock Camera Hack Reveals 1.6 Million Images and System Weaknesses

Hackers exfiltrated 1.6 million images from a single Flock camera

Takeaway: A hacker group stole a Flock ALPR camera, dumping its on‑device storage and logs, which contain 1.6 million images of roughly 50 000 vehicles captured over 21 days. The breach shows that the camera stores raw images locally without strong encryption and relies on a cloud backend that could add facial‑recognition capabilities.

What the leaked data contains

  • Image volume: Approximately 1.6 million JPEGs captured from 50 200 distinct vehicles.
  • Capture rate: The device logged an average of 3 300 vehicles per day, peaking at 4 454.
  • Storage failures: Logs record >27 000 “no space left on device” errors, thousands of crashes, and frequent reboots.
  • Heartbeat messages: Every two minutes the firmware logged “Who’s a good boy?!” – over 12 000 occurrences in the recovered logs.
  • System messages: Reboot events include the phrase “A reboot was requested! ¡Adiós, Amigos!” indicating a whimsical developer touch.

These artifacts were published by Distributed Denial of Secrets (DDOS) and can be examined at https://ddosecrets.org/article/flock-alpr-camera.

How the camera works – architecture revealed by the dump

  1. On‑device capture: The camera records high‑resolution frames locally on an SD card‑like partition. No evidence of on‑device encryption was found.
  2. Periodic upload: Images are batched and sent over Wi‑Fi/Bluetooth to Flock’s cloud service for processing.
  3. Backend processing: The cloud performs license‑plate recognition (ALPR) and, according to community analysis, can run additional AI models such as facial‑recognition or person‑detection – even though Flock’s marketing claims the camera itself does not perform facial recognition.
  4. API key exposure: The leaked firmware contains a hard‑coded API key that can retrieve stored credentials in plaintext, allowing an attacker to impersonate a camera and request data from Flock’s servers.

"The cameras don’t do facial recognition, but the backend can. The system detects people, making it easy for the server to run face‑recognition models later." – HN comment by phkahler

Security failures highlighted by the community

  • No-at‑rest encryption: The raw image partition is readable without authentication, contradicting best practices for IoT devices.
  • Hard‑coded credentials: An API key embedded in firmware enables unauthenticated access to backend services.
  • Out‑of‑date OS: Commenters note the camera runs an Android build missing security updates for eight years, exposing it to known kernel exploits.
  • Insecure boot & key management: As pointed out by killbot5000, the device lacks a secure boot chain and proper key storage, making physical access a trivial attack vector.
  • Vulnerability Disclosure Policy (VDP) loopholes: The VDP explicitly excludes reporting of configuration, SSL/TLS, and DNS hardening issues, limiting responsible disclosure.

"If you want to know what a ‘Vulnerability Disclosure Policy’ looks like when it’s just a PR stunt, read Flock’s VDP. They exclude the very categories that matter most." – HN comment by vayup

Operational impact and legal context

  • Potential privacy violations: The captured images include non‑hit license plates. Under New Hampshire law (N.H. Rev. Stat. § 261:75‑b), non‑hit data must be deleted within three minutes, a requirement that the leaked logs do not appear to enforce.
  • Law‑enforcement reliance: Flock’s cameras are deployed by municipal police departments and federal agencies; the leaked data confirms that a single compromised device can expose a massive trove of public‑space surveillance.
  • Regulatory risk: With the EU’s GDPR and upcoming U.S. state privacy laws, the lack of encryption and data‑retention controls could trigger enforcement actions if the devices are used in those jurisdictions.

Community speculation on broader threats

  • Mass surveillance amplification: Several commenters warn that the backend’s ability to run facial‑recognition models could turn a simple ALPR system into a full‑scale biometric surveillance network.
  • Potential for weaponization: The open‑source nature of the leak means adversaries (foreign intelligence, stalkers, domestic abusers) could replicate the attack to track individuals in real time.
  • Infrastructure fragility: A suggestion was made that a “stingray‑style” radio attack could force a firmware update and potentially brick large numbers of cameras.

What this means for IoT security

  1. Physical security matters: Devices deployed in public spaces must assume attackers can obtain physical access; secure boot, encrypted storage, and tamper‑evident hardware are essential.
  2. End‑to‑end encryption is non‑negotiable: Storing raw images without encryption violates industry standards such as IEC 62443 and exposes massive privacy risks.
  3. Transparent VDPs are required: Companies should accept reports on configuration and infrastructure weaknesses, not just software bugs.
  4. Regulators may act: The breach provides concrete evidence that could inform upcoming legislation targeting ALPR and AI‑enabled surveillance.

Next steps for stakeholders

  • Flock: Issue a full security advisory, revoke compromised API keys, roll out encrypted storage, and publish a revised VDP that accepts all categories of vulnerability reports.
  • Municipal purchasers: Conduct security audits of deployed cameras, enforce strict data‑retention policies, and consider alternative vendors with proven security postures.
  • Researchers: Continue analyzing the leaked firmware and logs to identify any additional back‑door capabilities or data‑exfiltration pathways.
  • Policymakers: Use the leak as a case study when drafting ALPR regulations, emphasizing encryption, data minimization, and auditability.

The hack underscores how a single insecure IoT device can become a gateway to massive, unprotected surveillance data, highlighting the urgent need for robust security standards across the entire data pipeline.

Sources

Related