Y a-t-il un moyen de lire un script php a dis tance ?

Pascal PONCET a écrit :
(snip)

J'en veux pour preuve l'audit récent d'un site Web qui a révélé une
faille toute bête (en restant poli) :

(snip)

<code>
// script "getJpeg.php" (à la racine web)
header("Content-type: image/jpeg");
$url = $_GET["url"];
readfile("img/".$url);
</code>

Mouarfffff !!!!

> Dingue, non ?

digne du dailyWTF.

Denis Beauregard a écrit :

Le 02 Mar 2009 15:10:54 GMT, slambert
<slambertNOSPAMPLEASE@vediovis.net> écrivait dans fr.comp.lang.php:

Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive

J'avoue avoir du mal à voir comment un plantage de l'interpréteur PHP -
qu'il soit déployé comme module apache (le cas le plus courant, de loin)
ou comme CGI - pourrait donner un tel résultat. La conséquence la plus
probable serait un 500, et la pire (si déployé comme module apache) un
plantage d'apache lui-même.

Le 03 Mar 2009 10:25:22 GMT, Bruno Desthuilliers
<bruno.42.desthuilliers@websiteburo.invalid> écrivait dans
fr.comp.lang.php:

Denis Beauregard a écrit :

Le 02 Mar 2009 15:10:54 GMT, slambert
<slambertNOSPAMPLEASE@vediovis.net> écrivait dans fr.comp.lang.php:

Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive

J'avoue avoir du mal à voir comment un plantage de l'interpréteur PHP -
qu'il soit déployé comme module apache (le cas le plus courant, de loin)
ou comme CGI - pourrait donner un tel résultat. La conséquence la plus
probable serait un 500, et la pire (si déployé comme module apache) un
plantage d'apache lui-même.

Une recherche sur google donne ceci :

Résultats 1 - 10 sur un total d'environ 2 320 000 pour php exploit

Il y a donc un grand nombre de possibilités de rupture de sécurité
en PHP.

Je suppose qu'il peut y avoir parmi elles, la possibilité que le
serveur PHP laisse passer le code tel quel, sans l'interptéter.

Mais en fait, la panne la plus simple, c'est si on a mal configuré
le serveur (par exemple lors de l'installation d'une nouvelle
version) et qu'à ce moment, donc pendant un court laps de temps,
les .php sont comme des .html et passent tels quels, sans
interprétation. Cela arrive souvent aux débutants qui essaient
leur code à la maison sans avoir installé de serveur PHP et cela
peut arriver sur un serveur qui ne supporte pas le PHP et où on
installe du code provenant d'un autre serveur sans le tester.


Denis

>> http://www.ush.it/team/ush/hack-phpfs/phpfs_mad.txt

Il me semble, que cette méthode d'attaque, ne pourrait fonctionner qu'avec
un script situé sur le même serveur que celui de mon site.

En l'occurence, surtout d'une [ho]|[e]rreur de codage. Ce qui est donné
comme POC c'est que dans le cas où on a (bêtement) utilisé l'algo suivant,
alors on peut passer outre à cause d'un comportement inattendu:

"Si l'extension du fichier est n'importe quoi sauf '.php' alors on peut
exécuter [ceci]"

Mais là pas de pot, l'extension c'est .php/ ou .php/. donc il y a
exécution de [ceci]. Si justement le [ceci] c'est un readfile par exemple,
alors là c'est cuit car on reçoit alors le code de n'importe quel fichier
en clair sans exécution.

C'est une application de "liste noire", liste de choses interdites (ici,
l'extension .php) qui est à la source de la faille avant tout.
Si on avait dit "seules les extensions .html .txt .truc" avec une liste
exhaustive et explicite des extensions autorisées, on n'aurait pas vu le
gag.

Effectivement le serveur de mon site a le patch Suhosi, mais encore
faudrait-il, que le hacker prenne le risque, alors que mon hébergeur
veille...

Qu'il veille, ça ne sert pas à grand chose, il faut surtout qu'il
configure ses rootjails correctement...

Si le hacker est abonné au même service d'hébergement que moi, Sivit aura
ses coordonnées, le risque est moins grand.

Il peut autant y avoir attaque locale suite à compromission d'un autre
site hébergé sur la même machine qu'une attaque délibérée d'un
"colocataire". Seules les barrières mises en place par l'hébergeur pour
que les "colocataires" ne *puissent pas** se voir permettront de s'en
prémunir.

En fait, mettre le script dans un espace hors web serait une mauvais idée,
si effectivement le hack qu'indique votre lien, fonctionne.

Mettre un script en dehors de l'aborescence garanti qu'il ne sera jamais
appelé en direct par http, rien (et moins) de plus.

Dès lors qu'un attaquant arrive à détourner un script pour se balader dans
l'arborescence en lui passant des arguments, ou il exécute du code de
manière incontrôlée si l'injection est faite via require ou include, ou il
lit directement le contenu des fichiers s'il injecte dans readfile ou
passthrough.

a++;
JG

Pascal PONCET a écrit :

Dingue, non ?
Avec un navigateur, autre que MSIE (???), il suffit de demander
"http://www.lesite.nul/getJpeg.php?url=../index.php" puis hop, un coup
de "voir source" sur la page blanche de résultat, et on a tout le code
PHP en clair avec les "include" (qu'on peut remonter de la même manière
pour voir les codes d'accès SGBD, etc.).

Donc une vraie catastrophe en terme de sécurité !
Alors, le ".htaccess" ou autre dans tout ça, il faut relativiser.

Cordialement,
Pascal

Bonjour Monsieur

C'est sûr, que le readfile en local, et l'envoi direct du contenu du
paramètre $url, constitue un très gros trou de sécurité...

En ce qui me concerne, d'une part mes include sont toujours codés en
dur, et d'autre part, il n'y a pas de readfil dans mes scripts. ;)

En fait, les graphiques automatiques générés sur mon site, viennent
effectivement de contenus rendus avec le header approprié, mais le
contenu, lui, est strictement déterminé par la Course sur laquelle on
est, est comme ce contenu est calculé, il ne correspond pas au contenu
d'un quelconque fichier, déterminable d'une façon ou d'une autre par un
apramètre $_GET, mais ce contenu n'a aucune relation directement
exploitable, avec le paramètre en question, qui détermine le contenu.

De plus, dans mon cas, ce contenu rendu par les graphiques, est
toujours une image, jamais le contenu d'un fichier.

Ce que vous indiquez là, est simplement un très gros trou de
sécurité, que Monsieur Gallet appréciera à a juste valeur... ;)

Bien à vous.

Amicalement.

Jean-François Ortolo

"Denis Beauregard" <denis.b-at-francogene.com.invalid@nospam.com.invalid>
wrote

Une recherche sur google donne ceci :
Résultats 1 - 10 sur un total d'environ 2 320 000 pour php exploit
Il y a donc un grand nombre de possibilités de rupture de sécurité
en PHP.

Je dois dire que ces résultats concernent des exploits pour des applications
écrites en PHP. Cela ne provient pas de la technologie. Modulo un petit
souci réglé dans les 24 heures à l'automne dernier, l'architecture
PHP/Apache elle même est plutôt saine depuis plusieurs années.



Les mauvaises pratiques sont indépendantes du langage et vous retrouverez le
même genre d'erreur de conception dans les autres architectures.

Dans tous les cas concernant le point à l'origine de ce fil de discussion,
le risque repose sur une non interprétation des scripts par le serveur
(mauvaise configuration, plantage, etc...).

Ceci dit, placer tous les fichiers en dehors du répertoire accessible par
Apache, et les appeler via un contrôleur qui vérifiera que tout se basse
bien, c'est une bonne idée. Dans le cas d'un véritable disfonctionnement du
serveur, seul le/les contrôleurs sont accessibles.

MVC rulez, mais c'est une opinion personnelle, et ce uniquement quand le
projet le nécessite (taille, longueur, etc...)

S.L.

John GALLET a écrit :

Il peut autant y avoir attaque locale suite à compromission d'un autre
site hébergé sur la même machine qu'une attaque délibérée d'un
"colocataire". Seules les barrières mises en place par l'hébergeur pour
que les "colocataires" ne *puissent pas** se voir permettront de s'en
prémunir.

Ok

Si je comprend bien, je peux toujours tester si ce type d'attaque
fonctionne, en testant moi-même sur mon hébergement en essayant de
charger le source du fichier caché avec l'extension *.php/. à partir
d'un script php ad hoc.

Si l'attaque réussit, je ne peux pas de toute façon savoir, s'il est
possible à un colocataire de lire dans mon arborescence de fichiers, à
moins de le demander à mon hébergeur.

A moins que je n'essaye moi-même de hacker de cette manière un autre
compte, encore faudrait-il que je sache le nom du compte...

Donc, dans l'ensemble, je préfère m'abstenir, et demander à mon
hébergeur si cette possibilité de lecture hors de son espace ftp est
possible, mais là je pense qu'il y a 100% de chances, pour que
l'hébergeur réponde: "non".

...Sinon, je peux toujours vérifier si le mode de php est suphp,
auquel cas, il me suffira de virer les permissions en
lecture/écriture/exxécution, sur autre chose que le propriétaire. ;)

Un coup de phpinfo.php fera l'affaire. ;)

Merci beaucoup de votre aide.

Respectueusement.

Jean-François Ortolo

Jean-Francois Ortolo a écrit :

...Sinon, je peux toujours vérifier si le mode de php est suphp,
auquel cas, il me suffira de virer les permissions en
lecture/écriture/exxécution, sur autre chose que le propriétaire. ;)

Un coup de phpinfo.php fera l'affaire. ;)

Effectivement

Le phpinfo() indique que deux variables d'environnement $_SERVER['
'] et $_ENV[' '] ( me souviens plus des deux mots exacts ) comportant
le token "SUEXEC_" sont bien positionnées.

Celà confirme ce que je pensais, me souvenant avoir lu quelque part
dans la doc de l'hébergeur de cette nouvelle plate-forme PHP 5 MySQL 5,
que le mode suexec est actif.

Celà est égalemet confirmé par le fait, que j'ai mis les permissions
du script à cacher, à: 700, et le script est encore fonctionnel, ce qui
indique que l'interpréteur php fonction avec le même iud que le
propriétaire du compte ftp.

...Le propriétaire du compte ftp étant d"sormais le seul à pouvoir
accéder à ce script, je n'ai même plus à me poser la question de savoir
si des colocataires peuvent "voir" ce script.

Je pense, qu'en ce qui me concerne, cette constatation clos ma question.

Bien à vous.

Amicalement.

Jean-François Ortolo

Denis Beauregard a écrit :

Le 03 Mar 2009 10:25:22 GMT, Bruno Desthuilliers
<bruno.42.desthuilliers@websiteburo.invalid> écrivait dans
fr.comp.lang.php:

Denis Beauregard a écrit :

Le 02 Mar 2009 15:10:54 GMT, slambert
<slambertNOSPAMPLEASE@vediovis.net> écrivait dans fr.comp.lang.php:

Sinon, imaginez que l'on puisse appeler à distance les scripts dans le but
de voir leur contenu, ce sera catastrophique.

Euh, il suffit qu'il y ait une panne de l'interpréteur pour que cela
arrive

J'avoue avoir du mal à voir comment un plantage de l'interpréteur PHP -
qu'il soit déployé comme module apache (le cas le plus courant, de loin)
ou comme CGI - pourrait donner un tel résultat. La conséquence la plus
probable serait un 500, et la pire (si déployé comme module apache) un
plantage d'apache lui-même.

Une recherche sur google donne ceci :

Résultats 1 - 10 sur un total d'environ 2 320 000 pour php exploit

Il y a donc un grand nombre de possibilités de rupture de sécurité
en PHP.

Je suppose qu'il peut y avoir parmi elles, la possibilité que le
serveur PHP laisse passer le code tel quel, sans l'interptéter.

PAQJS, la seule possibilité que cela arrive (sauf faille de sécurité
*dans le code de l'appli elle-même*) serait une erreur de config apache.

Mais en fait, la panne la plus simple, c'est si on a mal configuré
le serveur

Ce qui n'est pas une panne.

(par exemple lors de l'installation d'une nouvelle
version) et qu'à ce moment, donc pendant un court laps de temps,
les .php sont comme des .html et passent tels quels, sans
interprétation. Cela arrive souvent aux débutants qui essaient
leur code à la maison sans avoir installé de serveur PHP et cela
peut arriver sur un serveur qui ne supporte pas le PHP et où on
installe du code provenant d'un autre serveur sans le tester.

Encore une fois, ce sont erreurs humaines, pas une panne logiciel. Rien
à voir avec un "plantage de l'interpréteur PHP".

Re,

Si je comprend bien, je peux toujours tester si ce type d'attaque
fonctionne, en testant moi-même sur mon hébergement en essayant de charger le
source du fichier caché avec l'extension *.php/. à partir d'un script php ad
hoc.

Je donnais cette faille concernant les include/require de fichier de nom
invalide uniquement parce qu'il est connexe à la notion d'extension
(.truc) pas comme exemple absolu de "l'attaque qui réussit à tous les
coups". Je souhaitais seulement illustrer deux points:

- ne jamais se baser sur l'apparence extérieure d'un fichier pour
déterminer s'il est exécuté ou non (si j'ai un .txt je peux d'une part
configurer apache pour qu'il l'exécute comme un .php et d'autre part
utiliser require/include pour lui faire exécuter le code qu'il contient)

- ne jamais utiliser de listes noires (principe: "on autorise tout sauf"),
uniquement des listes blanches (principe: "on interdit tout sauf").

En l'occurence, du moment qu'on arrive à lire le répertoire du dessus de
son compte et qu'on y voit les colocs, ou à se balader dans l'arborescence
globale de la machine, il n'y a pas les pré-requis d'isolation entre les
différents comptes pour un hébergement "en milieu hostile" (c'est à dire
ouvert à n'importe qui dès lors qu'il paye). Ca peut suffire dans certains
cas, mais pas chez un hébergeur en mutualisé.

On sort ici du cadre de ce forum et des réponses plus appropriées seraient
disponibles sur fcs.

Donc, dans l'ensemble, je préfère m'abstenir, et demander à mon hébergeur
si cette possibilité de lecture hors de son espace ftp est possible, mais là
je pense qu'il y a 100% de chances, pour que l'hébergeur réponde: "non".

Je dirais plutôt 40% car il y a aussi 60% de chances qu'il ne réponde
jamais ;-)

Petit point au passage sans pub (je n'ai pas d'actions chez eux): quand on
voit que le premier prix du serveur *dédié* chez ovh par exemple c'est
23,91 euros TTC (même mon abonnement de ligne fixe Farce Telecom est plus
cher !) on peut se poser de grosses questions sur l'intérêt de
l'hébergement mutualisé dès lors qu'on a des données un tant soi peu
confidentielles. C'est bien une question d'équilibre, on est d'accord.

a++;
JG