Archive for the ‘Sicherheit’ tag
Sicherheitsupdate für PHP bei CGI-Verwendung
Gestern wurden neue Versionen für PHP 5.4 und 5.3 released, namendlich: 5.4.2 und 5.3.12. Grund für diese neuen Versionen ist eine gravierende Sicherheitslücke bei der Verwendung von PHP im CGI-Modus.
Aber erstmal Entwarnung: Wahrscheinlich nutzt ihr kein CGI mehr sondern FastCGI oder mod_php, dann seid ihr nicht gefährdet. Wer aber noch auf die alte CGI-Schnittstelle setzt sollte sich schleunigst informieren und updaten um schlimmeres zu vermeiden, denn dank dieser leicht auszunutzenden Lücke ist es jedermann möglich, die Quelltexte euer PHP-Dateien im Document-Root anzuschauen oder auch beliebigen eingeschleusten PHP-Code auszuführen.
Wer seine alte Installation nicht anfassen darf oder kann, für den gibt es Hilfe in Form einer Rewrite-Regel:
Local File Inclusion: Einige Beispiele
Ich habe schon länger keine sicherheitsrelevanten Probleme mehr gepostet, heute schauen wir uns ein paar häufig gemachte und exisierende Fehler an. Schaut euch diesen Code-Schnipsel an:
<? $url = $_POST['imageUrl']; $content = file_get_contents($url); // Put the content of that URL into a database for later use/display
Der Benutzer der Webseite kann also in ein Formular eine URL eintippen, beispielsweise die URL eines Bildes, einer XML-Datei oder einer Webseite. Das Script ruft diese Resource (z.B. ein Avatar Bildchen) ab und speichert es auf der Festplatte oder in einer Datenbank.
Auf einer anderen Seite kann der Benutzer (und vielleicht alle anderen Besucher der Webseite) dieses Bild dann abrufen.
Gibt es hier ein Sicherheitsloch? Ja, gleich mehrere! Was passiert wenn der Benutzer zum Beispiel folgende URLs eingibt:
2-Faktor-Authentifizierung mit dem Google Authenticator
Viele größere Webdienste bieten mittlerweile die 2-Faktor-Authentifizierung an, PayPal, Amazon, Facebook und nicht zuletzt Google. Mit der 2-Faktor-Authentifizierung muss neben dem Benutzernamen und Passwort auch noch ein Einmal-Passwort, ein sogenanntes One-Time-Token eingegeben werden, das von einem Gerät unabhängig vom PC generiert wird und nur einmal gültig ist. Sollte es also jemand schaffen und das Passwort erraten oder mitschneiden, hilft es dem Angreifer wenig denn er muss auch noch Zugriff auf das Hardwaregerät bekommen, und das sollte schwierig sein.
Die Generierung von solchen Codes ist nicht sonderlich schwer, beide Parteien (das Gerät und die Webseite) müssen nur ein gemeinsames “shared secret” kennen (auch Seed genannt), und aufbauend auf diesem dann sich immer ändernde Codes generieren können. Dazu gibt es RFCs, beispielsweise RFC 4226.
Client-Zertifikate als sicherer Login-Ersatz?
Wer auf Sicherheit achtet und seinen Webseitenbesuchern etwas Privatsphäre spendieren möchte installiert ein SSL-Zertifikat auf dem eigenen Webserver. Damit ist es Besuchern möglich verschlüsselt mit dem Webserver zu kommunizieren und ein eventuell vorhandener Mithörer im offenen WLAN guckt dumm aus der Wäsche. Spätestens wenn es um Login-Daten oder andere persönliche Informationen geht sollte HTTPS eigentlich mittlerweile Standard sein, aber auch für normale Seiten lohnt es sich, denn bereits eine URL verrät einiges über eine Person, auch wenn die Seite eigentlich nichts geheimes enthält.
HashDoS Angriff legt (unter anderem) PHP lahm
Ich bin leider die letzten 2 Tage nur wenige Stunden dazu gekommen die Live-Streams vom 28. Chaos Communication Congress (28C3) zu schauen, aber bzgl. PHP ist heute Nachmittag ein interessanter Talk gehalten worden mit dem Thema Effective Denial of Service attacks against web application platforms dem ich hier einen kurzen Artikel widmen werde.
Es geht darum wie PHP (und die anderen anfälligen Sprachen auch) Hash-Tabellen erstellen und verwalten. Die hier interessante Hash-Tabelle ist das $_POST Array, das man von außen füllen kann, und das anfällig ist wenn man nur genügend “passende” Datensätze reinfüllt. Der Algorithmus der die Hash-Tabelle befüllt wird nämlich langsamer sobald Kollisionen der Keys auftreten. Schickt man also beispielsweise 300KB POST-Daten an ein PHP-Script ist eine schnelle CPU damit ca. 30 Sekunden unter Volllast. Bei 8MB (dem Standard-Maximum für POST-Daten in der php.ini) wären es immerhin schon 5 Stunden, die die CPU benötigt um die Hash-Table zu füllen. Man kann also mit einer relativ kleinen DSL-Leitung einigen Schaden anrichten. Mit einer Gigabit-Leitung kann man so 10.000 CPU-Kerne dauerhaft beschäftigen.
