[0day-rubbish] Lightstreamer Server 7.4.8 Shipped placeholder JMX/RMI credentials plus MLet remote class loading to root RCE (9.8)

[disclosure via Fulldisclosure <fulldisclosure () seclists org>]

0day Rubbish Research Team is publicly disclosing a vulnerability in
Lightstreamer Server 7.4.8 build 3506 ENTERPRISE (with JMS Extender 2.1.0).

Type: a hard-coded placeholder credential shipped in the distribution
(user_changeme / password_changeme) authenticating a cleartext RMI management
connector on TCP 8888 bound to every interface; because the connector exposes
createMBean, an attacker registers javax.management.loading.MLet and calls
getMBeansFromURL against an origin they control, and the loaded MBean's
constructor runs Runtime.exec (CWE-798, CWE-319)

Scoring. This finding is dual-scored because remote reach depends on the
shipped placeholder being left unchanged. Both figures are published:
- PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This
  applies with the shipped placeholder credential unchanged, which is how the
  distribution archive delivers it (byte-identical to the deployed file, with no
  documented first-login rotation gate).
- CONDITIONAL, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. This
  applies where an operator has rotated the credential but createMBean and MLet
  remain exposed: the step then needs a genuinely privileged account.

Impact: arbitrary command execution as the broker process user, which was root
in the tested deployment. Configuration, TLS material and keystores, streamed
application data and any other credential configured in lightstreamer_conf.xml
are all reachable; the payload MBean stays registered for the JVM lifetime as a
persistent command channel.

Authentication: none beyond the shipped placeholder pair (empty and wrong
credentials were both rejected with SecurityException, so the defect is the
credential's provenance, not a bypassable check).

Verification boundary, stated plainly. We verified the chain end to end over
loopback against a broker unpacked from the distribution archive and started as
root, with the attacker HTTP origin simulated on the same research host: four
runs (three against the jmxrmi platform MBean server, one against the lsjmx
application MBean server), an out-of-band HTTP access log proving a uniquely
named JAR was really fetched rather than cached, runCmd returning uid=0(root)
and a root-owned proof file. Remote cross-network reach is an assessment of the
shipped bind topology (TCP 8888 binds 0.0.0.0 because <listening_interface> is
commented out, with no host firewall rule dropping it), not an observed attack
crossing a network boundary. The one genuine precondition is that the operator
has not replaced the shipped placeholder pair.

This is a distinct defect from the separate unauthenticated jvmtiAgentLoad
primitive we are disclosing in the same product; it reaches code execution via
remote Java class loading rather than a native agent load.

Full technical analysis and a reproducible proof-of-concept:
  https://0day-rubbish.com/blog/lightstreamer-default-creds-jmx-rmi-mlet-rce

Project archive (ongoing disclosure series):
  https://github.com/Exploit-Garbage/0day-Rubbish

The vendor has been notified through its published security contact. No vulnerability identifier has been assigned to
this finding yet.

--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/