Alarmed and Dangerous: A Security Researcher’s Look Inside a Monitoring App Vulnerability

Keegan Curran

— 3 min read

👋 Introduction: Why I Do What I Do

I work in cybersecurity, but even outside my day job, I often investigate the apps and services I use. It's part curiosity, part self-defense—and sometimes, it reveals something a little too real.

This time, my digging uncovered a severe security flaw in a monitoring panel application used by a major life safety monitoring provider. The impact? It wasn't just a bug—it was a structural vulnerability that put millions of facilities at risk.

That research led to a CVE, a CISA ICS advisory, and a coordinated remediation effort. This post summarizes what I found and why it matters.

🔍 Official Recognition

  • CVE ID: CVE-2025-0352
  • CISA Advisory: ICSA-25-051-05
  • Vulnerability Type: Insecure Direct Object Reference (IDOR)
  • Impact: Unauthorized access to facility data, alarm logs, and potential control over panel functions

This wasn’t hypothetical. It allowed unauthorized access to detailed account records and alarm panel activity across more than 2.6 million monitored locations.

🧪 Discovery and Methodology

Using Fiddler Everywhere and a lightweight Python script, I analyzed the mobile app's API traffic. The flaw: there was no server-side authorization enforcement between the authenticated session and the SiteNum requested.

This meant any valid session could enumerate through SiteNums and receive data from unrelated facilities, including:

  • Full site address
  • Monitoring region
  • Lockbox location and code hints
  • Test mode logs
  • Event history (e.g., alarms, dispatches, silences)

Here’s a simplified example of how enumeration was performed—without saving any personal data:

pythonCopyEditdef check_site_number(site_number):
payload["SiteNum"] = str(site_number)
response = requests.post(url, headers=headers, json=payload)
...

The process was controlled and ethical. Only aggregate data was stored, tracking the number of valid responses per city/state to gauge scope.

📦 What Was Exposed

✅ Verified:

  • Site/account information (addresses, regions, lockbox metadata)
  • Alarm panel logs (including ignored and silenced alerts)
  • Monitoring status per facility

🚩 Likely Vulnerable (but not tested due to ethical concerns):

  • Test mode toggles (enable/disable panel test states)
  • Alarm dispatch request endpoint (could trigger response protocols)

The structure of those endpoints was nearly identical to the ones exploited, strongly suggesting they were also unauthenticated or improperly scoped.

🧠 Why This Matters So Much

This platform wasn’t powering hobbyist home automation—it was the backend used by central station monitoring providers across North America. Facilities relying on this system include:

  • Apartment complexes and offices
  • Critical infrastructure
  • Industrial sites
  • Schools and public buildings

A compromise here could have enabled:

  • False alarm floods, tying up emergency dispatch
  • Suppression of real alarms, leaving events undetected
  • Targeted phishing using real location details and alarm history

With 2.6+ million records accessible via an unauthenticated enumeration pattern, this wasn’t just a data leak—it was a full-blown threat to physical security and emergency response reliability.

🔒 Responsible Disclosure

The full technical report was shared directly and privately with the company, including:

  • All vulnerable endpoints and PoCs
  • Suggested remediations and access control patterns
  • Enumerated impact summary (non-PII)

They acknowledged the report, coordinated with CISA, and took the issue seriously—something I deeply respect.

🛠 Recommendations

My recommendations (now echoed by CISA) included:

  1. Enforce server-side access control
    Each API request should confirm that the requesting session is authorized to access the SiteNum resource.
  2. Avoid client-side trust
    Never rely on frontend apps to enforce access. All authorization checks must happen server-side.
  3. Implement certificate pinning
    To prevent interception and replay via MITM tools during mobile traffic analysis.
  4. Add rate limiting and audit logging
    This prevents mass enumeration and flags unusual API access patterns early.

🧭 Timeline Summary

  • Initial discovery: Conducted independently during off-hours
  • Vendor notified: Sent full report and sample enumeration
  • CVE Assigned: CVE-2025-0352
  • CISA Advisory Released: ICSA-25-051-05

📢 Final Thoughts

This was one of the simplest—but most dangerous—vulnerabilities I’ve found. It required no advanced payloads or zero-day exploits. Just curiosity, an intercepting proxy, and a few lines of code.

In ICS and life safety systems, simple flaws become existential threats.

I’m glad the vendor took this seriously. If you’re developing or auditing systems like these, don’t assume authentication equals authorization. Validate every request. Scope every resource. Treat safety-critical apps like safety-critical code.

Thanks for reading. Stay safe out there.

Read more