Commentaires sur : Exploitation de faille include avec les sessions PHP

Par : Nuit du hack - Challenges publics - -[The lsd]-

Nuit du hack - Challenges publics - -[The lsd]- — Wed, 21 Jul 2010 17:54:46 +0000

[...] d’apache. Rien de concluant. le site n’utilise pas de sessions, donc, on ne peut pas inclure non plus les fichiers de session. J’essaye d’inclure d’autres fichiers, comme /p/.htaccess pour apprendre que le [...]

Par : Emilien Girault

Emilien Girault — Sat, 30 Jan 2010 22:47:01 +0000

Le PHPSESSID est un identifiant de session généré par le serveur et stocké par le client le plus souvent sous forme de cookie. Il permet de retrouver les données de la session de l’utilisateur qui sont stockées sur le serveur, donc non accessibles directement. Ce sont les données du tableau $_SESSION en PHP. Sur le serveur, ces données sont stockées dans des fichiers, généralement dans /var/lib/php5/. Leur nom est devinable en connaissant le PHPSESSID (cf ce que je dis dans l’article). Et ce qu’il y a de bien, c’est que ces fichiers sont toujours accessibles par Apache (sinon les sessions ne peuvent pas fonctionner).

Dans cette exploitation, on n’injecte donc pas dans le PHPSESSID, mais dans les données qui vont être sauvegardées en session. Dans mon cas, il se trouve que le concepteur du site stockait le login tel quel dans la session. Il était possible d’y insérer du code PHP. Ce sont donc les fichiers de session que l’on va chercher à inclure en utilisant la LFI (qui reste bien une LFI, pas une RFI). Ainsi on peut exécuter le code que l’on veut.

Pour sécuriser la LFI, il faut simplement éviter les appels à include() (et autres du même genre) avec des variables directement contrôlables, à moins de faire une vérification poussée sur le fichier. Vérifier si le fichier existe sur le serveur ne suffit pas, comme on vient de le voir (c’est le principe même de la LFI). Une bonne idée peut être de vérifier son extension, ou bien de s’assurer qu’il n’est pas plus haut que souhaité dans l’arborescence (filtrer les caractères / par exemple).

Par : cr0t4lux

cr0t4lux — Sat, 30 Jan 2010 12:32:15 +0000

Salut,

pourrais-tu m’en dire plus sur l’inclusion dans le phpsessid? J’ai un peu de mal à imaginer une interception des requêtes pour lui balancer l’adresse d’une backdoor.

Apparemment, dans ton article, le site cible était vulnérable à une LFI, mais aux travers de la variable, tu lui lances une RFI non?

Un peu plus de précision sur la manière dont tu as procéder serait le bienvenue Ainsi que la sécu, tu peux, car sinon dans un fichier secu.php (admettons en mvc, donc appliqué directement à toutes les pages) tu devrait sécurisé phpsessid sur xss, lfi, rfi.

Meilleures salutations,

P.S: Félicitation pour l’insomni’hack

Par : FlUxIuS

FlUxIuS — Tue, 22 Sep 2009 20:01:16 +0000

Lool t’as challengé le challenge lui même : ça le fou mal…

En Angleterre par contre je tombes sur un problème de sécu récurant : Robustesse des mots de passes négligée, plus récupération simple des accès PPPoA, y’a de quoi ce faire plaisir + surveillance mail (j’ai de jolis screenshots).

Au final => Plus rien ne me choque!

Par : Heurs

Heurs — Fri, 18 Sep 2009 18:00:07 +0000

Sur les serveurs LAMP ca passe pas pour l’exploitation par les logs, mais sur la majorité des WAMP ca marche par contre

Par : virtualabs

virtualabs — Thu, 17 Sep 2009 12:34:51 +0000

Ce type d’exécution de code PHP est moins connu que l’exécution de code par les logs (qui fonctionne même sur des systèmes autres que AMP, type Coldfusion), mais les conditions requises pour l’exploitation sont plus draconniennes: emploi des sessions par le site, stockage dans les sessions de contenu non filtré (un htmlentities empêche cette exploitation), sans oublier la modification de la configuration par défaut. Cette dernière n’est pas un problème si on a accès à la configuration PHP.

Tout ca pour dire que p0wner des serveurs de challenge, bah saimal. Même si la méthode pour y parvenir est quelque peu exotique.

Par : Yann

Yann — Wed, 16 Sep 2009 21:36:55 +0000

Pas mal de souçis de sécu il est vrai, mais il est vrai aussi que de sécuriser 100% est très compliqué.

Enfin rapidement l’openbasedir c’est pas du luxe et tu n’aurais pas réussi aussi facilement (même si il y a toujours moyens). Après il y a toujours moyen de mettre dans une jail le tout mais ça commence à devenir un peu plus compliqué.

Pour finir la sécurité uniquement du point de vue système n’est pas la bonne solution, trop de dev le pensent, beaucoup de solution éxiste dans le code pour parer à un bon nombre d’attaque (mysql_real_escape; vérif du contenu des variables; etc …)