CVE-2024-5165 - Critical XSS Vulnerabilities in Eclipse Ditto’s User Interface

Eclipse Ditto is a widely used open-source framework that helps you build digital twins for IoT (Internet of Things) applications. But between versions 3.. and 3.5.5, Ditto’s user interface had dangerous vulnerabilities—reflected and stored Cross-Site Scripting (XSS)—that could let attackers run arbitrary scripts in other people’s browsers.

This post lays out, in plain language, what CVE-2024-5165 is, how it works, and what you need to know about exploitation and protection. The technical details shared here are unique and meant for responsible defenders and developers.

Quick Look: What Is XSS?

Cross-Site Scripting (XSS) lets an attacker inject malicious JavaScript into websites seen by other users. If you use a web app and someone manages to slip <script>alert('Hacked')</script> into it, your web browser runs that code, even if it’s dangerous.

- Reflected XSS: The script comes from what the user just put in, bounced back by the server or UI right away (e.g., search boxes).
- Stored XSS: The script is saved in the system and shown to everyone who opens the page later (e.g., comments or data fields).

Affected Versions

- 3.. up to 3.5.5 (fixed in 3.5.6, see Changelog)

Some user-controlled fields in the Ditto Explorer UI were not safely encoded.

- Reflected XSS: Inputs for search queries and environment settings were saved in browser storage, not the backend. But when the UI loaded them, it didn’t sanitize them.
- Stored XSS: Some properties of “Things” (Ditto’s core data objects) were saved in the backend. If crafted maliciously, these properties would run attacker-supplied JavaScript when viewed by other users.

Official Reference

- Eclipse Ditto User Interface Documentation
- CVE Report

1. Reflected XSS (Local Storage)

Suppose you search for something in the Ditto Explorer UI, and the app remembers your last search in localStorage. If you put in JavaScript (i.e., as part of your search query), and Ditto doesn’t neutralize it before using it in the UI again, your own (or another user's) browser runs that script.

Proof of Concept Code

// In the browser console while on Ditto Explorer UI:
localStorage.setItem("searchQuery", "<img src=x onerror=alert('XSS!')>");

// When Ditto Explorer loads and displays the last search, you'll see the XSS alert.

2. Stored XSS (Backend “Thing” Property)

Authorized users can create or edit “Things” in Ditto, with properties like names or descriptions. If you enter JavaScript as a property and someone else views that Thing in the UI, their browser will run the script.

Attack Example

POST /api/2/things/my.malicious:thing

{
  "features": {
    "details": {
      "properties": {
        "name": "<script>alert('Stored XSS!')</script>"
      }
    }
  }
}

When another user opens Ditto Explorer and views this Thing, the JavaScript pops an alert—or worse, could steal their cookies or session.

Get authorized access: The attacker must have Ditto UI privileges.

2. Insert the payload: For Reflected XSS, manipulate localStorage or relevant fields; for Stored XSS, create/update Things with malicious properties.
3. Trigger execution: The victim loads Ditto Explorer and views the dangerous element (search, environment, Thing with malicious property).
4. Gain user's browser context: Now, the attacker can perform actions using the victim's permissions—possibly to escalate privileges, steal information, or attack others.

What’s the Real-World Risk?

- Reflected XSS: Mostly self-attack unless you socially engineer someone to load data (through export/import of environments or browser profile sharing, for instance).
- Stored XSS: Far more impactful! Any authorized user can attack colleagues or admins who open Ditto Explorer, potentially hijacking their sessions or gathering sensitive data.

Upgrade immediately (≥3.5.6)!

- See the official fix notes.

Code Snippet: How to Safely Render User Input

/* Dangerous: */
element.innerHTML = userInput; // XSS risk

/* Safe: */
element.textContent = userInput; // No HTML interpreted

Or, in Java for the backend

import org.apache.commons.text.StringEscapeUtils;

String safe = StringEscapeUtils.escapeHtml4(userInput);
// Now 'safe' can be displayed without risk.

Conclusion

Eclipse Ditto’s XSS vulnerabilities in CVE-2024-5165 were a real risk. If you run or develop Ditto-based solutions, make sure you’re safe: upgrade your servers and review your code for unsafe input handling. Stored XSS is particularly dangerous as it can let insiders or attackers with basic UI access compromise other users.

For more information
- Eclipse Ditto Release Notes
- Eclipse Ditto Documentation

Timeline

Published on: 05/23/2024 10:15:10 UTC
Last modified on: 06/04/2024 18:02:58 UTC