Solstice Pod 6.2 - API Session Key Extraction via API Endpoint

Solstice Pod 6.2 — API Session Key Exposure via Unauthenticated /api/config Endpoint

This article explains a reported information disclosure issue affecting Solstice Pod firmware (reported in versions up to 6.2). The vulnerable API endpoint returned configuration data that included sensitive session information and product metadata without requiring authentication. The focus here is on understanding the risk, performing safe assessments, and implementing robust mitigations and monitoring to protect deployments. Exploit code and step-by-step attack instructions are intentionally omitted; the guidance below is defensive and aimed at administrators and defenders.

Executive summary

• Vulnerability type: Unauthenticated information disclosure (sensitive session data in API response).
• Primary impact: Leak of session-related tokens/keys and device metadata that could aid further reconnaissance or unauthorized access attempts.
• Affected components: Solstice Pod API endpoint that returns device configuration (reported in versions up to 6.2).
• Priority actions: Audit devices, apply vendor updates or patches, restrict access to management APIs, and implement response redaction and authentication.

Why this matters

Exposed session keys or authentication artifacts in unauthenticated API responses significantly increase the attack surface. Even if the keys are short-lived, they can enable unauthorized sessions, lateral movement, or automation to discover additional weaknesses. Product metadata (version, variant, display name) also helps attackers identify exploit paths and craft targeted attacks.

Risk and potential impacts

• Unauthorized disclosure of session tokens leading to session hijacking.
• Information useful for targeted exploitation: exact server version, product variant, and exposed services.
• Reconnaissance acceleration — easier to fingerprint devices inside an organization.
• Regulatory or contractual exposure where device confidentiality is required.

Safe assessment and detection

When assessing whether your environment is affected, follow defensive, non-invasive practices. The goal is to identify devices that expose management APIs without authentication and to verify whether responses include sensitive fields.

Recommended assessment steps (defensive)

• Inventory all Solstice Pod devices and record firmware versions and network placement (management vs. guest networks).
• Review network segmentation: ensure management interfaces are not reachable from untrusted networks or the internet.
• Check configuration management and automated inventories from trusted sources rather than issuing unauthenticated queries from public networks.
• If you must query a device during an internal assessment, use an authenticated management channel or work with vendor support for safe scanning guidance.
• Inspect logs for unexpected access to management endpoints and anomalous requests to configuration APIs.

Detection signals to look for

• Unauthenticated GET requests to device configuration endpoints originating from unexpected sources.
• SIEM alerts for sensitive-key pattern matches in outgoing responses (if you capture API responses in internal logging pipelines).
• Unexpected changes to session state or multiple session creations correlating with management endpoint access.

Mitigations and recommended fixes

Mitigation should be implemented at multiple levels: vendor/firmware patches, access control, API hardening, and network controls. Below are prioritized steps for administrators.

1) Apply vendor patches and updates

• Check with the vendor (Mersive) for firmware updates, security advisories, and recommended patches. Apply vendor fixes as soon as feasible following your change management process.
• If a patch is not yet available, follow compensating controls below.

2) Restrict network exposure

• Move management interfaces to isolated management VLANs; block access from guest or public networks.
• Use firewall rules to restrict which IP ranges can reach management ports (e.g., only specific admin subnets or bastion hosts).
• Where possible, enable VPN or IPsec for remote administrative access rather than exposing management ports directly.

3) Enforce strong authentication and authorize API access

• Require authentication for all management APIs; deny anonymous GET/POST for configuration endpoints.
• Use mutually authenticated TLS (client certificates) for admin APIs when supported.
• Implement RBAC so that only necessary accounts can view sensitive configuration data.

4) Redact sensitive fields at the API layer

If the device software exposes sensitive fields in API responses, ensure the server removes or redacts them before returning data to unauthenticated or insufficiently privileged requests. The example below demonstrates a defensive approach: intercept the outgoing JSON and redact known sensitive keys. This is sample mitigation code for an API gateway or reverse-proxy filter — not an exploit.

# Example: Python WSGI middleware to redact sensitive JSON keys before responses
# (Intended for an API gateway or proxy; adapt to your tech stack)

import json
from wsgiref.util import setup_testing_defaults

SENSITIVE_KEYS = {"sessionKey", "authToken", "m_authenticationCuration"}

def redact_json_body(body_bytes):
    try:
        data = json.loads(body_bytes)
    except Exception:
        return body_bytes  # Not JSON or parse error — leave unchanged
    # Recursively redact keys
    def walk(obj):
        if isinstance(obj, dict):
            for k in list(obj.keys()):
                if k in SENSITIVE_KEYS:
                    obj[k] = ""
                else:
                    obj[k] = walk(obj[k])
        elif isinstance(obj, list):
            return [walk(i) for i in obj]
        return obj
    redacted = walk(data)
    return json.dumps(redacted).encode("utf-8")

def simple_redact_middleware(app):
    def middleware(environ, start_response):
        setup_testing_defaults(environ)
        status_headers_body = []
        def custom_start_response(status, headers, exc_info=None):
            status_headers_body.append((status, headers))
            return start_response(status, headers, exc_info)
        result = app(environ, custom_start_response)
        body = b"".join(result)
        # Only attempt to redact application/json responses
        headers = dict(status_headers_body[0][1])
        if headers.get("Content-Type", "").startswith("application/json"):
            body = redact_json_body(body)
        return [body]
    return middleware

Explanation: This middleware intercepts responses from an API server or gateway. If the response is JSON, it attempts to parse and recursively redact any keys listed in SENSITIVE_KEYS by replacing their values with "". Deploying a filter like this on a reverse proxy or API gateway ensures no unauthenticated response leaks session tokens.

5) Enforce TLS and certificate validation

• Do not accept insecure TLS versions; require TLS 1.2+ or TLS 1.3 and disable weak ciphers.
• Enable certificate verification on API clients and support HSTS on web-facing management consoles.

6) Access control at the web server / gateway

Use webserver configuration to block unauthenticated access to sensitive endpoints. Example: an NGINX location block that allows only authenticated clients (this example requires adapting to your environment and integrating with your auth system).

# Sample NGINX snippet: deny public access to /api/config and proxy authenticated requests only
location /api/config {
    satisfy any;
    allow 10.0.0.0/16;     # management network only (example)
    deny all;
    # Alternatively, require client cert validation or an auth request
    # proxy_pass http://backend;
    # proxy_set_header X-Authenticated-User $remote_user;
}

Explanation: The snippet restricts access to the /api/config path to a specified management subnet. Replace the CIDR with your actual management network. In production, integrate client certificate validation or an authentication layer to allow only authorized clients.

7) Logging, monitoring, and alerting

• Log all accesses to management APIs with source IP, user-agent, and request path. Retain logs for forensic needs and compliance.
• Create SIEM alerts for:
  • Unauthenticated requests to management endpoints.
  • Responses that include tokens or patterns matching session keys.
  • Unexpected hostnames or devices returning management responses on guest networks.
• Use network IDS/IPS signatures to detect anomalous enumeration of internal management APIs.

Testing remediation safely

After applying fixes, validate them using internal, authorized testing only. Avoid public or internet-facing probes. Recommended steps:

• Functional test: Ensure the API still serves required data to authorized clients while redacting or denying unauthenticated access.
• Regression test: Confirm that legitimate admin workflows are not broken by the change.
• Pen test: Coordinate with an internal or third-party red-team under proper authorization to confirm the vulnerability is closed.

Operational best practices

• Limit device management exposure: keep device management off guest networks and the internet.
• Use centralized configuration management and secure vaults for keys and tokens.
• Rotate session keys and administrative credentials regularly and after suspected compromise.
• Maintain an up-to-date inventory and vulnerability management program linking firmware versions to advisories.

Responsible disclosure and vendor coordination

If you discover sensitive information exposure on Solstice Pod devices in your network, follow your organization’s vulnerability handling policy:

• Document findings, including affected device models and firmware versions. Do not publish exploit details publicly.
• Contact the vendor’s security team (Mersive or your reseller) to report the issue and request remediation guidance.
• Coordinate disclosure and remediation timelines with the vendor; apply vendor-supplied fixes or recommended mitigations as they become available.

Summary

Exposed session keys in unauthenticated API responses are a high-priority risk because they enable further compromise and ease targeted attacks. The defensive approach is straightforward: inventory and segment devices, restrict access to management APIs, require strong authentication, redact sensitive fields server-side, and apply vendor patches. Implement layered controls (network, API gateway, logging/monitoring) and coordinate with the vendor for permanent fixes.

Action	Priority	Notes
Apply vendor firmware update	High	Check vendor advisory for fixed versions
Restrict API access to management network	High	Firewall rules / VLAN segmentation
Implement server-side redaction	High	Use API gateway or middleware to block token leakage
Require authentication and client certs	Medium	Implement RBAC and mutual TLS where supported
Enable monitoring & SIEM alerts	Medium	Detect anomalous API access and leaked fields