CVE-2019-3396

🔎 Wichtige Informationen:

• Betroffenes Produkt: Confluence Server & Data Center

• Betroffene Versionen: von 6.0.0 bis 6.15.4

• Schweregrad: Kritisch (CVSS ~9.8)

• Ursache:

  • Confluence verfügt über das Plugin Widget Connector (zum Einbetten von Videos, externen Inhalten wie YouTube, Vimeo...).

  • Diese Funktion überprüft die Benutzereingaben nicht ausreichend, was zu einer Server-Side Template Injection (SSTI) führt.

  • Ein Angreifer kann eine schädliche Payload senden → Confluence rendert sie mit der Velocity Template Engine → Code wird auf dem Server ausgeführt.

1. Installation und Start der Webseite

• Installiere eine verwundbare Version, z. B. 6.9.0:

https://www.atlassian.com/software/confluence/downloads/binary/atlassian-confluence-6.9.0.zip

• Führe die Einrichtungsschritte gemäß der Anleitung durch:

https://nguyendt.hashnode.dev/confluence-cve-2019-3396

• Nach erfolgreicher Installation erhalten wir die Oberfläche:

2. Suche nach der verwundbaren Stelle und Debugging

2.1 Suche nach der verwundbaren Stelle

• Laut POC befindet sich die fehlerhafte Funktion im Widget Connector (zum Einbetten von Videos, externen Inhalten wie YouTube, Vimeo...)
• Suche nach dieser Funktion:

1. Klicke auf Other macros

2. Suche nach dem Werkzeug Widget Connector

3. Gib einen Link ein und fülle die erforderlichen Informationen aus, wähle dann Preview

2.2 Debugging einrichten

• Da die Beschreibung Widget Connector erwähnt, suchen wir im Quellcode-Ordner von Confluence

• Lese die .jar-Datei mit Intellij IDEA
• Setze Breakpoints an Stellen, die die Linkauflösung verarbeiten, und starte den Debug-Vorgang

Debugging durchführen

• Führe das Debugging durch und setze einen Breakpoint bei com.atlassian.confluence.extra.widgetconnector.WidgetMacro.class
• Hier sehen wir die Parameter
• Aufruf der Klasse DefaultRenderManager.class

• Dort wird die Funktion getEmbeddedHtml() verwendet
• Gibt den HTML-Code zum Einbetten (Embed) externer Inhalte zurück (Videos, Widgets, Dokumente…) basierend auf einer URL, die der Benutzer in die Confluence-Seite eingefügt hat
• Von dort aus wird die Funktion YoutubeRenderer aufgerufen

• Gehe zur Klasse YoutubeRenderer
• In dieser Funktion getEmbeddedHtml(String url, Map<String, String> params)
• url → die ursprüngliche YouTube-URL, die der Benutzer eingegeben hat
• params → eine Map mit Konfigurationsparametern für das Rendering (z. B. Breite, Höhe, verwendete Vorlage …)

• Weiterer Aufruf von getEmbedUrl(), setDefaultParam() und DefaultVelocityRenderService.render()
• Konzentriere dich auf setDefaultParam()

• Wenn _template noch nicht vorhanden ist → wird die Standardvorlage youtube.vm zugewiesen. => Man kann _template manuell zum Programm hinzufügen

• Als nächstes: DefaultVelocityRenderService.render()

1. Zweck der Funktion

   • Nimmt url + Parameter params entgegen.
   • Verwendet eine Velocity-Vorlage (.vm), um eingebettetes HTML (iframe, embed, …) zu rendern.

2. Vorlagenauswahl

   • Wenn params _template enthält → diese Vorlage verwenden.
   • Andernfalls → Standardvorlage embed.vm.

3. Erstelle den Standardkontext mit MacroUtils.defaultVelocityContext().

• Füge alle Parameter aus params in den Kontext ein:

  • Wenn Schlüssel = tweetHtml → HTML unverändert lassen.
  • Sonst → sicher mit GeneralUtil.htmlEncode() kodieren.

• Füge urlHtml, width, height zum Kontext hinzu (falls leer, Standardwerte 400 × 300 setzen).

• Aufruf von VelocityUtils.getRenderedTemplate()

• Nun wechseln wir zur Klasse VelocityUtils
• Oben wird getRenderedTemplate und getRenderedTemplateWithoutSwallowingErrors() aufgerufen

• Danach wird getTemplate() aufgerufen

• Hier ist templateName gleich dem obigen _template.

• Dann wird VelocityEngine.Template() aufgerufen

• In der Klasse VelocityEngine wird weiter RunimeInstance.getTemplate() aufgerufen

RuntimeInstance (Velocity-Kern)
Dies ist das „Herz“ der Velocity Engine. Es kümmert sich um:

• Initialisierung der Engine (init)

• Verwaltung von Konfiguration, Makros, Parser, Direktiven, Ereignisbehandlern …

• Und insbesondere: Ressourcenverwaltung über ResourceManager

→ Das bedeutet, dass RuntimeInstance Ressourcen nicht selbst lädt, sondern an den resourceManager delegiert.

• Dann wird CompatibleVelocityResourceManager.getResource() aufgerufen

ConfigurableResourceManager (Confluence custom)
Dies ist eine Implementierung des Interfaces ResourceManager.
Es ist verantwortlich für:

• Verwaltung der Resource-Loader (File Loader, Classpath Loader, URL Loader …).

• Verwaltung des globalCache (Cache für Vorlagen nach resourceKey).

• Laden/Aktualisieren von Vorlagen (.vm-Dateien), wenn von RuntimeInstance angefordert.

try {
    this.refreshResource(resource, encoding);
} catch (ResourceNotFoundException var7) {
    this.globalCache.remove(resourceKey);
    return this.getResource(resourceName, resourceType, encoding);
}

• Wenn eine Ressource im Cache vorhanden ist, wird sie nicht sofort zurückgegeben, sondern es wird refreshResource(...) aufgerufen.

• refreshResource vergleicht den letzten Änderungszeitpunkt (lastModified) auf der Festplatte mit dem im Cache.

• Wenn die Datei geändert wurde → wird die Ressource im Cache ungültig → neu von der Festplatte geladen → Cache aktualisiert.