HACKED BY iSKORPiTX

Hallo,
@Iarumas: Egal was man in der php.ini eingestellt hat, solch ein Code ist und bleibt sau gefährlich, da ein Angreifer alles laden darf, was er möchte.

Merken:
Niemals darf ein User beliebige Inhalte/Dateien laden, sondern er darf maximal aus einer Liste von Dateien (Array, Datenbank) aussuchen, welche Datei geladen werden soll, sprich er übergibt keinen Dateinamen, sondern i.d.R. eine ID.
 
Original von Iarumas
Ich würde auf jedenfall Empfehlen "allow_url_fopen" in der php.ini auf Off zu stellen.

Gegen Lokale Includes bringt das trotzdem nichts. Hast du beispielsweise noch eine weitere Lücke in einem Upload-Skript kann er einfach eine "böse Datei" hochladen und die über dieses Skript includen. Solche Szenen zeigen, dass dein Skript potentiell gefährlich und unsicher ist.
Elderan hat eigentlich schon alles zu den Lösungsmöglichkeiten gesagt, daher gehe ich da nun nichtmehr drauf ein.
 
Ist schon klar das es nichts gegen lokale Includes bringt doch trotzdem wäre es ein Schritt in die richtige Richtung

Bzw wenn so ein Bug in einem Upload Script existiert wird der Angreifer eher weniger noch n Include machen müssen sondern die Datei direkt ausführen oder? :S
 
Und wenn die datei in ein Verzeichnis ausserhalb des document_root geladen wird, das der Angreiffer moeglicherweise kennt oder erraten kann?

Und nein: Es ist kein Schritt in die richtige Richtung. Es ist immernoch eine ernstzunehmende Sicherheitslücke, die den ganzen Server gefährden kann.
 
Hallo,
auch beliebige lokale Includes sind extrem gefährlich, hab dazu mal vor kurzen hier einen netten Post geschrieben, der viele Sicherheitslücken von solchen Includes aufweist

Original von Elderan aus Sicher vor CrossSiteScripting?
Hallo,
naja, nicht wirklich... es ist nur dann unsicher, wenn irgendwelche hohlbratzen von webhostern die möglichkeiten der nutzung von mod_security, openbasedir, seperaten temp-/session-dirs und die sperrung von befehlen wie shell_execute usw. ungenutzt lassen.

auch dann ist es Unsicher.

Immer wenn der User entscheiden kann, welche Dateien includiert werden, ist dies unsicher.
Denn, was viele nicht glauben, viele erstellte Dateien sind einfach nicht dafür geeignet, inkludiert zu werden, denn dadurch werden ja auch Variablen überschrieben.

Bsp:
PHP:
<?php
//Vars initialisieren
$log = false;

//Include
include("funktionen.php");
include('content/'.$_GET[path]'.php');


if($_SESSION['admin'] == "jo")
   $log = true;


if($log == true)
  //Zeige Adminfunktionen
else
  //Erst einloggen
?>


Wenn ein Angreifer es jetzt schafft, irgendeine Datei zu finden, in der die Variable $log geändert wird, auf einen Wert != false (z.B. 1,2...), dann kann man sich als Admin einloggen, ohne das Passwort zu haben.

Oder anderes Beispiel:

PHP:
<?php
//Vars initialisieren
$username = $_SESSION['username'];
$userid = $_SESSION['userid'];

//Include
include("funktionen.php");

//....


//Menü ausgeben
include('content/'.$_GET[path]'.php');



if(isset($username))
  //Zeige Member-Bereich für $username
else
  //Erst einloggen
?>
Wenn man jetzt eine Datei findet, in der $username deklariert wird, und diese includiert, so kann man sich einloggen.

Eine Datei kann z.B. so aussehen:

member_search.php:
PHP:
<?php
$username = $_GET['username'];

$suche = "SELECT * FROM users WHERE username = '$username'";
//...
?>


Mit dem Aufruf:
seite_mit_bug.php?username=Admin&path=member_search

Könnte ich mich als 'Admin' einloggen.


Man muss jede Datei überprüfen, ob diese inkludiert werden kann.
Wenn der User selbst die Datei bestimmen kann, muss man jede Datei überprüfen, ob diese Problemlos per include() geladen werden kann.



Sowie:
Im zweiten Advisory beschreiben die Entwickler, wie ein Angreifer mit Schreibrechten im TWiki-System durch eine rekursive Include-Anweisung in der editierten Seite innerhalb weniger Minuten den Webserver vollständig lahmlegen kann. Dieser fülle durch die wiederholte Einbindung derselben Seite seinen gesamten Hauptspeicher und erhole sich typischerweise erst nach einem vollständigen Neustart von dem Angriff.

Sicherheitslücken in TWiki vom 28.03.06
Advisory der TWiki-Entwickler

Wenn du also nicht verhinderst, dass per include immer wieder die eigene Seite geladen wird, kann dies schnell in einem Server Crash enden.


Wenn der Server dann noch schlecht konfiguriert ist, kann der Angreifer z.B. auch sensible Daten per include laden.
Ein mittelmäßig bekannter Freehoster war so konfiguriert, dass man über solch eine Attacke z.B. beliebige Datenbanken, also die Dateien in denen die Einträge gespeichert waren, per include laden konnte.
Oder der Angreifer lädt per include die /etc/passwd und sieht schonmal so, welche User es am System gibt usw.
Wobei es bei dem Freehoster es komfortabler wäre, sich einen kostenlosen Account einzurichten und dann per PHP-Shell-Konsole die Dateien von anderen Usern, auch deren Datenbankpasswörter, auszulesen.
 
Zurück
Oben