> [!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 WebSocket routes: /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 (embedded and external auth modes, every deployment) </details> <details open> <summary><strong>Summary</strong></summary> WebSocket exec/log routes authorize on an unverified JWT payload, giving anonymous clients interactive exec into any microservice </details> <details> <summary><strong>Severity</strong></summary> Critical. Attacker: anonymous, network-adjacent to the controller API (the same exposure the browser console requires; the API is commonly internet- or VPN-reachable). Impact: interactive shell inside any running workload container on any managed edge node, including system microservices such as the router, plus unrestricted log exfiltration; this is full compromise of the edge fleet's workloads and a pivot to the controller's data plane. Complexity: trivial (one hand-crafted JWT, no secrets, no victim interaction, no race). Existing mitigations (rate limit, RUNNING check, concurrency cap) do not reduce impact. Both embedded and external auth modes are affected because neither branch reaches a verifier on the WebSocket path. </details> <details> <summary><strong>Weakness</strong></summary> CWE-347 </details> <details> <summary><strong>Location</strong></summary> `src/lib/rbac/middleware.js:268` Sinks: src/websocket/server.js:1840 handleUserExecConnection, src/websocket/exec-session-manager.js createExecSession, src/lib/rbac/authorizer.js:138 authorize </details> <details> <summary><strong>Methodology</strong></summary> 1. `WebSocket.Server({ server })` is attached directly to the HTTP server in `src/websocket/server.js:309-330`; upgrade requests never traverse the Express middleware chain, so the only bearer verification in the app (`jwtVerify` in `getOidcMiddleware`, `src/config/oidc.js:256`) is never executed for WebSocket connections. `verifyClient` (`src/websocket/server.js:1484`) only enforces per-IP connection/rate limits. 2. `handleConnection` (`src/websocket/server.js:1550-1633`) matches the URL against registered `ws` routes and invokes the route middleware. Every user-facing WS route wraps its handler in `rbacMiddleware.protectWebSocket` (`src/routes/microservices.js:1143,1191,1239,1289`, `src/routes/iofog.js:413`). 3. `protectWebSocket` (`src/lib/rbac/middleware.js:461-526`) takes the token from the `Authorization` header or the `?token=` query parameter and calls `authorizeWebSocket`. 4. `authorizeWebSocket` -> `extractSubjectsFromWebSocket` (`src/lib/rbac/middleware.js:263-285`) splits the token on `.` and `JSON.parse(Buffer.from(tokenParts[1], 'base64'))` the middle segment. The header and signature segments are never inspected; no `jwtVerify`, issuer, audience or expiry check occurs anywhere on this path (the same unverified decode is repeated at `:378-381` for the password-change gate). 5. Subjects are built from the forged claims: `preferred_username` -> `{kind:'User'}`, and `groups`/`roles` -> `{kind:'Group', name}` (`extractGroupSubjects`, `:53-86`). 6. `authorizer.authorize` (`src/lib/rbac/authorizer.js:151-184`) grants immediately when any Group subject name matches a system role; the hard-coded `admin` role has `resources: ['*'], verbs: ['*']` (`src/config/rbac-system-roles.js:14-30`). A payload of `{"preferred_username":"x","groups":["admin"]}` therefore returns `allowed: true` for `execSessions`/`logs`/`systemExecSessions`/`systemLogs` without any database lookup. 7. The route handler sets `req._rbacAuthorized = true` and calls `handleUserExecConnection` (`src/websocket/server.js:1840`), whose only token check is `validateUserConnection` (`:2304-2318`): it requires the token to be a non-empty string, then validates only that the microservice exists and is RUNNING. The comment at `:2329` states 'RBAC Authorization is handled at route level'. 8. The handler creates a `MicroserviceExecSession`, bumps change-tracking so the agent connects, and relays the client's stdin/stdout to the agent's container exec (`setupExecMessageForwarding`, `:1928-1931`). The logs routes stream container/agent logs the same way. Attacker input: a self-constructed string `a.<base64url({"preferred_username":"x","groups":["admin"],"sub":"x"})>.b` sent as `?token=` on `wss://controller:51121/api/v3/microservices/exec/<uuid>`. Microservice UUIDs are needed; they are UUIDv4 but are routinely present in console URLs, agent logs and the `findAgent`/`findApplication` template filters, and the system-exec route accepts any system microservice (e.g. router) on every node. </details> <details> <summary><strong>Validation</strong></summary> **Verification verdict:** TRUE POSITIVE #### Verification details No configuration flag disables the user WS routes or adds verification — `config.yaml`'s `webSocket` section is transport tuning only, and `server.js` initializes the WS server unconditionally on both the HTTP and HTTPS branches. That answers the remaining open questions. Here is the explicit completion of the outstanding phases. #### Phase 2 — remaining sub-check: race conditions / timing **N/A — not a race-based bug, and no timing complications exist.** The exploit is a single, self-contained WebSocket upgrade carrying a forged token; no state must be won against a concurrent actor. Token "reuse" is unlimited by design flaw: since expiry (`exp`) is never checked on this path (no `jwtVerify` runs), the forged token never expires and works on every connection. The authorizer's result cache (`storeCachedResult`) only caches the *grant*, which helps the attacker, not the defender. Concurrency caps (10 conns/IP, exec concurrency per microservice) bound parallelism, not exploitability. #### Phase 5 — Devil's advocate, all 13 questions 1. **Upstream validation?** No — `verifyClient` (server.js:1484-1521) does only drain/connection-cap/rate-limit; Express OIDC middleware never sees upgrade requests (ws installs its own `upgrade` listener on the Node server). 2. **Test/demo code only?** No — `src/lib/rbac/middleware.js` and `src/routes/{microservices,iofog}.js` are shipped production routes; the test harness (`buildFakeJwt`) merely corroborates the behavior. 3. **Mitigations sufficient?** No — rate limits and RUNNING checks throttle but never authenticate. 4. **Version-specific?** The vulnerable code is on current `main` (package.json version 3.9.1, commit 2026-10-13) — not a stale-branch artifact. 5. **Reachable in default deployment?** Yes — the README's quick-start `docker run` exposes port 51121; the WS server attaches unconditionally to that same API server in both the HTTP and HTTPS startup branches (server.js:226-227, 259-260). 6. **Config option that disables it?** None — `config.yaml`'s `webSocket` block has only transport settings (payload size, timeouts, deflate); there is no "require verified JWT on WS" or "disable user WS routes" switch, and `devMode` affects cookies/HTTPS, not this path. 7. **Exploitable or theoretical?** Exploitable — executed PoC: forged `groups:["admin"]` → `{"allowed":true,"reason":"admin system role has permission"}` through the real middleware, and `protectWebSocket` invoked the protected handler with the token in `?token=`. 8. **Environment/sandbox prevents it?** No — the controller is a plain Node container; nothing between the network and the upgrade handler re-establishes identity. 9. **Privilege-limited context?** No — success yields exec inside workload containers across the managed fleet (controller-operator-level capability), not a confined scratch context. 10. **Unanalyzed upstream/downstream protections?** Downstream, `validateUserConnection` (server.js:2304-2333) was analyzed: non-empty-token + microservice-RUNNING only, with the comment "RBAC Authorization is handled at route level". The agent-side routes have real EdDSA verification but are a different path. 11. **Input actually attacker-controlled?** Fully — the token string is attacker-constructed byte-for-byte; nothing canonicalizes or validates it before `JSON.parse(Buffer.from(...))`. 12. **FP pattern (stub confusion, unreachable path, harness)?** Checked — the PoC used the repo's real exported `authorizeWebSocket`/`protectWebSocket` with no RBAC stubs; the routes are registered live; negative controls (nobody-group denied, no-token closed with 1008) prove the grant comes from the forged claim, not an open default. 13. **Reporter assumption that breaks in real deployment?** The only deployment-dependent assumption is knowing a microservice UUID; the report addresses it credibly (UUIDs appear in console URLs, agent logs, template filters; system-exec targets system microservices like the router present on every node). The one overstatement candidate — "every deployment" — survives: no auth mode or config branch adds verification on this path. #### Gate review | Gate | Verdict | Evidence | |---|---|---| | 1. Process | **PASS** | Claim restated (Step 0), standard path chosen and justified, all phases executed this session; prior-session memory used only as a map, every citation re-verified in this clone. | | 2. Reachability | **PASS** | Source→sink traced in this clone: upgrade on apiServer → `handleConnection` → `protectWebSocket` (routes :1143/:1191/:1239/:1289, iofog.js:413) → `extractSubjectsFromWebSocket` → `authorizer.authorize` admin short-circuit; no verifier anywhere on the path (all three `jwtVerify` call sites confirmed elsewhere). | | 3. Real Impact | **PASS** | Authentication bypass → interactive container exec and log exfiltration across the fleet; primary control (signature verification) absent, remaining controls are defense-in-depth throttles only. | | 4. PoC Validation | **PASS** | Executable PoC run against real unstubbed code: forged-admin allowed, handler invoked via `?token=`; two negative PoCs (nobody-group denied, no-token closed 1008). Limitation noted honestly: in-process call, not a live socket — the sandbox blocks local port binding (EPERM), and the in-process test exercises the exact authorization decision the live handshake delegates to. | | 5. Math Bounds | **N/A — PASS** | No arithmetic/bounds component in this bug class (CWE-347). | | 6. Environment | **PASS** | Default deployment exposes the path (port 51121, WS attached unconditionally); no config flag, auth mode, or env protection changes the outcome; repo is active production software, not EOL. | #### Final verdict **TRUE POSITIVE** — Critical, CWE-347. The report's trace, trust-boundary analysis, and validation claims are all accurate as cited; its one gap (no executed PoC) was closed this session with an executed PoC plus negative controls. **EXPOSURE: REMOTE** — an unauthenticated client with network reach to the controller API port (51121) forges the token itself; the only extra knowledge needed is a running microservice's UUID. **SCOPE: PRODUCTION** — README: "Cloud-native control plane for edge fleets. Controller orchestrates Edgelet nodes, microservices, routing, NATS messaging, RBAC, and certificates," shipped as release container images with production run instructions. **Summary: 1 TRUE POSITIVE** (finding \#7440, forged-JWT WebSocket exec/log authorization bypass), **0 FALSE POSITIVES**. Finding \#7371 is a known duplicate of this same code path with the same verdict. </details> <details> <summary><strong>Detail</strong></summary> ### Source ```javascript function extractSubjectsFromWebSocket (req, token) { const subjects = [] 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) { ``` ### Trust boundary Unauthenticated remote network client -> controller operator privilege. The WebSocket exec feature is intended for operators holding an RS256 access token issued by the embedded or external OIDC issuer and bound by RBAC to `execSessions`/`systemExecSessions`. The crossing is authentication: the token's signature, issuer, audience and expiry are never checked on the WebSocket path, so the attacker fully controls the principal and group claims the authorizer evaluates. Victim prerequisites: none; the attacker needs network reach to the API port (which the browser console itself needs) and a target microservice UUID. Effective guards actually present: per-IP upgrade rate limit (60/min) and connection cap (10), microservice must exist and be RUNNING, exec concurrency cap per microservice. None of these re-establish identity. ### References - <https://github.com/OWASP/ASVS/blob/v5.0.0_release/5.0/en/0x18-V9-Self-contained-Tokens.md> — asvs,v9,jwt (ASVS 5.0 V9 Self-contained Tokens: verify signature, issuer, audience and expiry before trusting claims) - <https://github.com/OWASP/ASVS/blob/v5.0.0_release/5.0/en/0x13-V4-API-and-Web-Service.md> — asvs,v4,websocket (ASVS 5.0 V4 API and Web Service: WebSocket connections must be authenticated with the same rigor as HTTP) - <https://cwe.mitre.org/data/definitions/347.html> — cwe (CWE-347 Improper Verification of Cryptographic Signature) </details> <details> <summary><strong>Prior art</strong></summary> Discovered via source. No prior Scrutineer finding at this location (only betterleaks results existed for repository 959 at audit time; audit-authz/audit-injection were still running). The HTTP RBAC path (`protect`, `requirePermission`) is not affected because it reads `req.kauth`, which is only populated after `jwtVerify` in `src/config/oidc.js:256-260`. </details> <details> <summary><strong>Steps to reproduce</strong></summary> Static validation performed: (a) confirmed no code path between `wss.on('connection')` and `handleUserExecConnection` calls `jwtVerify`, `jose`, `AuthTokenService` or `FogKeyService` (grep over `src/websocket/server.js` and `src/lib/rbac/middleware.js`; the only `jwtVerify` callers are `src/config/oidc.js`, `src/services/auth-token-service.js` (refresh tokens) and `src/services/iofog-key-service.js` (agent EdDSA tokens)); (b) confirmed the Express OIDC middleware cannot run on upgrade requests because `ws` installs its own `upgrade` listener on the Node `http(s).Server`; (c) confirmed the system `admin` group short-circuits authorization without a RoleBinding lookup (`authorizer.js:151-166`); (d) confirmed the agent-side WS routes are different: they go through `AuthDecorator.checkFogToken` -> `FogKeyService.verifyJWT` with EdDSA signature + JTI replay checks (`src/websocket/server.js:2250`, `src/services/iofog-key-service.js:91-131`), so only the user-side routes are affected; (e) the repository's own test helper `buildFakeJwt` (`test/support/ws-session-harness.js:259-267`) builds `alg:none` tokens with a literal `signature` segment and the WS security tests pass them through `protectWebSocket` successfully with only the authorizer stubbed, which is consistent with no signature verification existing on this path; (f) `docs/operations/ws-sessions.md:18` documents user WS auth as 'Bearer JWT via Authorization header or ?token= query param' with no mention of ingress-side verification. Not executed: no live WebSocket connection was made (static audit). </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> (Like disabling a configuration option, for example) <!-- l1-helper-dup: dada990af47b87f82b6d2fd11352f127fb6b3f059a4ef22901bce2115a689091 --> </details>