Dieser Artikel ist eine Antwort auf den Blogeintrag “777-Saftyalert — Post vom Provider” im Templaterie Blog. Der Artikel stellt die Frage, warum manche Provider es verbieten, die Zugriffsrechte von Dateien auf “777″ zu setzten.
“Ich lasse mich in der Angelegenheit Sicherheitsrisiko 777 gerne belehren…”
Nun, dann wollen wir das einmal versuchen 
Was bedeutet eigentlich 777?
777 ist die nummerische Darstellung von UNIX-Zugriffsrechten auf eine Datei oder ein Verzeichniss. In Buchstaben übersetzt ist es (ein wenig) anschaulicher: rwxrwxrwx.
Ein ‘r’ steht für read (lesen), ‘w’ steht für write (schreiben) und eXecute (ausführen, bzw. bei Verzeichnissen dafür, dass man in diese wechseln darf).
Diese Buchstaben kommen drei mal vor, um zwischen verschiedene Berechtigungsstufen unterscheiden zu können: Die Berechtigungen für den Eigentümer der Datei, für Mitglieder der ‘Gruppe’ der die Datei gehört und schließlich für den “Rest der Welt”. Hierzu gehören alle Benutzer des Systems, inklusive des Webservers und einem eventuellen “Gastkonto”.
Berechtigungen von “rwxr-x—” (also: 750) bedeuten zum Beispiel: Der Eigentümer darf alles mit der Datei machen. Die Gruppe darf die Datei lesen und ausführen, und der Rest der Welt darf gar nichts mit der Datei anstellen. Auch die Kombination “rw-r–r–” (oder: 644) ist gebräuchlich: Alle dürfen lesen, aber nur der Besitzer darf schreiben. Die 777 bedeutet also daß jeder der Zugriff auf den Computer hat darf alles mit der Datei machen. Ändern und Ausführen sind hierbei die sensiblen Stellen.
Alle Benutzer, die bei dem Provider einen Account haben können also auf den ungesicherten Webspace zugreifen. Ebenso kann dies jeder, der sich als “anonymous” über FTP einloggt, falls diese Möglichkeit besteht. (Man beachte: Anonymous-FTP ist ein Feature, keine Sicherheitslücke, die geschlossen werden müsste.)
Was kann ich mit 777 anstellen?
- Illegale Skripte / Filesharing-Server / Kinderporno-Schleudern / Phishing-Sites / …:
Jeder, der auf den FTP-Server des Providers zugreifen kann, kann seine eigenen Skripte und Server im ungeschützten Webspace installieren. Die Staatsanwaltschaft meldet sich dann beim unvorsichtigen Accountinhaber anstatt beim Ganoven.
Alleine diese Möglichkeiten sind meines Erachtens schon Grund genug, die Zugriffsrechte zu beschränken. Die Überwachung des eigenen Traffics ist kein geeignetes Mittel hiergegen anzugehen: Selbst bei täglicher Kontrolle haben die bösen Jungs 23 Stunden zur Verfügung, in der schon viel Schaden entstehen kann.
Aber: Wie könnte ein Szenario aussehen, in dem nicht nur der unvorsichtige Besitzer des “777-Accounts”, sondern auch andere Benutzer des Servers in Gefahr wären?
- Gezieltes Ausnutzen von Server-Schwachstellen:
Normale Benutzer versuchen Ihre Skrite so sicher wie möglich zu machen. Das gelingt nicht immer, und dann können Cracker oder Würmer diese Schwachstellen nutzen, um weitere Schwachstellen in Datenbanken oder Webservern auszunutzen, um schließlich Kontrolle über die ganze Maschiene zu erlangen.
Diese Möglichkeiten sind um so größer, wenn die Skripte von jedermann verändert werden können. Die erste Sicherheitskontrolle (das Skript des Benutzers) fällt weg.
Klar, sollten alle Webspace-Provider ihre Server immer frisch gepatched haben. Aber alles was es den bösen Jungs schwerer macht, ist gut. - Installation weiterer Software:
Wer Skripte beliebig verändern kann, kann auch andere Programme installieren. Auch wenn diese unter Unix dann ‘nur’ unter den Berechtigungen des entsprechenden Benutzers laufen, so können damit doch eventuell Daten ausspioniert werden.
Auch könnten Eindringlinge “Brute-Force Attacken” auf den Server des Providers durchführen. Firewalls und ähnliches sind umgangen. Mit entsprechend vorsichtigem Timing und der Benutzerliste des Servers könnten so Passworte anderer Webspace-Kunden geknackt werden. Und wenn diese Passworte auch für andere Dienste genutzt werden (was sie selbstverständlich nicht sollten), dann steht weiteren Einbrüchen oder Identitätsmißbrauch nicht mehr viel im Wege.
Fazit:
Auch wenn ich die oben angedachen Möglichkeiten nicht selbst ausprobiert habe, so finde ich sie doch plausibel genug, um auf die bequemlichkeit, die “777″ bringen kann zu verzichten. Uneingeschränkter Zugriff auf Webspace ist bei ansonsten perfekt gesicherten Servern wahrscheinlich gar nicht so schlimm. Jedoch ist es ein Schritt von vielen, den Server perfekt abzusichern.
“[der Provider] sollte [...] sicherstellen, dass nur diejenigen das dürfen, die sich vorher auf andere Weise autorisiert haben und ich sollte für menschliche oder technische Unzulänglichkeit Routinen entwickeln, die die Daten davor schützen, dass diese versehentlich durch einen anderen User überschrieben werden.”
Aber genau dies haben doch die entsprechenden Zugriffsrechte zu tun. Und wenn ich dem Server sage: “Jeder darf meine Daten verändern.”, dann ist es doch nicht verwunderlich, wenn er genau dies auch erlaubt, oder?
“ich genieße die Bequemlichkeit via FTP und HTTP auf Daten und Ordner frei zugreifen zu können.”
Wer grundlegende Sicherheit aufgibt um vorübergehen ein wenig Bequemlichkeit zu haben, verdient weder Sicherheit noch Bequemlichkeit. (frei nach Benjamin Franklin)
Auch wenn es vielleicht nicht ganz stimmt, wenn Provider “777″ deshalb sperren um andere Nutzer zu schützen, so finde ich es trotzdem verantwortungsvoll. Außerdem, wer sagt, dass meine “krimilelle Energie” einfach nicht ausreicht, entsprechende Szenarien zu ersinnen.
Die wirklich bösen Jungs und Mädels könnten sich noch viel schlimmere Dinge ausdenken…
Es ist doch tatsache, dass ich erst ein Skript auf meinem Server brauche, dass auf dem Server etwas geschrieben werden kann. Und auch bei anonymous-FTP braucht man einen Zugang zum Webspace und nicht zum FTP-Space, der völlig separat läuft.
Ich habe wirklich nun schon viel gesucht und immer läuft es darauf hinaus, dass mit 777 allein keine Sicherheitslücke vorhanden ist. Ich kann immer noch nicht von einem beliebigen Ort ein Skript starten und in dem Verzeichnis oder in der Datei Änderungen bewirken. Ich benötige entweder schon ein Skript auf meinem Server oder aber einen Zugang, der in der Regel Passwortgeschützt ist.
Ein anderes Thema mögen shared Server sein, wie man das mit den Feld-Wald-und-Wiesen-Angeboten bei Providern hat. Aber soweit ich es überblicke gibt es hier hinreichend Möglichkeiten diese Partitionen auf dem Server von einander abzuschotten.
Bleibt ein Restrisiko, dass die Abschottung nicht dicht genug ist oder aber dass durch Leichtfertigkeit bei Skripten mit Schreib- upload-Funktionen fremde Skripte geimpft werden können um beim kriminiellen Akt zu bleiben.
Hier aber kann ich nur sagen, dass dieses Thema bei allen Software-Themen zum tragen kommt und man sich so oder so immer in einer Wettstreit-Situation steckt.
CHMOD 777 kann ich beim besten Willen nicht als so großes Sicherheitsloch sehen, wie es dargestellt wird. Es hat noch keiner klar benennen können, das CHMOD für sich genommen ein Risiko ist. Ich kann CHMOD vollkommen sicher unter bestimmten Voraussetzungen einsetzen, oder doch mit einem absolut vertretbaren Risiko.
CHMOD 777 kommt mir vor wie das Thema User-Rechte in großen Firmen. Auch dort werden die Rechte meist mehr als nötig eingeschränkt und die Arbeitflüsse systematisch behindert. Monitoring kann übrigens ohne allzugroßen Aufwand auch unmittelbar per SMS auf jedes Handy aufschlagen, sobald auf die Platte etwas anderes geschrieben wird als die Zugriffslogdatei. Dann haben die kriminellen Subjekte keine 23 Stunden.
Sollte jetzt auch hier das Totschlagargument kommen, dass man mein Passwort ausspionieren könnte und man so zugriff erhielte, dann kann ich nur dazu sagen, dass Passwort ausspionieren immer geht und nicht nur bei mir, sondern auch im Herzen des Providers. Schließlich surft der Admin von seinem Arbeitsplatz nicht selten ins Netz und das recht frei. Ich habe bei einem Provider gearbeitet und kenne den Alltag.
“Es ist doch tatsache, dass ich erst ein Skript auf meinem Server brauche, dass auf dem Server etwas geschrieben werden kann.”
-> Ja. Und alle die auf dem gleichen Server einen Account haben, können genau diese Skripte erstellen, oder?
“Ein anderes Thema mögen shared Server sein, wie man das mit den Feld-Wald-und-Wiesen-Angeboten bei Providern hat.”
-> Ich ging davon aus, dass Du genau davon schreibst. Wer einen exklusiven Server hat, dem schreibt der Provider ja auch nicht die Zugriffsrechte vor, oder?
“Schließlich surft der Admin von seinem Arbeitsplatz nicht selten ins Netz und das recht frei.”
-> Wohin das führt, das haben wir ja jetzt bei OSX gesehen. Und wir zwei sind uns denke ich auch ziemlich einig, dass Admin-surfen höchst ungesund ist. Deshalb diskutiern wir über Zugriffsrechte…