Frage Warum ist chmod 777 in einem PHP / Apache / Linux-Kontext gefährlich?


Inspiriert von der Diskussion in diese Frageeine vielleicht dumme Frage.

Uns allen wurde beigebracht, dass Verzeichnisse oder Dateien auf Linux-basiertem Webhosting mit der Berechtigungsstufe von 777 ist eine schlechte Sache, und immer so wenig Berechtigungen wie nötig einzustellen.

Ich bin jetzt neugierig, wo genau Lügen die Gefahr der Ausbeutung, speziell in einem PHP / Apache-Kontext.

Schließlich kann eine PHP-Skriptdatei von außen (d. H. Über einen Aufruf an den Webserver und anschließend an den Interpreter) ausgeführt werden, unabhängig davon, ob sie als "ausführbar" markiert ist, oder? Das Gleiche gilt für Dateien, die über die Befehlszeile aufgerufen werden php Dolmetscher, oder?

Also wo genau ist die Schwachstelle mit? 777? Ist es die Tatsache, dass andere Benutzer auf demselben Computer auf Dateien zugreifen können, die weltweit beschreibbar sind?


43
2018-02-26 00:20


Ursprung


Antworten:


Hier ist ein Szenario:

  1. Sie haben ein ungeschütztes Verzeichnis, in das Benutzer hochladen können.
  2. Sie laden zwei Dateien hoch: ein Shell-Skript und eine PHP-Datei mit einem system() rufe es zum Shell-Skript auf.
  3. Sie greifen auf das PHP-Skript zu, das sie gerade hochgeladen haben, indem sie die URL in ihrem Browser aufrufen, wodurch das Shell-Skript ausgeführt wird.

Wenn dieses Verzeichnis 777 ist, bedeutet dies, dass jeder (einschließlich des Benutzer-Apache, welches php-Skript als ausgeführt wird) es ausführen kann! Wenn das Ausführungsbit nicht auf diesem Verzeichnis und vermutlich den Dateien innerhalb des Verzeichnisses gesetzt ist, würde Schritt 3 oben nichts tun.

Bearbeiten Sie aus den Kommentaren: Es ist nicht die Berechtigungen der PHP-Datei, die zählt, es ist die system() Rufen Sie innerhalb der PHP-Datei, die als Linux-Systemaufruf von der Linux-Benutzer-Apache ausgeführt wird (oder was auch immer Sie Apache festgelegt haben, als auszuführen), und das ist GENAU, wo das Ausführungsbit wichtig ist.


27
2018-02-26 00:31



Es gibt viele gute allgemeine Gründe, dem Minimalismus zu folgen, wenn es um Berechtigungen geht, aber im Zusammenhang mit einem LAMP-Webhost sind die wenigen, die einem sofort in den Sinn kommen

  • Auf einer Shared-Hosting-Plattform können andere Benutzer, die Ihren Host freigeben, nun Ihre Skripts lesen und schreiben.
  • Auf einem dedizierten Host können Rouge-Prozesse Ihre Dateien lesen / schreiben und versehentlich löschen. Nehmen wir an, es gibt einen benutzerdefinierten Logging-Prozess im Hintergrund als Benutzer niemand, der einen Fehler hat, der dazu führt, dass es versucht rm -rf /. Im Allgemeinen wird dies harmlos sein, da es kaum eine Datei geben würde, für die niemand Schreibrechte haben sollte, aber dieser Rouge-Prozess wird jetzt Ihre Dateien mitnehmen.
  • Um Ihre Website zu entstellen, muss jemand nur als Benutzer Zugang erhalten, auch niemand oder ein solches Pseudo-Konto sagen. Im Allgemeinen müsste der Angreifer einen weiteren Eskalationsangriff auf Benutzerebene durchführen, um an den Ort zu gelangen, an dem er Schaden anrichten kann. Dies ist eine echte Bedrohung. Einige nicht kritische Dienste werden möglicherweise unter Dummy-Konten ausgeführt und enthalten möglicherweise eine Sicherheitsanfälligkeit.

2
2018-02-26 00:32



Es erhöht das Anfälligkeitsprofil Ihrer Website erheblich gegenüber bösartigen Aktivitäten, da nur ein einziges Konto geöffnet werden muss.

Jeder, der mit jedem Login Zugang zu Ihrem System erhält, kann auf Ihren Seiten alles machen, was er möchte, einschließlich der Änderung zu lesen "Diese Website ist wirklich unsicher, also geben Sie mir bitte Ihre Kreditkarteninformationen."

EDIT: (Um zu klären und Kommentare zu adressieren)

Viele Server haben mehr als einen Zweck im Leben. Sie führen mehrere Dienste aus. Wenn Sie diese Dienste sorgfältig voneinander trennen, indem Sie jedem einen eindeutigen Benutzer zuweisen und die Dateiberechtigungen entsprechend verwalten, sind Sie immer noch in heißem Wasser, wenn jemand die Anmeldeinformationen für ein Konto kompromittiert, aber der Schaden, den sie verursachen, auf diesen einen Dienst beschränkt ist . Wenn Sie nur einen generischen Account haben und das gesamte Dateisystem auf 777 setzen, gefährdet ein kompromittierter Account alles auf dem Rechner.

Wenn Ihr Server nur dafür vorgesehen ist, Apache / PHP auszuführen und keinen anderen Zweck im Leben erfüllt und es nur einen Account gibt, unter dem Apache / PHP ausgeführt wird, ist die Kompromittierung dieses einen Accounts so gut wie die Kompromittierung des gesamten Rechners Standpunkt Ihrer Anwendung (obwohl Sie immer noch Systemdateien geschützt und nicht beschreibbar durch das Konto, mit dem PHP ausgeführt werden soll, sollte das immer noch nur für ein Admin-Konto / root möglich sein).

Wenn sie eine Datei schreiben können und sie ausführbar ist, können sie sie in etwas ändern, das auf Ihrem Computer ausgeführt wird (ausführbare Datei oder Skript) und dann PHPs Shell_exec verwenden, um diese ausführbare Datei auszuführen. Wenn Sie konfiguriert sind, shell_exec nicht zuzulassen, können sie Ihre Konfiguration ebenfalls ändern


2
2018-02-26 00:22



Nehmen wir an, Sie haben ein Softwarepaket auf Ihrem Server installiert, und es gibt eine Zero-Day-Schwachstelle. Der Angreifer erhält Zugriff auf Ihre Admin-Systemsteuerung mit Funktionen zum Hochladen von Dateien. Wenn Sie alles auf 777 setzen, wäre es für ihn einfach Shell-Skript, wo immer er will. Wenn Sie die Berechtigungen jedoch richtig einstellen, kann er dies nicht tun, da niemand / www-data / etc keine Schreibberechtigung hat.


0
2018-01-21 20:17