Confluence CVE-2022-26134

Eigentlich kümmere ich mich auf der MSXFAQ primär um Windows und Exchange-Lücken, von denen es durchaus genug gibt, z.B. siehe Hafnium Exploit. Andere Produkte haben aber auch ihre Probleme und in dem Fall war eine Confluence-Installation betroffen, die aus dem Internet erreichbar war. Auslöser war eine entsprechende Sicherheitsmeldung einer Firma auf ihrer Webseite.

Öffentliche Meldung

Um nicht den Eindruck von Schadenfreude oder Geschäftsschädigung zu erwecken, haben ich den Namen der Firma nicht öffentlich gemacht. Hinsichtlich der Kurzauswertung macht dies keinen Unterschied.

Im Februar 2023 war die Firma einem Sicherheitsvorfall betroffen und hat diesen auf ihrer News-Seite veröffentlicht. So unangenehm solche Pflichtmeldungen für Firmen erst einmal sind, so wichtig ist ein offener Umfang mit den Fehlern, damit möglichst viele andere Firmen sensibilisiert werden. Auch wenn ich zu keiner Zeit in den Vorfall selbst involviert war, so sind die öffentlich zugänglichen Informationen immer auch eine Prüfung, ob das der eigenen Firma auch passieren könnte. So ein Incident muss ja nicht einmal eine "Schuld" der betroffenen Firma sein, insbesondere wenn eine so genannte "Zero-Day-Lücke" ausgenutzt wird. Aus der Meldung vom 9.3.2023 auf https://www.xxxxxxx.de/de/news/news/index.jsp lese ich mehrere Informationen:

  • 11. Januar 2023 Einbruch erkannt
    Es wird zwar nicht genauer spezifiziert, wie der Einbruch erkannt wurde, aber irgendwann werden die Angreifer ja ihr Ziel verfolgen und dazu müssen Sie etwas ändern, z.B. Datenmengen ausleiten oder Dateien verändern, Hintertüren anlegen etc. Das kann erkannt werden und ist hier vermutlich erfolgt. Laut Betreiber erfolgte der Einbruch schon im Mai 2022.

Lernkurve:
Wer keine Kennzahlen seiner Server und Netzwerke erfasst, kann Veränderungen nicht erkennen. Würden Sie "Veränderungen" an Installationen, z.B. geänderte Funktionsumfänge, neu dazugekommener Code o.ä. erkennen? Nur zur Erinnerung. Welcher Server (außer Windows Updates) installiert der ändert ohne Zutun eines Administrators Programme?

  • 2. Feb 2023 erste öffentliche Meldung
    Anscheinend waren die Veränderungen "extern" nicht zu bemerken. Mir ist nicht bekannt, dass die reguläre Webseite nicht erreichbar oder die Mailkommunikation eingeschränkt war. Daher dürfte man sich etwas mehr Zeit genommen haben, um den Umfang zu analysieren und Gegenmaßnahmen einzuleiten. Gehen wir einmal davon aus, dass die üblichen Pflichtmitteilungen erfolgt sind.

Lernkurve:
Haben Sie sich selbst einmal gefragt, wo und wie sie eine solche Meldung bereitstellen, wenn Sie selbst betroffen sind und ihr Internet gerade mal "down" ist?

  • Angriffsvektor CVE-2022-26134
    Die Firma führt die Confluence-Lücke CVE-2022-26134 als Root-Cause auf. Dieses Lücke wurde vom Hersteller im Juni 2022 korrigiert. Wir gehen davon aus, dass die Firma ihre Server zeitnah patched und sie spricht selbst von einem Zero-Day-Angriff, was auf ein sehr zeitnahes Update hinweisen könnte. Dennoch wurde die Instanz kompromittiert.
  • Angriff vor Verfügbarkeit eines Patch
    Das bedeutet im Umkehrschluss natürlich, dass der Angriff schon vor der Verfügbarkeit des Patches im Juni 2022 erfolgt ist. Laut Betreiber erfolgte der Angriff schon im Mai 2023. Das bedeutet aber auch, dass der Angreifer sich bis Jan 2023 ca. 7 Monate verdeckt und unbemerkt auf dem System bewegen konnten.

Lernkurve:
Es kann durchaus sein, dass ein Einbruch monatelang unentdeckt bleibt. Bedenken Sie dies bei ihrer Datensicherungen. Großvater, Vater, Sohn oder ein paar VSS-Kopien könnte zu wenig sein sein.

  • Logdateien
    Aus der Aussage zur Ausnutzung einer Zero-Day-Lücke vor mehr als 7 Monate in der Vergangenheit liegt, folgere ich dass auch Protokolldateien aus dem Zeitraum vorhanden sind. Die Veränderungen durch die Installation von Plugins auf dem System lassen sich so am einfachsten nachweisen. Das "Dateidatum" eines Plugins auf der der Festplatte kann ein Angreifer sonst auch einfach ändern. Eventuell wurde auch ein Vergleich von Ist-Stand mit den Datensicherungen genutzt, um den Zeitpunkt zu ermitteln.

Lernkurve: 30 Tage Haltezeit für Protokolle ist nicht immer ausreichend. Hier müssen Sie natürlich Datenschutzvorschriften mit ihrem Schutzbedarf abwägen. Exchange löscht das Messagetracking normalerweise nach 60 Tagen, das Windows Eventlog überschreibt alte Events beim Erreichen des Speicherplatzlimits pro Eventlog. Der IIS löscht automatisch z.B. keine Webserver-Logs. Da "böse Buben und Mädels" aber auch Logfiles löschen könnten, sollten Sie über einen Loghost nachdenken, an den solche Protokolle gesendet werden.
Auch im Microsoft 365 werden Auditlogs/Signinlogs nur 30 Tage aufbewahrt. Sie können diese z.B. nach Azure Sentinel o.ä. überführen, um diese länger zu behalten.

  • Erfolgreiche Angriffe auf andere Systeme im Netzwerk
    Wenn Code auf einem Confluence Server so weitreichende Rechte hat, dass er auch andere Server im LAN angreifen kann, dann sollten alle Alarmglocken schrillen. Ich hoffe, dass die anderen Server irgendwas mit Confluence zu tun hatten, z.B. BackendServer zur Datenablage oder Authentifizierungsserver. Wobei dann schon zu hinterfragen ist, mit welchen Berechtigungen so ein Dienst läuft und wie streng die Netzwerkverbindungen kontrolliert werden.

Lernkurve: Ich kenne das Rechtemodell von Confluence nicht, aber eine normale Webanwendung auf einem Server sollte mit minimalen Berechtigungen laufen. Wer seine Server nach Anwendungen in verschiedene VLANs separiert, braucht zwar mehr Subnetze und einen Router mit Paketfilter oder gleich eine Firewall. So können Sie aber besser verhindern, dass es keine Querkommunikation gibt. Vertrauen Sie nie darauf, dass ein Server ohne Internet-Zugriff automatisch sicher ist. Übrigens gilt das auch für die Personen, die sich auf so einem kompromittierten Server anmelden. Das sollten Sie vielleicht nicht als "DomainAdmin" machen, so dass die Malware das Kennwort mitschneidet oder sich ein Golden/Silver-Ticket aus dem Kerberos-Speicher besorgt. Auch sollten natürlich keine Kennwort in einem Skript oder Tresor stehen.

Hier beende ich die Interpretation der öffentlichen Sicherheitswarnung und bedanke mich bei der Firma für die bereitgestellten Informationen.

Keine Infos zu

Die Pressemitteilung beschreibt einige Dinge aber schweigt sich auch über Details aus.

  • Keine Preauthentication
    Anscheinend wurde die Confluence-Instanz direkt mit dem Internet über Port 443 verbunden. Ein Reverse Proxy davor oder eine Firewall hat die Verbindungen eventuell umgesetzt aber keine Authentifizierung erzwungen. Es ist heute relativ einfach möglich, dass ein Loadbalancer oder auch ein Azure AD Application Proxy vom Anwender erst eine Anmeldung abfordert. Damit werden zumindest die Lücken gesichert, über die jemand anonym einen Service kapern kann. Das gelingt natürlich nicht, wenn der Service nicht die Daten einer Preauthentication weiter verarbeiten kann und der Anwender sich dann doppelt anmelden müsste.
  • Keine Suche nach dem Patch
    Wenn es ein Zero-Day war und der Betreiber den Patch von Confluence zeitnah installiert hat, dann sollte man auch die Logfiles und das System auf Einbruchsspuren untersuchen. Solange zu den Exploit noch nicht alle Informationen vorliegen, ist das vielleicht nicht vollständig aber dann wiederholt man den Check immer mal wieder. Microsoft hat es bei Hafnium u.a. vorgemacht, wie man die IISLogs auf Treffer zur Lücke durchsucht und so versuchte und insbesondere erfolgreiche Einbrüche erkennen kann. Darüber ist in der Veröffentlichung nichts zu finden aber wenn die Confluence-Instanz schon vor dem Patch korrumpiert war, dann sollte es nicht 7 Monate dauern, bis dies auffällt.
  • VPN zu angebundene Kunden
    Ich weiß nicht, ob diese Firma auch VPN-Verbindungen zu Kunden und Lieferanten hat. Das ist gar nicht mal zu unwahrscheinlich.

Lernkurve: Ein Einbruch bleibt selten auf ein System beschränkt. Wenn Firmen per VPN verbunden sind, dann sollten sie die andere Seite nicht als "trusted" ansehen, sondern nur erforderlich Verbindungen zulassen. Das gilt übrigens auch für ein VPN-Tunnel von einem On-Premises Netzwerk z.B.: zu einem Azure-Netzwerk oder anderen Cloud-Anbietern.

Prävention

Ich bin immer wieder überrascht, wie viele Produkte darauf setzen, dass der ausgeführte Code sich selbst verändern kann. Wenn Sie einen klassischen Windows Desktop anschauen, auf dem ein Administrator z.B.: Office in C:\Programme\Office installiert, dann ist es vollkommen normal, dass ein Benutzer keine Schreibrechte in diesem Verzeichnis hat.

Bei Webservern scheint sich das noch nicht rumgesprochen zu haben, dass der Webserver auch mit einem beschränkten User arbeiten könnte. Wenn ein fehlerhafter Code eines IIS oder Apache gar nicht erst in das "wwwroot"-Verzeichnis schreiben dürfte, dann wäre es deutlich schwerer so eine Hintertür zu installieren.

Aber ich weiß auch, das z.B. Wordpress auch ein "Selbstupdate" ausführen kann und die anwenderfreundliche Installation von Addons über die Webseite ist natürlich bequem. Wie viel aufwändiger wäre da doch die Installation über eine Remote Shell oder durch FTP-Upload. Aber es ist dann halt auch unsicherer.

Die MSXFAQ nutzt statische Seiten, die ich über einen FTP-Account schreiben kann.

Sie können also schon an einigen Hebeln drehen, um ihr System sicherer zu betreiben. Eine öffentliche "Security Meldung" mit einigen Details erlaubt durchaus Rückschlüsse auf den Vorfall und vor allem eine Prüfung der eigenen Umgebung, wie gut Sie sich zu Wehr gesetzt hätten.

CVE-2022-26134

Zur Lücke selbst gibt es nicht viel mehr zu schreiben. Über den Code "CVE-2022-26134" finden wir ganz schnell die entsprechenden Hinweise auf die Lücken, wer sie entdeckt und dokumentiert hat, wann der Hersteller einen Patch bereitgestellt hat. Es ist ein anonymer HTTP-Request gegen den Server. Zur Lesbarkeit habe ich die URL-Codierung des Pfads entfernt:

https://<confluenceserver>/${
                               (#a=@org.apache.commons.io.IOUtils@toString
                                  (@java.lang.Runtime@getRuntime().exec(
                                        "'+optionsOpt.command+'"
                                     ).getInputStream(),"utf-8"
                                  )
                               ).
                               (@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader("X-Cmd-Response",#a))
                            }/

Ich bin kein Confluence-Fachmann, um die gültigen URLs zu erkennen. aber ein ".exec(" in einer URL könnte recht einfach ausgeschlossen werden. Die Lücke wurde am wohl 2.6.2022 an Confluence gemeldet und schon am 3. Jun 2022 wurde eine Regel für eine Web Application Firewall veröffentlich um dann sehr schnell durch neuere Versionen ersetzt zu werden. Das Verfahren erinnert an Microsoft, wo auch in sehr kurzen Abständen immer wieder die Vorgehensweisen aktualisiert wurden.

Ich bin nun nur nicht sicher, ob der Zeitstempel "Date Record Created 202202252" von https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26134 ein Tippfehler ist oder ich "20220225" nur falsch als 25. Feb 2022 interpretiere. Wenn dann wäre die Lücke schon 5 Monate vor dem Patch durch Confluence bekannt gewesen.

Weitere Links