OpenRemote Manager Cross-Tenant IDOR in Bulk Alarm Deletion

Vulnerability Description

OpenRemote Manager contains a classic Insecure Direct Object Reference (IDOR) flaw in the bulk alarm deletion endpoint. The vulnerability stems from inconsistent authorization logic between two methods: the singular removeAlarm() correctly validates realm ownership per alarm, while the plural removeAlarms() only checks whether the caller's own realm is active—a trivial check satisfied by any authenticated user. This creates a multi-tenant isolation bypass where an attacker can reference arbitrary alarm IDs and achieve unconditional deletion across tenant boundaries.

Root Cause & Impact

The root cause is missing per-object authorization in the batch operation handler. Rather than iterating through each alarm and validating alarm.getRealm() == callerRealm, the code assumes realm validation at the function entry point is sufficient. The impact is severe: any authenticated user (even with minimal 'alarm write' permissions in their own realm) can permanently destroy safety-critical alerts and security incident logs in other realms, potentially masking intrusions, tampering with safety evidence, or causing availability damage.

Detection Guidance

Defenders should monitor for:

• API logs: POST/DELETE requests to /api/alarm or /api/alarms endpoints with removeAlarms parameters containing alarm IDs belonging to different realms than the requester's authenticated context
• Audit trails: Alarm deletion records where the deleting user's realm does not match the deleted alarm's realm
• Log signatures: Search application logs for realm mismatches in alarm lifecycle events (e.g., "user@realm-A deleted alarm from realm-B")
• Behavioral indicators: Spikes in cross-realm deletion attempts; a single user deleting alarms at unusual scale or frequency

Mitigation & Patching

Immediate actions:

1. Apply vendor patches when available; this flaw requires code-level remediation (adding realm validation in the loop)
2. Workaround: Implement WAF/reverse-proxy rules to block bulk alarm delete requests; restrict alarm write permissions to read-only for non-administrators
3. Access control: Disable cross-realm user impersonation; enforce strict role-based access controls (RBAC) scoped per realm
4. Monitoring: Enable detailed API audit logging; alert on any cross-realm object access attempts

Risk Assessment

Likelihood of exploitation: High. The flaw requires no privilege escalation—any authenticated user qualifies. Exploitation is trivial: supply arbitrary alarm IDs in a single request. Threat actor interest: Critical infrastructure operators, multi-tenant SaaS providers, and regulated industries (healthcare, energy, manufacturing) are prime targets due to safety and compliance implications. The ability to delete safety alerts without authorization is a high-value capability for adversaries seeking to mask malicious activity or cause operational disruption.