> [!warning] AI-Generated Vulnerability Report > This report was produced using AI-assisted security analysis, adversarially verified but not human-confirmed. This finding was challenged against the codebase and survived; we filter out low-confidence results rather than forwarding raw model output. Technical details, exploitability, and severity may still be wrong. Please validate independently before acting. <details open> <summary><strong>Basic information</strong></summary> **Project name:** Eclipse ioFog™ **Project id:** iot.iofog **Repository:** https://github.com/eclipse-iofog/controller </details> <details> <summary><strong>What are the affected versions?</strong></summary> All user-facing WebSocket routes registered with rbacMiddleware.protectWebSocket: /api/v3/microservices/exec/:microserviceUuid, /api/v3/microservices/system/exec/:microserviceUuid, /api/v3/microservices/:uuid/logs, /api/v3/microservices/system/:uuid/logs, /api/v3/iofog/:uuid/logs </details> <details open> <summary><strong>Summary</strong></summary> WebSocket RBAC trusts unverified JWT payload: forged token grants admin exec/logs access </details> <details> <summary><strong>Severity</strong></summary> Critical / high confidence. Complete authentication and authorization bypass of the operator WebSocket API, giving an anonymous attacker an interactive shell inside any workload container on any edge node, plus live logs of every microservice and fog. Remediation: in `authorizeWebSocket`/`protectWebSocket`, verify the bearer with the same `jose.jwtVerify(token, jwks, { issuer, audience })` used by `getOidcMiddleware` (reject `token_use === 'refresh'`) and derive subjects only from the verified payload; apply the same to `scheduleAgentExecConnectEvent`-style decoders if they influence anything beyond logging. </details> <details> <summary><strong>Weakness</strong></summary> CWE-347 </details> <details> <summary><strong>Location</strong></summary> `src/lib/rbac/middleware.js:270` Sinks: WebSocketServer.handleUserExecConnection (interactive exec session into any microservice container), WebSocketServer.handleUserLogsConnection (live log stream of any microservice or fog) </details> <details> <summary><strong>Methodology</strong></summary> 1. Client opens a WebSocket upgrade to `/api/v3/microservices/exec/<uuid>` with `Authorization: Bearer <token>` or `?token=<token>`. The `ws` server is attached directly to the HTTP server (`src/websocket/server.js:310-326`), so Express middleware, including the OIDC bearer verifier in `src/config/oidc.js:239-268`, never runs for upgrade requests. `verifyClient` (`src/websocket/server.js:1484`) only applies rate/connection limits. 2. `handleConnection` (`src/websocket/server.js:1590-1632`) matches the registered route and calls its middleware, which is `rbacMiddleware.protectWebSocket(...)` (`src/routes/microservices.js:1143`). 3. `protectWebSocket` (`src/lib/rbac/middleware.js:461`) extracts the token and calls `authorizeWebSocket` (`:366`), which calls `extractSubjectsFromWebSocket` (`:263`). 4. `extractSubjectsFromWebSocket` splits the token on `.` and does `JSON.parse(Buffer.from(tokenParts[1], 'base64'))` (`:270`). No signature verification, no issuer/audience/expiry check, no call to `jose.jwtVerify`. The `roles`/`groups`/`resource_access` arrays of the attacker-written payload become Group subjects (`extractGroupSubjects`, `:54-87`). 5. `authorizer.authorizeRequest` (`src/lib/rbac/authorizer.js:143-164`) treats a Group subject named `admin` as the static ADMIN_ROLE (`resources:['*'], verbs:['*']`, `src/config/rbac-system-roles.js:14-30`) and returns `allowed: true` without touching the database. 6. The route handler sets `req._rbacAuthorized = true` and calls `handleUserExecConnection` (`src/routes/microservices.js:1166`). Its only token check is `validateUserConnection` (`src/websocket/server.js:2304-2318`), which merely requires a non-empty string after stripping `Bearer `; the comment at `:2335` says RBAC is handled at route level. 7. An exec session is created and the agent is instructed to attach a shell to the container; stdin/stdout are relayed to the attacker's socket. </details> <details> <summary><strong>Validation</strong></summary> **Verification verdict:** TRUE POSITIVE #### Verification details Formal phase documentation, completing the verification record for finding \#7371. All evidence below was gathered in this session against the clone at HEAD `de510d4`. #### Phase 1 — Data Flow Analysis **Source → sink trace (every hop verified in the clone):** 1. **Source:** attacker-supplied WS upgrade request to `/api/v3/microservices/exec/:uuid` (or the four other `method:'ws'` routes), token in `Authorization` header or `?token=` query param — `src/lib/rbac/middleware.js:461-485` reads both. 2. WS server attaches to the raw API HTTP/HTTPS server (`src/server.js:226-228, 259-261` → `wsServer.initialize(apiServer)`), so **Express middleware — including the OIDC verifier `src/config/oidc.js:256` — never runs on upgrade requests**. `verifyClient` (`src/websocket/server.js:1484`) does only per-IP connection counting and rate limiting. 3. `protectWebSocket` → `authorizeWebSocket` (`middleware.js:366`) → `extractSubjectsFromWebSocket` (`:263-285`): `JSON.parse(Buffer.from(tokenParts[1],'base64'))` — **sink: unverified claims become RBAC subjects**. No `jwtVerify`, no issuer/audience/expiry check. 4. `authorizer.authorizeRequest` (`src/lib/rbac/authorizer.js:150-168`): a Group subject named `admin` matches the static ADMIN_ROLE (`resources:['*'], verbs:['*']`, `src/config/rbac-system-roles.js:14-30`) and returns `allowed:true` **before any DB lookup** — no account need exist. 5. `handleUserExecConnection` → `validateUserConnection` (`src/websocket/server.js:2304`): non-empty-string check only; its comment defers RBAC to the route level. **Trust boundary:** unauthenticated network client → admin-level operator. **API contracts:** `jose`'s verify API exists and is used on the HTTP path; the WS path deliberately decodes without it. **Cross-references:** grep over `src/` shows the only `jwtVerify` call sites are `oidc.js:256` (HTTP), `auth-token-service.js:110` (refresh), `iofog-key-service.js:110` (agent) — none reachable from the user WS path. **Environment protections:** none found — routes registered unconditionally; `verifyClient` is rate-limiting only; TLS does not authenticate the client. #### Phase 2 — Exploitability Verification - **Attacker control: CONFIRMED.** The attacker authors the entire JWT payload; the forged `groups:["admin"]` claim is the exact value matched by the authorizer. Executed PoC proves causation (see Phase 4). - **Mathematical bounds: N/A** — logic/authentication flaw (CWE-347), no bounds arithmetic involved. - **Race conditions: N/A** — single-request, deterministic path; no check/use separation. - **Adversarial analysis — what could still stop the attacker?** (a) Password-change gate (`enforcePasswordChangeGateForWebSocket`): looks up `sub` and blocks only *existing* users flagged for rotation; a bogus `sub` passes — confirmed by the PoC which traversed this gate live. (b) Route-catalog lookup: the exec route *is* in the catalog (and uncatalogued routes are allowed "for backward compatibility", `middleware.js:395-399` — fail-open). (c) `validateMicroservice`/RUNNING-status check: requires the attacker name a real running microservice UUID; UUIDs are enumerable via the same forged-admin access to list/log routes, so this is a minor targeting step, not a barrier. No protection prevents exploitation. #### Phase 3 — Impact Assessment - **Real security impact, not operational robustness:** the outcome is interactive shell execution inside any workload container on any edge node (`handleUserExecConnection` instructs the agent to attach a shell and relays stdin/stdout), plus live log disclosure of every microservice and fog. That is privilege escalation (anonymous → cluster admin) and remote command execution on managed workloads — direct CIA impact. - **Primary control vs defense-in-depth:** JWT signature verification *is* the primary authentication control on this path; it is absent, not merely weakened. There is no second authentication layer behind it (`validateUserConnection` explicitly defers to the broken route-level RBAC). Critical severity is justified. #### Phase 4 — PoC Creation - **Pseudocode PoC:** `token = b64url({alg:"none"}) + "." + b64url({sub:"attacker", groups:["admin"]}) + ".AAAA"`; open `ws(s)://controller:51121/api/v3/microservices/exec/<uuid>?token=<token>`; RBAC grants admin; exec session attaches to the container shell. - **Executable PoC: RUN.** In-process Node script (built the project with `npm install --ignore-scripts --legacy-peer-deps` + `npm rebuild sqlite3`) calling the **real** `authorizeWebSocket` with the real exec-route URL. Result: `{"allowed":true,"reason":"admin system role has permission"}`. - **Negative PoCs: RUN.** Same harness, forged token with `groups:["nobody"]` → denied ("Authorization denied…"); no token → denied ("No subjects found"). This isolates the forged `admin` group as the sole cause of the grant. - **Full end-to-end socket PoC skipped with justification:** the sandbox blocks local port binding (known limitation), and the remaining hops after the authorize grant (`req._rbacAuthorized = true` → `handleUserExecConnection`) were verified by code reading (`src/routes/microservices.js:1143-1166`) to contain no further token checks. The repo's own test harness (`test/support/ws-session-harness.js`, `buildFakeJwt()` building unsigned tokens) independently corroborates that unsigned tokens are accepted end-to-end. - **PoC verification:** output reproduced above in-conversation; positive and negative cases behave as predicted. #### Phase 5 — Devil's Advocate (13-item checklist) 1. **Full validation chain traced:** yes — upgrade bypasses Express/OIDC; every guard between socket and sink enumerated; none verifies the signature. 1a. **Conditional reachability:** route is in the RBAC catalog and registered unconditionally; no condition makes the path unreachable. 2. **Defensive programming?** No — the decode is the *authentication decision itself*, not an assertion backed by a real check elsewhere. 3. **Exploitable data path confirmed:** yes, by executed PoC through the real functions, not pattern-matching. 4. **Data source context:** token is pure attacker input from the network; nothing upstream constrains it. 5. **Bounds validation logic:** N/A (no arithmetic). 6. **TOCTOU claims:** N/A (none made). 7. **API contract:** `jose.jwtVerify` is available and used on the HTTP path; the WS path's manual decode has no hidden safety guarantee. 8. **Internal storage vs external input:** the matched `admin` role is a hard-coded system role, but the *subject* claiming it comes entirely from external input — that's the flaw, not a mitigation. 9. **Pattern recognition vs analysis:** verdict rests on an executed PoC with negative controls, not on the code "looking unsafe". 10. **Concurrency actually possible:** N/A. 11. **Real vs theoretical impact:** real — anonymous → admin exec into edge containers. 12. **Defense-in-depth vs primary control:** the missing check is the primary control; nothing behind it compensates (confirmed at `validateUserConnection`). 13. **Checklist applied systematically:** all items addressed above; two independent reports (\#7371, \#7440) and the repo's own unsigned-token test harness converge on the same conclusion. #### Gate Review | Gate | Verdict | Evidence | |---|---|---| | 1. Process | **PASS** | Phases 0–5 documented above with file:line evidence | | 2. Reachability | **PASS** | Unauthenticated upgrade path traced hop-by-hop; PoC confirms attacker-controlled claims drive the grant | | 3. Real Impact | **PASS** | Admin exec/log access = privesc + RCE on managed workloads, not an operational nit | | 4. PoC Validation | **PASS** | Executable PoC run against real code: forged admin → allowed; two negative controls denied | | 5. Math Bounds | **PASS (N/A)** | Logic/auth flaw; no mathematical precondition to disprove | | 6. Environment | **PASS** | No environmental protection blocks it: WS bypasses OIDC middleware, `verifyClient` rate-limits only, routes always registered, TLS doesn't authenticate clients | #### Verdict **BUG \#7371 TRUE POSITIVE — WebSocket RBAC accepts unverified JWT payloads; a self-minted `groups:["admin"]` token grants anonymous admin exec/log access (CWE-347, Critical).** Duplicate of finding \#7440 (same code path, same verdict, verified earlier today) — triage as one issue. **Final summary: 1 TRUE POSITIVE, 0 FALSE POSITIVES.** EXPOSURE: REMOTE — any unauthenticated client that can reach the Controller API port (51121 per the documented `docker run`) can open the WS upgrade with a forged token; no credentials or foothold required. SCOPE: PRODUCTION — the README describes shipped software: "**Cloud-native control plane for edge fleets.** Controller orchestrates Edgelet nodes, microservices, routing, NATS messaging, RBAC, and certificates", distributed as release container images; no EOL/deprecation notices. </details> <details> <summary><strong>Detail</strong></summary> ### Source ```javascript if (token) { try { const tokenParts = token.replace('Bearer ', '').split('.') if (tokenParts.length === 3) { const payload = JSON.parse(Buffer.from(tokenParts[1], 'base64').toString()) const user = extractUserSubject(payload) if (user) { subjects.push(user) } ``` ### Trust boundary Unauthenticated network client -> Admin-level operator. The actor needs no account at all: a self-minted JWT such as `header.base64({"sub":"x","preferred_username":"x","roles":["admin"]}).anything` passes `extractSubjectsFromWebSocket` and the RBAC system-role check. The same token also bypasses the password-change gate (`userStillRequiresPasswordChange` looks up `sub` and returns `true` only for existing users who must rotate, so a bogus `sub` is not blocked). ### Reach Every deployment: the WebSocket server is always started on the API port (`startHttpServer`/`startHttpsServer` in `src/server.js:226-228, 259-261`) and the user WebSocket routes are registered unconditionally by `setupMiddleware`. </details> <details> <summary><strong>Prior art</strong></summary> Discovered via source. No existing findings were returned by the Scrutineer findings API for this repository. </details> <details> <summary><strong>Steps to reproduce</strong></summary> Entry point: WebSocket upgrade to any route registered with `method: 'ws'` and wrapped by `rbacMiddleware.protectWebSocket` (e.g. `src/routes/microservices.js:1142-1143`). Effective guard chain: `verifyClient` (rate limiting only) -> `protectWebSocket` -> `authorizeWebSocket` -> `extractSubjectsFromWebSocket` (base64 decode only) -> `authorizer.authorizeRequest` (system-role match on decoded `roles`/`groups`) -> `validateUserConnection` (non-empty string check). Privileged action: `handleUserExecConnection` / `handleUserLogsConnection` create exec or log sessions against any microservice or fog selected by the URL. Missing rule: cryptographic verification of the bearer token (issuer JWKS, issuer, audience, expiry, `token_use`) before claims are used as the principal. Verified that the only `jwtVerify` call sites in first-party code are the HTTP OIDC middleware (`src/config/oidc.js:256`), the refresh-token path (`src/services/auth-token-service.js:110`) and the agent fog-key path (`src/services/iofog-key-service.js:110`); none is reachable from the user WebSocket path. The repository's own `test/src/websocket/ws-security.test.js` builds tokens with `buildFakeJwt()` (unsigned), which is consistent with this behaviour. Code is current on the default branch (`de510d4`, 2026-10-13). Not executed in this container: the audit was run read-only per the skill constraints. </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> (Like disabling a configuration option, for example) <!-- l1-helper-dup: 01da89456acbbff2976430fb3e344766ed1aa0dfd478b1ce598690081711d725 --> </details>