maschinenraum

Vor einem Monat wurde die Uni-Pinnwand unfreiwillig auf das private Blog einer recht bekannten Person umgeleitet.

Hier nun ein kleiner Erklärbär-Post zur Pinnwand-Sicherheit und ein wenig Web-Security im Allgemeinen:

Disclaimer: Die Informationen dazu sind seit Jahren bekannt und niemand möchte der Universität schaden oder hat wirklich Cookies geklaut. Es ist aber teilweise einfach zu einfach und viele Fehler tauchen im Netz immer wieder auf oder man begeht sie selbst wenn man Webseiten bastelt (ist immer einfacher als man denkt ;)

Daher hier einmal die beiden (bislang bekannten und bereits gefixten) Bugs in der Piazza etwas erklärt:

Bug #1: HTML-Injection

Möglich geworden ist dies durch eine XSS-Lücke. Der Titel eines Beitrages wurde auf der Übersichtsseite nicht korrekt escaped. ¹

Das klingt auf den ersten Blick recht harmlos. In Verbindung mit JavaScript ergeben sich aber unendlich viele Möglichkeiten Spass zu haben oder eben auch "böse" Dinge zu tun. Mit JavaScript hat man Zugriff auf den kompletten DOM einer Website und kann normalerweise ² auch Cookies auslesen oder Asteroids mit den Elementen der Website spielen ³.

Cookies sind vor allen Dingen interressant, weil damit Sessions authentizifiert werden. Wer es noch nicht kennt: Firesheep demonstriert recht beeindruckend, dass man oft nur den Cookie stehlen muss um eine Session zu stehlen.

Zum Glück hat das SCC seine Hausaufgaben hier gemacht und das Vorlesungsverzeichnis (mit den Noten der Studenten) nutzt httponly-Cookies ² und ist damit (mit modernen Browsern) nicht angreifbar. Aber das TYPO3-Backend der Uni nutzt diese z.B. nicht.

Wie würde denn ein Angreifer mit bösen Absichten Session-Cookies stehlen?

Hier hilft wieder JavaScript. Cookies und JavaScript haben 2 verschiedene Sicherheitskonzepte. JavaScript hat eine sog. Same-Origin-Policy. D.h. man hat nur Zugriff auf Objekte der Domain in der das JavaScript ausgeführt wird.

Cookies haben zusätzlich zur Same-Origin-Policy noch einen Cookie-Path d.h. der Browser sendet nur Cookies an eine bestimmte Unterseite, wenn diese im Cookie-Path steht.

Dank JavaScript ist es aber kein Problem dies zu umgehen:

Man muss nur die Seite von der man die Cookies stehlen möchte in einen z.B. 1x1 Pixel großen <iframe> öffnen und kann dann über die JavaScript Funktion document.cookie den gewünschten Session-Cookie auslesen und unbemerkt weiterleiten.

Damit ist es dem Angreifer dann möglich sich als User zu authentifizieren.

Um das mal am Beispiel der Pinnwand zu illustrieren:

Person XY ist im TYPO3-Backend der Universtät eingeloggt und besucht die Pinnwand-Seite, dort ist ein verstecktes JavaScript in einer Nachricht, welches die TYPO3-Seite im Browser von Person XY in einem unsichtbaren (oder sehr kleinen) <iframe> öffnet, den Session-Cookie stielt und an den Angreifer weiterleitet.

Dieser kann sich nun selbst im TYPO3 einloggen in dem er den Cookie in seinen Browser einträgt.

Bug #2: Authentifizierung umgehen

Bis vor 3 Wochen konnte man ohne Passwort-Abfrage und ohne Freischaltung unter jeden Namen auf der Pinnwand Beiträge verfassen.

Die XSS-Lücke hat die Neugier geweckt und man kann sich ja mal den HTML-Quellcode ansehen und beobachten wie die Pinnwand funktioniert.... erstaunliches trat zu Tage:

Zur Erklärung: Dinge die man in Browser-Eingabekästchen eintippt werden gewöhnlich durch <form> und <input> Tags beschrieben. Beim Klick auf "Beitrag veröffentlichen" sendet der Browser in einen POST-Request die Daten an die URL die in dem Form-Tag angeben ist.

Auf der "Beitrag-Verfassen"-Seite wurde schon immer ein ein Passwort mitgesendet und überprüft. So weit so gut...

Nach der Verfassen-Seite kommt die Vorschau-Seite. Dort gibt gab es wieder ein Formular welches abgeschickt wird:


<form method="post"
action="https://www.uni-weimar.de/cms/index.php?id=2456" id="insert"
accept-charset="ISO-8859-1, ISO-8859-2">
<fieldset>
<input type="hidden" name="user" value="HIER EINEN
UNI-LOGIN EINTRAGEN">
<input type="hidden" name="titel" value="Titel des Posts">
<input type="hidden" name="inhalt"
value="Inhalt+vom+Post+urlencoded" />
<input type="hidden" name="datum" value="2010-10-20">
<input type="hidden" name="zeit" value="14:30:00">
<input type="hidden" name="dauer" value="1h">
<input type="hidden" name="intern" value="">
<input type="hidden" name="gast" value="">
<input type="hidden" name="pin_rubrik" value="11">
<input type="submit" value="Beitrag veröffentlichen"
name="insert">
</fieldset>
</form>


Na - fällt etwas auf? Hier gibt gab es kein Passwort-Feld. Und die URL an welche die Daten gesendet werden ist auch eine andere.

Blöd nur, dass HTTP zustandslos ist. Dementsprechend interressiert es weder den Browser noch die Website ob man sich vorher schon erfolgreich authentifiziert hat...

...basteln wir uns also eine kleine HTML-Datei, welche die Daten hinschickt und ändern wir den Eintrag im user=-Feld.

Huch. Da ist ein neuer Beitrag auf der Piazza ohne Passwortabfrage von einer anderen Person. In das Feld für den Namen konnte man eintragen was man möchte.

Jetzt können wir also alle unliebsamen Vorlesungen absagen und in Bernds Namen trollen. m(

Wer selbst eine Lücken finden sollte: Bitte der SCC Security Hotline melden: security@scc.uni-weimar.de. Die kümmern sich dann darum.

Und hier gibt es einen gutes Tutorial zur Sicherheit von Web-Anwendungen.

Anmerkungen

[1] Escaping ist das Umwandeln von Sonderzeichen wie < > in entsprechende HTML-Codes, so dass der Browser sie nicht mehr ausführt. In PHP z.B. mit htmlspecialchars() machbar.

[2] Da es das Problem des Cookie-Diebstahls schon sehr lange gibt wurde mit Internet Explorer 6 SP1 (2002) das httponly-Flag eingeführt. Damit wird verhindert, dass JavaScript- sowie AJAX-Funktionen Zugriff auf derart gesicherte Cookies haben.

[3] Einfach das Codeschnippsel in die Adresszeile kopieren mit den Pfeiltasten navigieren und mit der Leertaste ballern:

javascript:var%20s%20=%20document.createElement('script');
s.type='text/javascript';document.body.appendChild(s);
s.src='http://erkie.github.com/asteroids.min.js';void(0);


scheint an unserer geliebten Universität das Akronym für Servicezentrum für Computersysteme und -kommunikation zu sein. Auch, wenn ich's bei dem Namen persönlich ja SCK genannt hätte aber vielleicht wurde das beim Abkürzen ja in's Englische übersetzt. Ein junger Mann mit dem ich wiederholt in der Mensa gefrühstückt habe, nannte die Mittagsessengruppe des SCCs, die wir während des Frühstücks wiederholt getroffen haben, immer den "Behindertenkindergarten" – das fand' ich nicht so nett. Aber vielleicht steht SCC in Wirklichkeit Schon Comische Cinder.

Letzteres würde zumindest einige ihrer Sicherheitsstrategieen erklären. So hindern sie mich regelmäßig – also täglich – daran Linuxdistributionen zu verbreiten, bitten mich aber darum, dass ich ihren Mailserver nutze (worin sie die einzige Möglichkeit sehen, sicher zu stellen, dass die von mir versandten E-Mails auch von mir stammen). Den Blödsinn mit den E-Mails werd' ich hier jetzt nicht kommentieren, den wie schnell E-Mail-Adressen gekapert sind weiß heutzutage schon jeder Bildleser.

Andere Services des SCC nutze ich auch nur selten und wenn, dann nur unter Verwendung größerer Vorsichtsmaßnahmen als ich im kostenlosen WLAN von Bahnhofskneipen an den Start bringen würde. Zu diesem Zweck hilft es, dass vor einigen Wochen eine Liste im Bus gefunden wurde, die Nutzernamen und Passwörter von Nutzern enthält, die nicht-natürlichen Personen zugeordnet sind [diese Liste kann auf Anfrage weitergegeben werden]. Ich geh' einfach davon aus, dass es schon in Ordnung geht, wenn ich hier mit

user: siemens
pass: siemens.

das Netz nutze. E-Mails gehen dennoch nicht durch aber nach Anlage 2, § 4, Satz 2 der Nutzungsordnung geht das schon in Ordnung, dass ich innerhalb der Uni so ausgefallene Protokolle wie IMAP nicht nutzen kann. Vielleicht ist ihnen ja aufgefallen, dass sie ihren Mehlserver so häufig ausfällt, dass Studierende ihre Privatsphäre lieber an US-amerikanischen Unternehmen preisgeben als ihnen.

Grund dieses Posts ist aber ein anderer. Vor eingien Tagen wurde das Arbeitstier der Rechnerinfrastruktur unserer Uni offline genommen. Dafür gibt's jetzt hübsche neue Hardware und Single-Sign-On-Accounts für alle Systeme und Pools der Uni. Das ist schon schick. Scheint aber eine Kleinigkeit verfrüht durchgeführt worden zu sein. Das Erste, was jemand nach der Umstellung im Bus gefunden hat war die Liste aller 7455 Logins, die das SCC derzeit verwaltet [auch diese Liste kann auf Anfrage vorgezeigt werden]. Der oben  veröffentlichte Eintrag sieht da z.B. so aus:

siemens:mi4SbmDAImKTI:18565:20:Projekt Siemens:/home/zuv/siemens:/bin/csh

oder in menschenlesbar:

Login-Name:gehashtes Passwort:Klarname:Heimatverzeichnis des Nutzers:Login-Shell

Noch sind die Passwörter nicht offen. Aber dank der zu erst gefundenen Liste und einiger Freiwilliger haben wir ca. 20 Cribs.  Es scheint nur noch eine Frage der Zeit und Rechenpower bis alle Passwörter vorliegen. Derzeitiger Zwischenstand: Wir wissen wie der Hash gesalzen ist, wir wissen wie gehasht wird, wir haben Rechenpower und Zeit.

Also: Wenn mein Vertrauen in's SCC jemals bestanden hätte, jetzt wäre der Zeitpunkt an dem ich meine E-Mails und anderen Daten auf Computer verlegen würde, die mir oder Menschen denen ich vertraue gehören.

Mein eigentliches Problem ist aber, dass der Kollege neben mir dabei ist ein sehr gutes und sicheres Passwort von mir freizurechnen. Ein Passwort, das ich auch in anderen Zusammenhänge verwende. Leider sind das nicht nur Uni-Spielzeug-Server, sondern zentrale Teile meiner Privatsphäre. Ich hab' wohl den Rest der Nacht damit zu tun Passwörter zu ändern. Im SCC ist's derzeit leider nicht möglich :-(

lalap00.