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);


"Faschisten, Nazi-Schweine!", schreit ed, noch bevor er das Flammenschwert richtig ziehen und googlen konnte, ob er denn überhaupt richtig liegt. Nach dem wm zarghaft klein ed ins Gewissen geredet hat, doch erst einmal zu überprüfen ob 'yacybot' und 'yacy' das gleiche wären und doch eigentlich erst das SCC zu fragen: "Warum eigentlich?"

Ja warum eigentlich schließt das SCC den yacybot von den Inhalten der Universitäts-Seite aus? Wie man es unschwer in der robots.txt nachlesen kann.

Da ed so das öffentliche pöbeln auf der Pinnwand des SCC oder der Piazza untersagt wurde, ergriff ed die Gunst der Stunde um die Redefreiheit dieses Blogs unter Beweis zu stellen!

Seit Freitag abend schien es so als das die alternative mediathek und pirate cinema weimar down wären. Gerade schlag ich im MR auf und sehe, dass die Kiste hier ganz normal läuft und die Seiten erreichbar sind. Aber irgendwie nur ausm Uni-Netz heraus. Bestimmt hat man uns die Ports abgedreht!? Mhm, don't know. Warum uns da eigentlich niemand bescheid sagt versteh ich immer nicht. Also wenn es jemanden "stört" bzw. jemanden etwas unklar ist könnte mensch ja darüber reden. Ist doch doof sowas. Naja für die Pirate Cinema Weimar Seite muss ich punk.152 nochmals stressen, dass wir eine Domain dafür bekommen und das ganze auf den Root-Server schieben. Für die mediathek allerdings brauchen wir noch eine schöne Lösung.

So ich mach dann mal an meinem Raytracer weiter. Die Bauchschmerzen kommen mir allein schon bei dem Gedanken daran. Könnte aber auch daran dass ich noch nichts gefrühstückt habe :)

[update] komisch komisch komisch nun geht wieder alles wie vorher ohne das was gemacht wurde?!

In den Kommentaren zu diesem Post hat Klaus Mebus -- Sicherheitschef des SCC -- den folgenden Text über die Probleme des SCC und die Umstellung von NIS auf LDAP hinterlassen, der hier nach Rücksprache mit ihm veröffentlicht wird:

Die Umstellung war für definitiv für März geplant. Die Voraussetzungen sollten u.a. mit der seit Juni 2008 laufenden und immer noch nicht abgeschlossenen Passwortsynchronisierung geschaffen werden. Wenn man ein Authentifizierungssystem umstellt, dann geht das in einer gewachsenen völlig heterogenen Umgebung mit verteilten Verantwortlichkeiten und einer möglichst geringen Beeinträchtigung aller Nutzer (wir haben über 7500 Accounts!) nicht auf die Schnelle, ohne das ggf. wichtige Prozesse beeinträchtigt werden. Das Problem war im übrigen nicht in erster Linie die Verwendung eines unsicheren Verschlüsselungsalgorithmus, sondern die Zugänglichkeit der NIS-Datenbank und der damit verbundenen Möglichkeit des Crackens der Passwort-Hashes. Hier machen es einem viele Nutzer sehr leicht, indem sie Passwörter verwenden, die die Bezeichnung kaum verdient haben. Hier hilft nicht mal die stärkste Verschlüsselung, wenn das bloße Raten ausreicht. Mir wäre es auch lieber, dass alle bekannten Misstände auf einen Schlag Geschichte wären, aber im SCC laufen eben noch viele andere Prozesse, die vielleicht nicht jeder auf den ersten Blick so sieht, und damit meine ich nicht nur die Standardaufgaben, sondern Projekte wie die gerade durchgeführte Storageumstellung. Umstellungen mit weitreichenden Folgen sollten gut geplant und ausreichend getestet werden, sonst kann es bei einer schnellen Implementierung auch wieder zu Fehlern kommen, die einem später auf die Füße fallen. Im Lehrbuch ist das immer einleuchtend und wenn meine seine(n) Home-PC oder Mac bearbeitet, geht das auch immer fix, aber hier geht es um wie gesagt um die komplette Infrastruktur eine Universität.
Schon mal versucht ein Passwortsystem für über 7500 accounts von Crypt auf MD5 (das wäre ja wohl die einzige Alternative im NIS) umzustellen? Funktioniert das überhaupt auf allen Systemen? Wie soll das Passwortsystem in der Übergangszeit crypt und MD5-Hashes gleichzeitig verarbeiten? Ist das überhaupt möglich? Sollten wir allen Nutzer das Passwort wegnehmen, alle accounts auf MD5 umstellen und dann jeder sich ein neues beim Benutzerservice abholen? Was machen die, die gerade nicht in Weimar sind?.... So easy ist das eben nicht.

Jedenfalls wurde die Umstellung nun angegangen und das bei vielen nicht ohne Schmerzen, die hätten vielleicht vermieden werden können, aber wir waren nun mal im Zugzwang und wollten und konnten nicht mehr warten. Ich hoffe jeder hat nun auch das Verständnis dafür, wenn eben mal temporär was nicht läuft, aber so ist das eben bei unplanmäßigen Änderungen und selbst bei einer guten Planung und Test kann es immer Fälle geben, bei denen Abhängigkeiten auftauchen, die man nicht voraussehen konnte.

In einer E-Mail fügte er an:

Bei neuen auf LDAP basierenden System werden wir natürlich bemüht sein einen Hash-Algorithmus zu verwenden, der die größt mögliche Sicherheit verspricht (SHA oder RIPEMD160). SHA-1 ist da zwar Standard bei LDAP, Bruce Schneier hat aber bereits 2005 auf Schwächen hingewiesen. Wenn es möglich ist werden wir also SHA-2 einsetzen und zusätzlich in jedem Fall dafür sorgen, dass man an die nicht mehr so einfach rankommt.

sind so komische Kartoffelprodukte. Meist frittiert und sehr salzig. In der Mensa gibt's die für ca. 50¢ pro Beilagenportion. Das ist nicht nur praktisch, wenn mensch schon wieder dringend den Elektrolyt- und Fetthaushalt in den Normbereich bringen muss. Das ist auch praktisch, wenn mensch andere Menschen mit Pommes bewerfen will. Wie z.B. den Ed und mich.

Nachdem wir bekannt haben, dass wir's verdient haben, hat die Jule nun einen Termin für unsere öffentliche Bepommesung festgelegt: Kommenden Montag, 12:30h, in der Mensa. Pommes müssen Interessierte aber selbst mitbringen.