Das löchrige Intranet der Fachhochschule Graubünden

Als (unterdessen ehemaliger) Student der Fachhochschule Graubünden habe ich Zugang zu deren Intranet. Es handelt sich dabei um eine Typo3 Inhouse-Entwicklung der FHGR, über welche Studierende administrative Dinge wie Einschreibungen, Download der Zeugnisse, Verwaltung der Studentenkarte usw. erledigen können. Über falsch oder nicht gesetzte Zugriffsrechte im System ist es mir gelungen, Zugang zu Zeugnissen, Scans, Druckverläufen und weiteren sensiblen Daten aller an der FHGR eingeschriebenen Studierenden und Mitarbeitenden zu erhalten. Das Ausmass und die technischen Begebenheiten des Datenlecks sowie die Reaktion der FHGR werden nachfolgend kurz dargelegt.

Fehlermeldungen und Zugriffsrechte

Das Intranet der FHGR befand sich während meiner Studienzeit öfters mal im Umbau, was nicht selten in kleineren Unterbrüchen, toten Links oder Downtime bei der Notenfreigabe resultierte. Vor einiger Zeit ging beim Einschreiben für das neue Semester etwas schief und es wurden mir laufend Typo3 Fehlermeldungen angezeigt. Interessanterweise wurde der gesamte Stacktrace ausgegeben, was mich ein wenig stutzig machte.

Der Stacktrace zeigt an, was im Programm bisher geschehen ist und wo es schlussendlich zum Fehler gekommen ist. Das ist als Entwickler*in nützlich, da man so mehr Informationen zur etwaigen Ursache des Fehlers bekommt, auf Live-Websites stellt dies jedoch eine Angriffsfläche dar. Potentielle Angreifer (oder neugierige Studenten) erhalten so einen Einblick in den Quellcode der Applikation und in das dahinterliegende System. Es ist daher üblich, bei Live-Websites auf die Ausgabe des Stacktrace zu verzichten, stattdessen wird z. B. lediglich eine Meldung mit dem Text «Oops, an error occurred!» angezeigt.

Hier wurden von FHGR offensichtlich best-practicies¹ ignoriert, was mich dazu bewegte, einen genaueren Blick auf das Intranet zu werfen. Nach einigem Ausprobieren und dem Erzwingen von Fehlermeldungen auf diversen Seiten des Intranets stellte ich fest, dass die Anfragen für das Herunterladen von Dateien über eine Typo3 Extbase Extension geschehen, welche über GET Parameter ansteuerbar ist. Das sieht am Beispiel der gekürzten URL für den Download der Campus Credit Punkte folgendermassen aus:

...&tx_htwouteng_reportengine[report]=ccpreport&tx_htwouteng_reportengine[params]=a:2:{s:8:"idperson";s:6:"146246";s:12:"studienstufe";s:3:"bsc";}&tx_htwouteng_reportengine[output]=pdf

Die Personen-Id 146246 sowie die Studienstufe bsc werden als Parameter an die Extension tx_htwouteng_reportengine weitergegeben, welche dann das entsprechende Dokument als PDF zurückgibt. Erwartungsgemäss müsste hier überprüft werden, ob die angefragte Id mit der Id des eingeloggten Users übereinstimmt, damit dieser ausschliesslich seine eigenen Dokumente herunterladen kann. Dies geschah jedoch nicht: das Anpassen der Id ermöglichte es mir, den Campus Credit Report einer Studienkollegin als PDF herunterzuladen.

Auch mit dem Intranet verbunden – und ebenso ein Eigenbau der FHGR – ist der Dienst der Studentenkarte. Die Studentenkarte dient als Zahlungsmittel für die Mensa und wird für das Drucken und Scannen von Dokumenten an der Hochschule sowie für das Buchen von Sportangeboten verwendet. Über das Intranet besteht die Möglichkeit, den Saldo der Karte abzufragen. Auch hier konnte über das Anpassen der GET Parameter eine xls Datei der Saldoübersicht eines beliebigen Users heruntergeladen werden, ohne dass Berechtigungen geprüft wurden:

...id=saldouebersicht_print&tx_htwouteng_reportengine[report]=eq_transactions&tx_htwouteng_reportengine[params]=a:2:{s:6:"anzahl";i:250;s:6:"iduser";s:5:"10090";}&tx_htwouteng_reportengine[output]=xls

Mittels dem oben beschriebenen Vorgehen erhielt ich Zugriff auf eine Vielzahl von Dokumenten, welche auf den Servern der FHGR lagen. Das Prinzip war jeweils das gleiche: URLs bzw. Parameter die leicht zu erraten sind und fehlende Prüfung der Rechte seitens der FHGR. So setzten sich z. B. die GET Anfrage zum Herunterladen gescannter Dokumente aus Datum und Uhrzeit, dem Namen des Users und der IP des Druckers zusammen. Alles Dinge, die einem bestimmten Muster folgten und somit leicht zu erraten waren. Mittels eines Scripts, welches systematisch alle möglichen Kombinationen durchprobierte, war es so relativ einfach möglich, gescannte Dokumente einer beliebigen Person an der FHGR herunterzuladen.

Ausmass

Mit dem oben beschriebenen Vorgehen wäre es mir (und jeder anderen Person, welche Zugriff zum Intranet der FHGR hat) potentiell möglich gewesen, Leistungsnachweise aller Semester, Saldoübersicht der Studentenkarte und gescannte Dokumente aller rund 2000 aktuell an der FHGR eingeschriebenen Studierenden sowie an der FHGR angestellten Personen herunterzuladen. Entgegen meiner Erwartungen wurden meine doch recht aggressiven Scripts nicht geblockt, ich beendete den Versuch daher, um die Server nicht weiter zu belasten.

Neben Namen, AHV-Nummer, Geburtsdatum sowie Noten aller Studierenden enthielten vor allem die Saldoübersicht der Studentenkarte und die gescannten Dokumente weitere sensible Daten. Auf der Saldoübersicht ist der Druckverlauf mit Datum, Uhrzeit und Dateiname vermerkt. Allein schon aus Dateinamen lassen sich persönliche Daten lesen. So ist z. B. ersichtlich, wer ein Stipendiengesuch eingereicht hat oder wer sich für ein Austauschsemester angemeldet hat. Unter den gescannten Dokumenten waren zudem auch private Dokumente wie Mietverträge oder Veranstaltungstickets zu finden.

Das Ausnutzen der oben beschriebenen Lücken war meines Wissens nur Personen möglich, welche über ein Intranet-Login verfügten. Auf meiner Suche stiess ich jedoch noch auf weitere Lücken, welche Daten zum Teil auch von aussen – sprich ohne Intranet Login – zugänglich machten:

• Das Wegleitungssystem im Hauptgebäude der FHGR funktioniert mittels im Gebäude angebrachten Beamern, welche die Besucher*innen auf entsprechende Räumlichkeiten oder Veranstaltungen aufmerksam machen. Die Steuerung dieser Beamer war öffentlich für jeden zugänglich. Es wäre somit jederzeit möglich gewesen, das gesamte Wegleitungssystem des Hauptgebäudes oder Teile davon auszuschalten.
• Ebenso ohne Login zugänglich waren Archive diverser internen Protokolle, welche bis ins Jahr 2014 zurückreichten. Betroffen hiervon waren vorwiegend Kommissionen der FHGR, unter anderem die Mitwirkungskommission, Nachhaltigkeitskommission und Gesundheitskommission.
• Die «internen» Intranet-Bereiche Personal sowie Qualitätsmanagement waren ebenso öffentlich einsehbar und verlinkten auf weitere Google Docs/Spreadsheets, welche über eine Linkfreigabe geteilt waren, sensible Daten enthielten und bearbeitet werden konnten.
• Es wäre mir möglich gewesen, die Abgabe des Abstracts und des Titels aller laufenden Bachelor- und Mastertarbeiten zu bearbeiten (und Monate zu früh final einzureichen).

Die Anzahl Lücken und die Vielfalt der betroffenen Bereiche deuten auf schwerwiegende Fehler und eine fahrlässige Handhabung der Benutzerrechte im Intranet der FHGR hin. Zudem lässt das Kürzel ‹htw› im Namen der Extensions vermuten, dass diese Lücken schon länger bestanden, da die FHGR seit dem Jahr 2019 nicht mehr HTW (Hochschule für Technik und Wirtschaft) heisst.

Reaktion

Über die oben beschriebenen Lücken informierte ich den Informatikdienst der FHGR in zwei Mails. In der ersten Mail im Februar 2022 meldete ich die Lücken, welche mir zu jener Zeit bekannt waren (Leistungsnachweise, Studentenkarte, Studienbestätigungen). Ich ging davon aus, dass ich bei Weitem nicht alle Lücken gefunden hatte und empfahl dem Informatikdienst daher, das gesamte System zu untersuchen.

Die Reaktion auf die erste Mail erfolgte schnell und die entsprechenden Parameter wurden als Workaround in der URL verschlüsselt. So war es nicht mehr möglich, durch erraten der URL unberechtigt Daten herunterzuladen. Auf meine Empfehlung hin, das gesamte System hinsichtlich der Zugriffsberechtigungen zu überprüfen, begann der Informatikdienst der FHGR laut eigenen Angaben, «bestimmte Methoden zusätzlich abzusichern, so dass nur berechtigte Personen darauf zugreifen können», da dies «bei nachgelagerten Aktionen leider nicht konsequent erfolgte».

Als ich mich einige Monate später, nach Abschluss meiner Bachelorarbeit, nochmals auf die Suche nach Lücken machte, stellte ich fest, dass das Überprüfen des Gesamtsystems wohl nicht konsequent erfolgt war. Im Gegenteil, die restlichen der oben genannten Lücken entdeckte ich erst zu diesem Zeitpunkt. Erneut meldete ich mich beim Informatikdienst, welcher wiederum schnell reagierte und die Lücken innerhalb einer Woche behob. Die von mir gemeldeten Datenlecks sind damit behoben².

Fazit

Wie lange die Lücken bestanden, ob schon Daten abgegriffen wurden und wie löchrig das Intranet sonst noch ist, ist schwer zu beurteilen. Was bleibt ist das Gefühl, dass eine Hochschule, die unter anderem Kurse in Information Security und Webengeneering anbietet, dies eigentlich besser können sollte und dass jemand, der sich vertieft mit Typo3 auskennt, auch jetzt noch einiges an Daten aus diesem System holen könnte. Grundsätzlich begrüsse ich den Ansatz der FHGR, eigene Software zu verwenden und sich nicht von einem Tech-Giganten abhängig zu machen. Jedoch scheint die interne Qualitätskontrolle und der Umgang mit Vorfällen dieser Art noch einiges an Verbesserungspotential aufzuweisen, um auch in Zukunft sicherzustellen, dass die von der FHGR entwickelten Systeme gängige Sicherheits- und Datenschutzstandards einhalten.

Da ich nun mein Studium an der FHGR abgeschlossen habe, darf gerne ein anderer Student bzw. eine andere Studentin einen Blick auf das Intranet werfen und die FHGR auf Trab halten. Der Stacktrace wird bis heute (Oktober 2022) ausgegeben, eventuell lässt sich hier noch was Spannendes finden…

1. Typo3 Docs, Debugging Setup, Error and exception handling
2. Oder zumindest mit einem Workaround (dem Verschlüsseln bzw. Verschleiern der GET Parameter) versehen.