Sicherheitsanalyse elearning.uni-bremen.de

Transkript

1 Sicherheitsanalyse elearning.uni-bremen.de 21 Übungsgruppen in der LV Informationssicherheit 1 Übersicht über Verwundbarkeiten von PHP-Systemen Analyse der Quellen (Stud.IP 1.1.5) Tests mit Testinstanzen Stud.IP elearning.uni-bremen.de Lernziele: Komplexität realer Verwundbarkeiten kennenlernen Funktion Tiger-Team in einem realen, soziotechnischen System ausüben, Problematiken kennenlernen 2 XSS (Cross-Site-Scripting) Ungeprüfte Eingaben in Titel / Titel nachgestellt Ermöglichen Einfügung von JavaScript in bestimmte Stud.IP- Webseiten, z.b. High-Score-Liste und Umfragen Baustein für komplexe Angriffe Mögliche Angriffe: Information Gathering Session Hijacking Umleitung auf präparierte Webseiten des Angreifers 3

2 Ungeprüfte Parameter Z.B. username, msg, shortcut XSS-Problematik: Einstreuen von JavaScript in sonst harmlos aussehende Original-Seiten von Stud.IP Möglicher Baustein für komplexe Angriffe 4 SQL-Injection Mehrere potentielle Probleme durch ungeprüfte URL- Parameter Z.B. $sortby (archiv.php) Weitgehender Schutz durch magic_quotes_gpc In $GET/$POST/$COOKIE werden Anführungszeichen mit Backslash entschärft Kein vollständiger Angriffsvektor gefunden 5

3 Unsafe GET Stud.IP erlaubt Ausführung von modifizierenden Operationen mit GET-Methode Angriff: Unterschieben von URLs in geeigneten Web- Seiten, auch außerhalb von Stud.IP seminare.php?cmd=kill &auswahl= Nutzt eventuell bestehende Session im Browser Mögliche Lösungen: Korrekte Implementation der GET-Semantik Referer-Check 6 Unvollständig modifiziertes Sicherheitsmodell logout.php erzeugt spezielle Session Damit Zugriff auf allerlei Informationen möglich Angriff: Auslesen von auf Stud.IP-Mitglieder beschränkte Informationen durch Externe (Outsider-Angriff) Im ursprünglichen Stud.IP-Sicherheitsmodell möglich (beabsichtigt) In Bremer Instanz nicht vollständig ausgebaut global_forum.php, browse.php (Vgl. Auch Zugänglichkeit von z.b. /user/* ohne Session) 7

4 und 495 weitere 8 Information Gathering PHP-Fehlermeldungen werden zum Benutzer durchgereicht Dateien wie history.txt sind zugreifbar Zugriff auf Verzeichnisse /modules/ /vote/ /resources/ /locale/ /lib/ /lernmodule/ /extern/ /chat/ /calendar/ /admin/ Mindestens Modifikationsdaten erkennbar Teils eigene Privacy-Probleme (letzte Folie) Erleichterung der Aufklärungsphase eines Angriffs 9

5 Nicht untersucht: Systemsicherheit Versionen von Subsystemen nicht immer aktuell Offener Port des MySQL-Subsystems Weitergehende Analyse ohne Gefährdung des Betriebs schwierig 10 Soziotechnische Aspekte Admins tappen in klar als solche erkennbare Falle Überhastetes Abdichten führt zu kurzzeitigen Verfügbarkeitseinschränkungen 11

6 Bewertung einer Übungsgruppe Wir finden es ziemlich merkwuerdig, dass ein so unsicheres System bei uns an der Uni, wie auch an vielen anderen eingesetzt wird. Da wir auch nicht wirklich viel Ahnung von der Materie haben und 1 2 Tage eher nur herumprobiert haben, ist davon auszugehen, dass Stud.IP noch viele weitere und gefaehrlichere Sicherheitsluecken hat, die zur kompletten Kompromittierung des Systems sowie der Accounts fuehren koennen 12 Stand von Stud.IP Viele der entdeckten Verwundbarkeiten waren in aktueller Open-Source-Version bereits ausgeräumt Gibt es ein Advisory-System für Stud.IP? 13

7 Empfehlungen an das ZMML Abkopplung von Open-Source-Version beenden Sicherheit zu einem expliziten Gegenstand der Stud.IP- Kooperation erheben Uni-Bremen-Sicherheitsmodell in Open-Source-Version verankern Administrative Maßnahmen treffen: Sicherheit in die Agenda aufnehmen Notfallpläne entwickeln Mitarbeiter in Sicherheitsfragen fortbilden Regelmäßige Sicherheitsaudits durchführen 14 Empfehlungen an die Studierenden Tiger-Team vs. getting carried away Wie lange müssen Angriffe sichtbar bleiben? Wie genau müssen Angriffe ausprogrammiert sein? (vs. Proof of Concept) Laborjournal Experimentelles Arbeiten Journal mit Bedingungen und Beobachtungen führen Bestandteil der Dokumentation 15