STiNE-Sicherheitslücken: Unterschied zwischen den Versionen
K (2 Versionen) |
|||
| (5 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 14: | Zeile 14: | ||
* 09.10.2006: Lücke entdeckt ([[Roland Illig]]). | * 09.10.2006: Lücke entdeckt ([[Roland Illig]]). | ||
* 10.10.2006: Datenlotsen benachrichtigt. | * 10.10.2006: Datenlotsen benachrichtigt. | ||
* 01.04.2014 (Ja, wirklich nach SIEBEN Jahren!): Lücke behoben (allerdings schon vor ein paar Wochen) | |||
= Cross-Site-Scripting beim Anzeigen von | = Cross-Site-Scripting beim Anzeigen von STiNE-Nachrichten = | ||
Beim Verfassen einer | 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 27: | ||
* 17.10.2006: Details angehängt | * 17.10.2006: Details angehängt | ||
= Unbeabsichtigte Einsicht in | = 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 33: | ||
Verlauf: | Verlauf: | ||
* 10.10.2006: Lücke entdeckt. | * 10.10.2006: Lücke entdeckt. | ||
* irgendwann dazwischen: | * 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 39: | ||
= 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 [ | 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 45: | ||
= ... 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 | Ü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 | 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 58: | ||
== Details == | == Details == | ||
Das Herunterladen von Dateien, die von | 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 | * session: Die Session-ID | ||
* fnsrc: Der Name der Datei auf dem Server | * fnsrc: Der Name der Datei auf dem Server | ||
| Zeile 64: | Zeile 65: | ||
* 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 | 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 == | ||
| Zeile 71: | Zeile 72: | ||
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]] | 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]] | ||
[[Kategorie:STiNE]] | |||
Aktuelle Version vom 1. April 2014, 09:38 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[Bearbeiten]
- 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[Bearbeiten]
dumdidum.
Verlauf:
- 09.10.2006: Lücke entdeckt (Roland Illig).
- 10.10.2006: Datenlotsen benachrichtigt.
- 01.04.2014 (Ja, wirklich nach SIEBEN Jahren!): Lücke behoben (allerdings schon vor ein paar Wochen)
Cross-Site-Scripting beim Anzeigen von STiNE-Nachrichten[Bearbeiten]
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[Bearbeiten]
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 ...[Bearbeiten]
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 ...[Bearbeiten]
Ü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[Bearbeiten]
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[Bearbeiten]
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[Bearbeiten]
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