Summary
A logic flaw in Coturn's mobility feature allows authenticated attackers who obtain a victim's MOBILITY-TICKET to resume allocations using their own credentials instead of the original owner's.
Under these conditions, an attacker can receive and inject relayed traffic through the victim's allocation and consume the victim's TURN quota without being detected as impersonation.
Affected context
This vulnerability occurs in Coturn TURN/STUN servers configured with the --mobility option enabled and using long-term credentials.
It manifests during the handling of resumed REFRESH requests when allocations are resumed based solely on an attacker-controlled mobility identifier.
The risk is present when MOBILITY-TICKET values can be captured, reused, or otherwise obtained by an authenticated party who is not the original allocation owner.
Exploit preconditions
- Attack surface: TURN
REFRESHresume processing in mobility-enabled Coturn servers - Required access: Valid long-term credentials on the server and access to a victim's MOBILITY-TICKET
- Trigger point: Sending a resumed
REFRESHrequest using the victim's mobility identifier from an attacker-authenticated session - Why exploitation is possible: The resumed allocation is located using only the mobility ID, and the authorization check validates against the resuming user's identity rather than confirming that the requester matches the original allocation owner.
Why this happens
The root cause is an authorization logic error where allocation ownership is not revalidated during session resumption.
In the handle_turn_refresh resume branch, Coturn locates the victim's allocation using a mobile identifier controlled by the requester, then relies on existing authentication state (hmackey_set) to validate the REFRESH without confirming that the resuming session belongs to the allocation owner.
Because credentials are only copied when the resuming session is unauthenticated, a previously authenticated attacker can reuse their own identity while controlling the victim's allocation context.
This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where a user-supplied token (mobility ID / MOBILITY-TICKET) is used as a lookup key without properly ensuring that the requester is the legitimate owner of the referenced resource.
Potential impact
- An attacker may receive relayed traffic intended for the victim's TURN allocation.
- An attacker can inject arbitrary traffic through the victim's allocation, potentially enabling spoofing or abuse.
- The victim's TURN quota can be consumed, leading to denial of service or unexpected resource usage.
- Logging and accounting may incorrectly attribute traffic to the victim, complicating incident response and auditing.
General mitigation guidance
Mitigation generally focuses on strengthening authorization checks around resource resumption and token-based mobility.
Recommended design patterns include:
- Ensuring that any mobility or session-resumption identifier is bound to both the allocation and the original authenticated identity, and that both are checked on resume.
- Treating resumption tokens (like MOBILITY-TICKETs) as sensitive bearer credentials, limiting their lifetime and scope, and requiring proof-of-possession or re-authentication when reused.
- Resetting or revalidating authentication state when switching allocation contexts, rather than relying on prior
hmackey_setflags alone. - Applying least-privilege principles to TURN allocations so that resumed sessions cannot escalate access beyond what the original owner had.
- Designing server-side checks that reject resumption attempts when the requesting identity does not match the allocation owner, even if the requester is otherwise authenticated.
How teams detect issues like this
Detection efforts can focus on identifying authorization inconsistencies and suspicious mobility behavior:
- Static analysis and code review can look for authorization flows where user-controlled identifiers (such as mobility IDs or tickets) are used to locate allocations or sessions without explicit owner verification.
- Security-focused reviews of TURN/STUN server code should trace how authentication state flags (e.g.,
hmackey_set) influence decision-making and confirm that resource ownership is revalidated when resuming allocations. - Runtime monitoring can flag unusual patterns where traffic associated with a single allocation appears to be driven by multiple authenticated identities or where resumption events occur from unexpected clients.
- Policy enforcement in CI/CD can require explicit checks tying resumption tokens to both resource identifiers and user identities, and can reject changes where authorization is inferred from prior state rather than recomputed per request.
