STiNE-Sicherheitslücken: Unterschied zwischen den Versionen

Aus Fachschaft_Informatik
Zur Navigation springen Zur Suche springen
K (+kat)
K (dewiki)
Zeile 15: Zeile 15:
 
* 10.10.2006: Datenlotsen benachrichtigt.
 
* 10.10.2006: Datenlotsen benachrichtigt.
  
= Cross-Site-Scripting beim Anzeigen von [[STiNE]]-Nachrichten =
+
= Cross-Site-Scripting beim Anzeigen von STiNE-Nachrichten =
  
Beim Verfassen einer [[STiNE]]-Nachricht konnte man beliebigen HTML-Code in die Nachricht einbetten,
+
Beim Verfassen einer STiNE-Nachricht konnte man beliebigen HTML-Code in die Nachricht einbetten,
 
der 1:1 im Browser des Empfängers angezeigt wurde.
 
der 1:1 im Browser des Empfängers angezeigt wurde.
  
Zeile 26: Zeile 26:
 
* 17.10.2006: Details angehängt
 
* 17.10.2006: Details angehängt
  
= Unbeabsichtigte Einsicht in [[STiNE]]-Nachrichten beliebiger Benutzer =
+
= Unbeabsichtigte Einsicht in STiNE-Nachrichten beliebiger Benutzer =
  
 
Im [[STiNE-Modul MESSDETAIL]] konnte man einfach die Nachrichten-ID auf einen beliebigen Wert setzen, und wenn die Nachricht vorhanden war, wurde sie angezeigt, egal, ob sie für den gerade angemeldeten Benutzer bestimmt war.
 
Im [[STiNE-Modul MESSDETAIL]] konnte man einfach die Nachrichten-ID auf einen beliebigen Wert setzen, und wenn die Nachricht vorhanden war, wurde sie angezeigt, egal, ob sie für den gerade angemeldeten Benutzer bestimmt war.
Zeile 32: Zeile 32:
 
Verlauf:
 
Verlauf:
 
* 10.10.2006: Lücke entdeckt.
 
* 10.10.2006: Lücke entdeckt.
* irgendwann dazwischen: [[STiNE]]-Projektleitung benachrichtigt (mündlich, vielleicht auch schriftlich).
+
* irgendwann dazwischen: STiNE-Projektleitung benachrichtigt (mündlich, vielleicht auch schriftlich).
 
* 17.10.2006: Die Sicherheitslücke ist behoben.
 
* 17.10.2006: Die Sicherheitslücke ist behoben.
 
* 18.10.2006: Details veröffentlicht.
 
* 18.10.2006: Details veröffentlicht.
Zeile 38: Zeile 38:
 
= Und so weiter ... =
 
= Und so weiter ... =
  
Das ist bei weitem nicht alles. Ohne große Anstrengung kann man mit wenig Fachwissen jede Menge weiterer Sicherheitslücken finden. Der umfassende Datenschutz, der in der [[STiNE]]-FAQ (http://www.info.stine.uni-hamburg.de/stud_faq.html) angepriesen wird, ist bei weitem nicht eingehalten. [16.10.2006]
+
Das ist bei weitem nicht alles. Ohne große Anstrengung kann man mit wenig Fachwissen jede Menge weiterer Sicherheitslücken finden. Der umfassende Datenschutz, der in der [http://www.info.stine.uni-hamburg.de/stud_faq.html STiNE-FAQ] angepriesen wird, ist bei weitem nicht eingehalten. [16.10.2006]
  
 
Es macht allerdings den Eindruck, als ob die Datenlotsen jetzt erkannt haben, dass Softwaresicherheit wichtig ist (siehe auch [[STiNE-Tagebuch]]).
 
Es macht allerdings den Eindruck, als ob die Datenlotsen jetzt erkannt haben, dass Softwaresicherheit wichtig ist (siehe auch [[STiNE-Tagebuch]]).
Zeile 44: Zeile 44:
 
= ... und so weiter ... =
 
= ... und so weiter ... =
  
Übrigens machen nicht nur die Datenlotsen so schlechte Software. Die Firma [http://www.magicsoftware.com/ Magic Software], auf deren Middleware [[STiNE]] aufbaut, weiß auch noch nicht, was SQL-Injections sind, wie deren Entwicklerdoku zu <nowiki>eDeveloper</nowiki> beweist. (Update vom 22.05.2007: Das scheint mittlerweile behoben zu sein. --[[Roland Illig]])
+
Übrigens machen nicht nur die Datenlotsen so schlechte Software. Die Firma [http://www.magicsoftware.com/ Magic Software], auf deren Middleware STiNE aufbaut, weiß auch noch nicht, was SQL-Injections sind, wie deren Entwicklerdoku zu eDeveloper beweist. (Update vom 22.05.2007: Das scheint mittlerweile behoben zu sein. --[[Roland Illig]])
  
 
= Unberechtigter Zugriff auf personenbezogene Dokumente =
 
= Unberechtigter Zugriff auf personenbezogene Dokumente =
  
Durch gezieltes Raten ist es einem Angreifer möglich, auf die persönlichen Dokumente (zur Zeit Semesterbescheinigungen und Studienbuch) anderer [[STiNE]]-Benutzer zuzugreifen. Das funktioniert im Prinzip wie damals mit den [[STiNE]]-Nachrichten, nur dass die Dokumenten-IDs jetzt nicht mehr fortlaufend numeriert sind.
+
Durch gezieltes Raten ist es einem Angreifer möglich, auf die persönlichen Dokumente (zur Zeit Semesterbescheinigungen und Studienbuch) anderer STiNE-Benutzer zuzugreifen. Das funktioniert im Prinzip wie damals mit den STiNE-Nachrichten, nur dass die Dokumenten-IDs jetzt nicht mehr fortlaufend numeriert sind.
  
 
Verlauf:
 
Verlauf:
Zeile 57: Zeile 57:
  
 
== Details ==
 
== Details ==
Das Herunterladen von Dateien, die von [[STiNE]] verwaltet werden, geschieht nicht innerhalb von Magic, sondern mit einem externen Programm (filetransfer.dll). Das bekommt die folgenden Parameter:
+
Das Herunterladen von Dateien, die von STiNE verwaltet werden, geschieht nicht innerhalb von Magic, sondern mit einem externen Programm (filetransfer.dll). Das bekommt die folgenden Parameter:
* [[PATH_INFO]]: "download" oder "upload" (wie letzteres geht, weiß ich allerdings noch nicht. ;))
+
* PATH_INFO: "download" oder "upload" (wie letzteres geht, weiß ich allerdings noch nicht. ;))
 
* session: Die Session-ID
 
* session: Die Session-ID
 
* fnsrc: Der Name der Datei auf dem Server
 
* fnsrc: Der Name der Datei auf dem Server
Zeile 64: Zeile 64:
 
* subdir: Das Verzeichnis, aus dem die Datei kommt. Mir wurde gesagt, dass es sich hierbei um "logische" Verzeichnisse handelt, so dass Angriffe der Form "subdir=../../../.." zwecklos seien.
 
* subdir: Das Verzeichnis, aus dem die Datei kommt. Mir wurde gesagt, dass es sich hierbei um "logische" Verzeichnisse handelt, so dass Angriffe der Form "subdir=../../../.." zwecklos seien.
  
Das Problem war nun, dass die Session-ID anscheinend garnicht überprüft wurde, denn man konnte die Dokumente auch herunterladen, wenn die Session-ID 0 war. Die Folge davon war, dass man die Datei auch noch herunterladen konnte, nachdem man ausgeloggt war, wenn man nur die URL kannte. Und selbst wenn man die URL nicht kannte, konnte man doch durch "gezieltes Raten" versuchen, an Dokumente heranzukommen, wenn man den ungefähren Zeitpunkt kannte, zu dem das Dokument in [[STiNE]] erzeugt wurde. Denn danach richtet sich der Dateiname fnsrc, der die Form "f" + [[STiNE]]-ID + ".cache" hat.
+
Das Problem war nun, dass die Session-ID anscheinend garnicht überprüft wurde, denn man konnte die Dokumente auch herunterladen, wenn die Session-ID 0 war. Die Folge davon war, dass man die Datei auch noch herunterladen konnte, nachdem man ausgeloggt war, wenn man nur die URL kannte. Und selbst wenn man die URL nicht kannte, konnte man doch durch "gezieltes Raten" versuchen, an Dokumente heranzukommen, wenn man den ungefähren Zeitpunkt kannte, zu dem das Dokument in STiNE erzeugt wurde. Denn danach richtet sich der Dateiname fnsrc, der die Form "f" + STiNE-ID + ".cache" hat.
  
 
== Kommentare ==
 
== Kommentare ==

Version vom 18. Mai 2008, 11:05 Uhr

Natürlich ist STiNE nicht nur ein großes, langsames Softwaresystem, es enthält auch ein paar Sicherheitslücken. Da es unfein ist, sie einfach so zu veröffentlichen, bekommen die Datenlotsen generell ein bißchen Vorsprung, um die Lücken zu schließen.

Ablauf, wenn Du eine neue Sicherheitslücke findest

  • Sicherheitslücke grob beschreiben
  • Datenlotsen benachrichtigen
  • Je nach Sachlage 21 Tage später die Sicherheitslücke (nach Absprache) veröffentlichen

Sessionübernahme per HTTP-Referrer

dumdidum.

Verlauf:

  • 09.10.2006: Lücke entdeckt (Roland Illig).
  • 10.10.2006: Datenlotsen benachrichtigt.

Cross-Site-Scripting beim Anzeigen von STiNE-Nachrichten

Beim Verfassen einer STiNE-Nachricht konnte man beliebigen HTML-Code in die Nachricht einbetten, der 1:1 im Browser des Empfängers angezeigt wurde.

Verlauf:

  • 10.10.2006: Lücke entdeckt (Roland Illig).
  • 10.10.2006: Datenlotsen benachrichtigt.
  • 17.10.2006: Die Sicherheitslücke ist behoben.
  • 17.10.2006: Details angehängt

Unbeabsichtigte Einsicht in STiNE-Nachrichten beliebiger Benutzer

Im STiNE-Modul MESSDETAIL konnte man einfach die Nachrichten-ID auf einen beliebigen Wert setzen, und wenn die Nachricht vorhanden war, wurde sie angezeigt, egal, ob sie für den gerade angemeldeten Benutzer bestimmt war.

Verlauf:

  • 10.10.2006: Lücke entdeckt.
  • irgendwann dazwischen: STiNE-Projektleitung benachrichtigt (mündlich, vielleicht auch schriftlich).
  • 17.10.2006: Die Sicherheitslücke ist behoben.
  • 18.10.2006: Details veröffentlicht.

Und so weiter ...

Das ist bei weitem nicht alles. Ohne große Anstrengung kann man mit wenig Fachwissen jede Menge weiterer Sicherheitslücken finden. Der umfassende Datenschutz, der in der STiNE-FAQ angepriesen wird, ist bei weitem nicht eingehalten. [16.10.2006]

Es macht allerdings den Eindruck, als ob die Datenlotsen jetzt erkannt haben, dass Softwaresicherheit wichtig ist (siehe auch STiNE-Tagebuch).

... und so weiter ...

Übrigens machen nicht nur die Datenlotsen so schlechte Software. Die Firma Magic Software, auf deren Middleware STiNE aufbaut, weiß auch noch nicht, was SQL-Injections sind, wie deren Entwicklerdoku zu eDeveloper beweist. (Update vom 22.05.2007: Das scheint mittlerweile behoben zu sein. --Roland Illig)

Unberechtigter Zugriff auf personenbezogene Dokumente

Durch gezieltes Raten ist es einem Angreifer möglich, auf die persönlichen Dokumente (zur Zeit Semesterbescheinigungen und Studienbuch) anderer STiNE-Benutzer zuzugreifen. Das funktioniert im Prinzip wie damals mit den STiNE-Nachrichten, nur dass die Dokumenten-IDs jetzt nicht mehr fortlaufend numeriert sind.

Verlauf:

  • 26.09.2007: Lücke entdeckt.
  • 26.09.2007: Datenlotsen benachrichtigt.
  • 27.09.2007, 14:50: Lücke behoben, die Mail über das Beheben habe ich jedoch erst am 01.10. bekommen. :)
  • 01.10.2007: Details veröffentlicht.

Details

Das Herunterladen von Dateien, die von STiNE verwaltet werden, geschieht nicht innerhalb von Magic, sondern mit einem externen Programm (filetransfer.dll). Das bekommt die folgenden Parameter:

  • PATH_INFO: "download" oder "upload" (wie letzteres geht, weiß ich allerdings noch nicht. ;))
  • session: Die Session-ID
  • fnsrc: Der Name der Datei auf dem Server
  • fndest: Der Name der Datei, wie ihn der Benutzer sehen soll
  • subdir: Das Verzeichnis, aus dem die Datei kommt. Mir wurde gesagt, dass es sich hierbei um "logische" Verzeichnisse handelt, so dass Angriffe der Form "subdir=../../../.." zwecklos seien.

Das Problem war nun, dass die Session-ID anscheinend garnicht überprüft wurde, denn man konnte die Dokumente auch herunterladen, wenn die Session-ID 0 war. Die Folge davon war, dass man die Datei auch noch herunterladen konnte, nachdem man ausgeloggt war, wenn man nur die URL kannte. Und selbst wenn man die URL nicht kannte, konnte man doch durch "gezieltes Raten" versuchen, an Dokumente heranzukommen, wenn man den ungefähren Zeitpunkt kannte, zu dem das Dokument in STiNE erzeugt wurde. Denn danach richtet sich der Dateiname fnsrc, der die Form "f" + STiNE-ID + ".cache" hat.

Kommentare

Kommentar: Als ich mal damit gespielt habe, ging das mit der Terminexportfunktion ähnlich. --MartinBurmester

Ja, stimmt, hatten wir das gar nicht erwähnt? ;) Ich wollte es eigentlich ausprobieren, aber da ich keine Termine habe, kann ich auch nichts exportieren. Ich bin trotzdem neugierig, wie lange die Dateien aufgehoben werden. --Roland Illig

Diese Sicherheitslücke sollte mittlerweile komplett behoben sein. Wer sich dennoch daran versuchen will, kann ja mal versuchen, meine Semesterbescheinigungen zu bekommen. Sie sind unter der ID fnsrc=f329444333092776.cache gespeichert. --Roland Illig