Opencast: Session Fixation ermöglicht Kontoübernahme über einen präparierten Link

Ein Angreifer setzt über einen präparierten Link eine selbst gewählte Sitzungskennung im Browser des Opfers; da Opencast die Kennung bei der Anmeldung nicht rotiert, übernimmt der Angreifer nach der Anmeldung des Opfers dessen Sitzung, bis hin zur vollständigen Administratorkontrolle.

Advisory-ID: TP-2026-048
Produkt: Opencast (Open-Source-System für die Aufzeichnung, Verwaltung und Auslieferung von Vorlesungs- und Videoinhalten)
Schwachstellentyp: Session Fixation (CWE-384)
CVE: CVE-2026-77614
CVSS 3.1: 8.8 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Hersteller-Advisory: GHSA-6f53-jp7x-gg7p
Betroffene Versionen: opencast < 19.7 und < 20.2 (verifiziert auf 20.0, Docker allinone)
Behoben in: 19.7, 20.2
Gemeldet: 17. Juni 2026

Zusammenfassung

Opencast ist ein Open-Source-System für die Aufzeichnung, Verwaltung und Auslieferung von Vorlesungs- und Videoinhalten. Die Anwendung erneuert die Sitzungskennung JSESSIONID bei der Anmeldung nicht und akzeptiert zusätzlich eine vom Client über den URL-Pfadparameter ;jsessionid= vorgegebene Kennung, die der Server als Set-Cookie in den Browser des Opfers zurückspiegelt. Ein Angreifer sendet dem Opfer einen Link mit einer selbst gewählten Kennung; sobald sich das Opfer in diesem Browser anmeldet, bleibt genau diese Kennung an die authentifizierte Sitzung gebunden. Der Angreifer verwendet dieselbe Kennung ohne Zugangsdaten weiter und reitet die Sitzung des Opfers, bei einem Administrator bis zur vollständigen Kontrolle über den Mandanten. turingpoint hat die Kette live gegen eine laufende Opencast-Instanz (Standard 20.0) verifiziert und an den Hersteller gemeldet, der sie in 19.7 und 20.2 behoben hat.

Ursache

Der Block <sec:http create-session="ifRequired"> in etc/security/mh_default_org.xml:21 wird ohne jedes <sec:session-management>-Element ausgeliefert, sodass keine Rotation der Sitzungskennung stattfindet. Die Authentifizierung läuft über eine eigene CompositeFilter-Kette plus <sec:form-login> (mh_default_org.xml:396), weshalb die Namespace-SessionFixationProtectionStrategy (migrateSession) nicht greift. Der eigene Erfolgs-Handler AuthenticationSuccessHandler.onAuthenticationSuccess (modules/kernel/src/main/java/org/opencastproject/kernel/security/AuthenticationSuccessHandler.java:74) ruft request.getSession() auf, aber kein changeSessionId() oder invalidate(). Das eingebettete Jetty/pax-web hat das jsessionid-URL-Tracking aktiv, nimmt eine über ;jsessionid= gesetzte Kennung an und gibt sie als Set-Cookie: JSESSIONID=… zurück. Der JSESSIONID-Cookie trägt weder Secure noch SameSite, und es gibt keine CSP, sodass ein Cross-Site-Link die Kennung über einfaches HTTP setzen kann.

Proof of Concept

# 1. Opfer klickt einen Link, der eine vom Angreifer gewählte Sitzungskennung setzt:
GET /admin-ui/index.html;jsessionid=ATTACKERVALUE.node0
#   -> 302  Set-Cookie: JSESSIONID=ATTACKERVALUE.node0; Path=/; HttpOnly

# 2. Opfer meldet sich in diesem Browser als Administrator an (keine Rotation der Kennung):
POST /j_spring_security_check      (admin:opencast, Cookie JSESSIONID=ATTACKERVALUE.node0)

# 3. Angreifer verwendet dieselbe Kennung ohne Zugangsdaten:
GET /info/me.json                  Cookie: JSESSIONID=ATTACKERVALUE.node0
#   -> {"user":{"username":"admin"}, "roles":[ROLE_ADMIN,ROLE_SUDO,ROLE_USER_ADMIN,...]}

Der Server bindet die vom Angreifer vorgegebene Kennung und erneuert sie bei der Anmeldung nicht, sodass Vor- und Nach-Login-Kennung identisch bleiben. Weil JSESSIONID allein die Sitzung schlüsselt, greift der Angreifer anschließend mit derselben Kennung auf /info/me.json und /admin-ng/users/users.json als angemeldeter Administrator zu.

Auswirkung

  • Vollständige Übernahme jedes Kontos, dessen Inhaber dem präparierten Link folgt und sich anschließend anmeldet, einschließlich Administratoren (ROLE_ADMIN/ROLE_SUDO).
  • Vollständige Kontrolle über den Opencast-Mandanten: Nutzerverwaltung, alle Medien und Serien sowie Konfiguration.
  • Ausnutzung ohne Zugangsdaten, ohne XSS und ohne MITM; ein angeklickter Link und eine spätere Anmeldung genügen.
  • Begünstigt durch die fehlenden Attribute Secure und SameSite am JSESSIONID-Cookie und die fehlende CSP.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen