Im Vergangenen November stiess ich bei Recherchen auf der Seite des Grossen Rats Basel auf mehrere Sicherheitslücken. Obwohl ich die Behörden sofort informiert habe, reagierten diese nur zögerlich und einige Mängel blieben bis heute bestehen.

Path Traversal und XSS

Auf der Internetpräsenz des Grossen Rats lassen sich die Protokolle der Sitzungen abrufen. Diese sind alle in einem Verzeichnis auf dem Server abgelegt. Ein einfaches PHP Skript listet den Verzeichnisinhalt auf. Der Verzeichnispfad wird dabei als einfaches Argument in der URL angegeben. Eine Prüfung dieses Arguments fand dabei überhaupt nicht statt! Die einzige "Schutzmassnahme" war eine open_basedir Einstellung von PHP. Dabei wurde ausser Acht gelassen, dass PHP auch Zugriff auf ein Temporäres Verzeichnis benötigt. Dafür wurde /tmp gewählt, was eine äusserst schlechte Wahl ist, da man so nicht nur auf alle temporären Dateien von PHP, sondern vom ganzen Server zugreifen kann.

Da der eingegebene Pfad ebenfalls ungeprüft und ungefiltert wieder ausgegeben wird, war auch XSS möglich.

Die folgenden URLs funktionierten zu diesem Zeitpunkt:

http://abstimmungen.grosserrat-basel.ch/index_archiv3_v1.php?path=/tmp
http://abstimmungen.grosserrat-basel.ch/index_archiv3_v2.php?path=/tmp
http://abstimmungen.grosserrat-basel.ch/index_archiv2_v2.php?path=/tmp
http://abstimmungen.grosserrat-basel.ch/index_archiv2_v2.php?path=%3Cscript%20%20defer=%22defer%22%3Ealert(%27xss%27)%3C/script%3E
http://abstimmungen.grosserrat-basel.ch/index_archiv3_v2.php?path=%3Cscript%20%20defer=%22defer%22%3Ealert(%27xss%27)%3C/script%3E

Im /tmp Verzeichnis können sich sensible Daten von PHP selbst oder anderen Programmen befinden. Darum erhält üblicherweise jedes Programm ein eigenes Unterverzeichnis zugeteilt und es werden nach Möglichkeit zufällige Dateinamen verwendet. Mit Zugriff auf den gesamten /tmp Verzeichnisbaum nützt dies jedoch wenig.

Fraglich ist auch, warum das Skript eine Art Versionsnummer im Dateinamen hat und warum die alten Versionen nicht entfernt wurden. Das erweckt einen chaotischen Eindruck.

Warning!

Wenn man die Hauptseite unter https://grosserrat-basel.ch/ aufruft fallen einem als erstes diverse «Warning:» Meldungen von PHP auf. Gemäss einer Antwort vom vergangenen November wird die Seite «gegenwärtig nicht mehr aktualisiert» weil die Seite auf eine neue Plattform migriert worden und es sei geplant diese alte Plattform abzuschalten. Die alte Seite mit den PHP Warnungen ist aber bis heute noch dort.

Die Warnungen sind nicht nur sehr unschön, sondern verraten wie im Fall von open_basedir auch Details über den Code und die Konfiguration des Servers.

Noch mehr XSS und etwas SQL

In einem Anderen Bereich der Webseite gibt es ein Suchfeld. Wenn man dort glaubt, mit den üblichen Ausdrücken gezielte Suchanfragen stellen zu können, wir überrascht sein, dass dabei die Seite kaputt geht:

http://www.grosserrat.bs.ch/de/geschaefte-dokumente/datenbank?gr_global_suchfeld=%27)&gr_kat_filter1=1

Auch HTML lässt sich ohne weiteres Eingeben:

http://www.grosserrat.bs.ch/de/geschaefte-dokumente/datenbank?pager_reset=1&gr_kat_tab=&gr_global_suchfeld=%22%3E%3Cscript%20defer=%22defer%22%3Ealert(%27xss%27);%3C/script%3E

Geprüft wird auch hier: Nichts. Aber auch hier gibt es eine "Schutzmassnahme": Eine Web Application Firewall prüft offenbar gewisse Eingaben, denn einige Zeit später konnte ich genau dieses Beispiel, dass ich in meinem ersten Bericht an die Admins aufgeführt habe, nicht mehr reproduzieren. Stattdessen kam vom Server ein HTTP 403 («Forbidden») zurück.

Doch WAF Regeln lassen sich umgehen und so habe ich kurzerhand nochmal mit einer leicht abgeänderte Variante geantwortet:

http://www.grosserrat.bs.ch/de/geschaefte-dokumente/datenbank?pager_reset=1&gr_kat_tab=&gr_global_suchfeld=%22%20onmousemove=%22alert(%27xss%27)%22%3E

Der einzig wirksame Schutz wäre gewesen, die Fehler in der Suchfunktion zu beheben.

Eine Content Security Policy wird nicht verwendet.

Kein HTTPS

Von Behördenseiten erwartet man Vertrauen. Doch wie in den in diesem Beitrag aufgeführten Beispielen zu sehen ist, werden die Inhalte bis heute nicht über HTTPS ausgeliefert. Selbst auf der Joomla! Login Seite ist keine gesicherte Verbindung möglich. Übrigens scheint dort auch keine Zwei-Faktor-Authentisierung aktiviert zu sein.

Zögerliche Antwort

Die Behörde hat erst im zweiten Anlauf geantwortet. Eine Anlaufstelle für Sicherheitsprobleme gibt es keine. Auch Wochen später liessen sich einige Beispiele noch reproduzieren. Inzwischen wurden die wichtigsten Probleme offenbar behoben. Allerdings wurde nicht immer die Ursache angegangen, sondern teilweise auf eine WAF zurückgegriffen oder Funktionen ersatzlos gestrichen.
Eine Abschliessende Antwort habe ich nicht erhalten.

Update: Einige Tage nach der Veröffentlichung des Artikels hat die Behörde reagiert und weitere Fehler behoben. Es soll nun an allgemeinen Sicherheitsverbesserungen gearbeitet werden.