1.Zusammenfassung

ILIAS bietet eine SOAP-Schnittstelle, über die andere Systeme Objekte anlegen können – unter anderem Dateien. Beim Anlegen wird eine XML-Beschreibung übergeben, die neben Titel und Beschreibung auch angeben kann, dass der Inhalt aus einer bereits auf dem Server liegenden Datei übernommen werden soll. Für einen Import, bei dem zuvor ein Archiv entpackt wurde, ist das sinnvoll.

Damit diese Angabe harmlos bleibt, muss sie gegen ein festgelegtes Basisverzeichnis aufgelöst werden – eben jenes Verzeichnis, in das der Import entpackt wurde. Genau das unterblieb auf dem SOAP-Weg: Ein Basisverzeichnis wurde nie gesetzt. Die Auflösung erfolgte daher gegen einen leeren Wert, und was als relative Angabe gedacht war, wurde dadurch zu einem absoluten Pfad.

Die Anwendung öffnete die so bezeichnete Datei und legte deren Inhalt als reguläres Dateiobjekt im Zielcontainer ab. Von dort ließ er sich über dieselbe Schnittstelle wieder abrufen. Im Ergebnis konnte ein angemeldeter Aufrufer beliebige Dateien lesen, auf die der Webserver Zugriff hat.

Voraussetzung war ein angemeldetes Konto mit dem Recht, in einem einzigen beliebigen Container eine Datei anzulegen. Das ist keine besondere Berechtigung – sie liegt in vielen Installationen bei gewöhnlichen Mitgliedern oder Tutoren. Ein Administrationszugang war nicht erforderlich.

2.Betroffene Systeme

Betroffen waren alle zum Zeitpunkt der Meldung gepflegten Versionslinien, einschließlich der jeweils aktuellen Stände. Die Korrektur ist erst mit der Release-Runde vom 12.08.2026 erschienen.

Betroffenheit je Versionslinie und der jeweils behebende Stand
Versionslinie Betroffen Behoben in
ILIAS 9 alle Stände vor 9.22 9.22
ILIAS 10 alle Stände vor 10.10 10.10
ILIAS 11 alle Stände vor 11.3 11.3

Über die Version hinaus ist für die eigene Einschätzung relevant, ob die SOAP-Schnittstelle in der Installation überhaupt aktiviert und erreichbar ist. Wo sie abgeschaltet oder auf bekannte Gegenstellen begrenzt ist, war der beschriebene Weg nicht nutzbar. Das ist eine Eigenschaft der Konfiguration und kein Ersatz für das Update.

3.Technische Analyse

Voraussetzungen. Ein angemeldetes Konto mit dem Recht, in einem einzigen beliebigen Container eine Datei anzulegen, sowie eine erreichbare SOAP-Schnittstelle. Keine Administrationsrechte, keine Nutzerinteraktion auf der Gegenseite.

Der Befund liegt nicht in einer fehlerhaften Prüfung, sondern in einer fehlenden Voraussetzung. Der Datei-Import ist für einen Ablauf gebaut, bei dem zuvor ein Archiv in ein temporäres Verzeichnis entpackt wurde. Dieses Verzeichnis wird dem Import als Basis mitgegeben, und alle Pfadangaben im XML werden relativ dazu aufgelöst. Solange das geschieht, ist der Mechanismus in Ordnung.

Die Kette

  1. Der Einstieg prüft nur die Rechte, nicht den Inhalt Die SOAP-Methode zum Anlegen einer Datei prüft die Sitzung und das Recht, im angegebenen Zielcontainer eine Datei zu erzeugen. Die übergebene XML-Beschreibung selbst unterliegt keiner Einschränkung.
  2. Das Basisverzeichnis bleibt ungesetzt Der Parser für die Dateibeschreibung kennt ein Basisverzeichnis für Pfadangaben, das standardmäßig leer ist. Auf dem SOAP-Weg wird es nie gesetzt – anders als bei den Importwegen, für die der Mechanismus gedacht ist.
  3. Aus relativ wird absolut Der Zielpfad entsteht durch Zusammensetzen von Basisverzeichnis, Trennzeichen und Angabe. Ist die Basis leer, beginnt das Ergebnis mit dem Trennzeichen – und damit an der Wurzel des Dateisystems. Die vorhandene Bereinigung der Angabe entschärft Rücksprünge im Pfad, ändert an diesem Umstand aber nichts.
  4. Der Inhalt wird zu einem regulären Objekt Die Anwendung öffnet den Pfad und übernimmt die Bytes in ein neu angelegtes Dateiobjekt im Zielcontainer – mit allen Eigenschaften einer regulär hochgeladenen Datei, einschließlich der Möglichkeit, sie wieder abzurufen.

Warum eine Pfadbereinigung hier nicht genügt

Der übliche Reflex gegen Pfadangaben von außen ist, Rücksprünge wie ../ zu entfernen. Das schützt jedoch nur, solange es eine Basis gibt, aus der man nicht herausspringen soll. Fehlt die Basis, ist nichts einzugrenzen: Jede Angabe wird von der Wurzel aus gelesen, ganz ohne Rücksprung. Wirksam ist an dieser Stelle nur, den Pfad nach dem Zusammensetzen gegen ein festgelegtes Verzeichnis zu prüfen – und den Vorgang abzubrechen, wenn er außerhalb liegt.

Zurückgehalten

Dieses Advisory zeigt weder die XML-Beschreibung, mit der sich der Vorgang auslösen ließ, noch die Abfolge der Aufrufe, noch die Pfade, die im Test gelesen wurden. Die Ursache ist auch ohne diese Angaben vollständig beschrieben; für Betreiber ändert sich durch sie nichts, für einen Angreifer gegen eine nicht aktualisierte Instanz sehr wohl.

4.Auswirkung (Impact)

Lesbar war alles, worauf der Benutzer des Webservers Zugriff hat. Das umfasst die Konfigurationsdateien der Anwendung selbst – und damit unter anderem den Pfad zur Dateiablage, die Zugangsdaten zur Datenbank und den hinterlegten Prüfwert des Setup-Passworts. Ebenso betroffen sind hochgeladene Inhalte anderer Kurse, auf die der Aufrufer über die Oberfläche keinen Zugriff hätte, sowie Dateien des Betriebssystems, soweit sie für den Webserver lesbar sind.

Bemerkenswert ist die Verkettung mit den Berechtigungen der Anwendung: Wer die Konfiguration lesen kann, kennt den Ablageort sämtlicher hochgeladener Dateien. Damit wird aus dem Lesezugriff auf einzelne Pfade ein Zugriff auf den gesamten Dokumentenbestand der Instanz – ohne dass dafür je ein Recht in der Anwendung nötig gewesen wäre.

Der Vorgang hinterlässt allerdings Spuren: Jede ausgelesene Datei entsteht als reguläres Objekt im Zielcontainer und ist dort sichtbar, solange sie nicht wieder entfernt wird. Das ist für die Auswertung im Nachhinein der wichtigste Punkt – siehe Abschnitt 5.

Warum hier keine eigene CVSS-Einstufung steht

Für die anderen Befunde dieser Reihe habe ich einen eigenen Score mit vollständigem Vektor angegeben, weil er nachrechenbar ist. Hier lasse ich ihn bewusst offen. Die Auswirkung hängt fast vollständig davon ab, was der Webserver-Benutzer in der jeweiligen Installation lesen darf – das reicht von „die Konfiguration der Anwendung“ bis zu „praktisch alles, was auf dem System liegt“, je nach Rechtevergabe und Betriebsumgebung. Eine einzelne Zahl würde diese Spannbreite eher verdecken als abbilden.

Für die Priorisierung ist ohnehin der Satz unten entscheidender als ein Score: Es genügt ein gewöhnliches Konto, und was am Ende herauskommt, entscheidet Ihre Serverkonfiguration – nicht die Anwendung.

Auswirkung in einem Satz: Lesezugriff auf beliebige für den Webserver erreichbare Dateien – einschließlich der Anwendungskonfiguration und aller hochgeladenen Inhalte – für jedes Konto, das irgendwo eine Datei anlegen darf.

5.Gegenmaßnahmen / Workarounds

Update

Die maßgebliche und einzige vollständige Maßnahme ist das Update auf ILIAS 9.22, 10.10 oder 11.3. Die Versionen wurden am 12.08.2026 bereitgestellt und enthalten neben dieser Korrektur weitere Sicherheitsbehebungen.

Überbrückung, wenn nicht sofort aktualisiert werden kann

  • SOAP-Schnittstelle abschalten oder eingrenzen. Viele Installationen nutzen sie überhaupt nicht. Wo sie gebraucht wird, lässt sich der Zugriff am vorgelagerten Webserver auf die Adressen der bekannten Gegenstellen begrenzen. Das ist die wirksamste Sofortmaßnahme.
  • Dateirechte auf dem Server durchsehen. Der Webserver-Benutzer sollte die Konfigurationsdateien der Anwendung lesen können – aber möglichst wenig darüber hinaus. Diese Härtung wirkt unabhängig von diesem Befund.
  • Zugangsdaten erneuern. Wenn die Konfiguration ausgelesen worden sein könnte, sind die dort hinterlegten Geheimnisse als kompromittiert zu behandeln – Datenbankzugang und Setup-Passwort zuerst.

Prüfung auf zurückliegende Ausnutzung

Anders als bei vielen Lesezugriffen bleibt hier etwas zurück, und das macht die Nachprüfung ungewöhnlich aussichtsreich:

  • Dateiobjekte mit auffälligem Inhalt. Jede so ausgelesene Datei wurde als reguläres Objekt in einem Container angelegt. Konfigurationsdateien oder Systemdateien, die als Kursmaterial auftauchen, sind ein eindeutiger Befund.
  • Zugriffe auf die SOAP-Schnittstelle in den Protokollen des Webservers – insbesondere von Adressen, die nicht zu den bekannten angebundenen Systemen gehören.
  • Kurz nacheinander angelegte und wieder gelöschte Dateiobjekte, soweit sich das aus Protokolldaten oder dem Papierkorb rekonstruieren lässt.

Ergibt sich ein begründeter Verdacht, sollten die in der Konfiguration hinterlegten Zugangsdaten erneuert und die Sitzungen invalidiert werden.

6.Disclosure-Timeline

  1. Identifikation und Meldung an den Hersteller Mantis 0048009
  2. Patch durch den Hersteller ILIAS 9.22, 10.10 und 11.3
  3. Veröffentlichung dieses Advisories

7.Referenzen

Rückfragen zu diesem Advisory

Fragen richten Sie bitte an security@schweigertit.de, gerne verschlüsselt. Proof-of-Concept-Code gebe ich auch auf Anfrage nicht heraus.