Y a-t-il encore des développeurs utilisant des url vulnérables à la faille include

Version imprimable

14/03/2011, 13h57
randriano

Y a-t-il encore des développeurs utilisant des url vulnérables à la faille include

Bonjour,

Je parle d'URL vulnérables: monsite.com/index.php?page=xxxx
Ce n'est pas seulement vulnérable à la faille include mais aussi au "directory tranversal" qui permet au hacker de remonter vers des répertoires sensibles en utilisant ".."

L'include à distance fonctionne-t-il encore aujourd'hui? monsite.com/index.php?page=http://autre_site.com/page

Est-ce que include() teste l'extension du fichier qu'on lui fait inclure? car les pirates réussissent souvent à uploader un fichier image contenant du php qu'ils vont forcer à inclure
14/03/2011, 14h39
grunk

Citation:

Envoyé par randriano

Bonjour,
L'include à distance fonctionne-t-il encore aujourd'hui? monsite.com/index.php?page=http://autre_site.com/page

Professionellement parlant j'ose espérer que non. Il me semble également qu'une directive du php.ini empêche l'utilisation d'url distante, donc il est fort probable que ce soit activer par défaut sur tous les mutualisé.

Citation:

Est-ce que include() teste l'extension du fichier qu'on lui fait inclure?

Non tu peu inclure ce que tu veux. Tu peux faire du php avec des fichier .prout si ton serveur est configuré pour ^^
14/03/2011, 15h51
randriano

1 pièce(s) jointe(s)

J'ai posté ce fil car je n'arrive pas jusqu'à maintenant à comprendre comme un hacker a pu uploadé des fichiers ELF Linux, Perl et PHP sur un site que je maintiens!

Le plus bizarre c'est qu'il arrive à remplacer mon index.php mais comment?

Le hacker:
Pièce jointe 74411
14/03/2011, 16h00
grunk

Sympathique comme message...

Plusieurs solutions possible mais les plus probable :

- Un upload de fichier est disponible sur ton site et il n'est pas sécurisé correctement (mime type , csrf ...)

- Tes identifiants FTP on été volé , il y'a quelques temps un trojan existait qui utilisait filezilla. Il insérait un bout de JS à l'upload d'un fichier , ce JS envoyait les identifiant serveur vers un serveur distant...

- Faille XSS sur ton site ayant permis la récupération de cookie contenat des informations sur tes identifiants.
14/03/2011, 19h52
randriano

Citation:

Envoyé par grunk

Sympathique comme message...

Plusieurs solutions possible mais les plus probable :

- Un upload de fichier est disponible sur ton site et il n'est pas sécurisé correctement (mime type , csrf ...)

Je ne crois pas que ce soit mes identifiants volés ni un vol de cookie (XSS), le premier tiret m'intrigue le plus!
Il y a effectivement des upload mais filtrés, seuls les fichiers .pdf, .xls ou .doc peuvent passer, bien sûr on peut uploader un fichier php à extension .pdf mais en principe on ne pourra pas l'exécuter! Sauf comment?
14/03/2011, 20h44
pablofr

Question :

- Tu utilise un CMS ?
- Est ce que tu vérifie uniquement le TypeMime quand tu upload un fichier en PHP ?
- Est ce que tu es sur un hébergement Mutualisé ?
- Quel est le propriétaire des derniers fichier uploadé ? et index.php

mais en principe on ne pourra pas l'exécuter

Pourquoi pas ?

Quel sont les droits dans le dossier où tu peux uploader ?

As-tu rajouter un .htaccess pour bloquer spécifiquement l'utilisation de php dans ce dossier ?

Si vraiment tu veux qu'on regarder envoi l'adresse de ton site en PM

A+
15/03/2011, 08h27
randriano

Citation:

Envoyé par pablofr

Question :

- Tu utilise un CMS ?
- Est ce que tu vérifie uniquement le TypeMime quand tu upload un fichier en PHP ?
- Est ce que tu es sur un hébergement Mutualisé ?
- Quel est le propriétaire des derniers fichier uploadé ? et index.php

mais en principe on ne pourra pas l'exécuter

- Non, je développe en PHP pur!
- Oui je vérifie le TypeMime uniquement
- Oui mutualisé
- C'est le webmaster qui uploade les fichiers et je confirme qu'il n'a uploadé que des fichiers sûrs!
15/03/2011, 08h41
grunk

Citation:

Envoyé par randriano

- Non, je développe en PHP pur!
- Oui je vérifie le TypeMime uniquement
- Oui mutualisé
- C'est le webmaster qui uploade les fichiers et je confirme qu'il n'a uploadé que des fichiers sûrs!

De quelle manière vérifie tu le type mime ? Les 2 seules solutions efficaces sont l'utilisation de fileinfo ou alors la lecture de l'entête du fichier uploader (qui revient à ce que fileinfo fait mais lui à une bdd des types). Toutes les autres (extension ,entête http ...) sont usurpable assez facilement.

Ton script d'upload est il efficacement sécurisé ? J'entends par là :
- Dois je être identifié
- Dois je avoir un niveau d'accès particulié
- Puis je appeller le script à distance en lui fournissant les paramètre de mon choix ? (en gros ton script est il lié au formulaire de ton site via un token ?)
15/03/2011, 09h21
randriano

Citation:

Envoyé par grunk

Ton script d'upload est il efficacement sécurisé ? J'entends par là :
- Dois je être identifié
- Dois je avoir un niveau d'accès particulié
- Puis je appeller le script à distance en lui fournissant les paramètre de mon choix ? (en gros ton script est il lié au formulaire de ton site via un token ?)

Oui
15/03/2011, 09h39
RunCodePhp

Salut

Citation:

Envoyé par pablofr

Quel sont les droits dans le dossier où tu peux uploader ?
As-tu rajouter un .htaccess pour bloquer spécifiquement l'utilisation de php dans ce dossier ?

Tu n'as pas répondu à cette question, et vu que le fichier index.php aurait été modifié, je me dis que ça vaut le coup d'insister.

Je suis tout de même très loin d'être un spécialiste (absolument pas un admin système) mais il me semble que pour modifier un répertoire ou un fichier, il faut d'abord avoir les droits.
- Donc soit le gars l'a obtenu en y accédant directement via FTP, là ça suppose qu'il ait obtenu le login/pass, mais apparemment tu dis que ce n'est pas possible.
- Soit les droits sur les fichiers/répertoire seraient trop permissifs.

Pour info, de mon coté, j'essaie de toujours prendre soin de les limiter comme ceci :
chmod 0444 sur tous les fichier et chmod 0666 sur les répertoires.
Un chmod de 0444 ne permet pas de modifier un fichier même par son propre code Php.
Enfin, théoriquement. ;)

De même que tu ne répond pas si coté .htaccess tu as des "Deny from all" au niveau de tes répertoires.

A coté de ça, il a tout sortes de technique qui théoriquement limitent les problèmes, mais ça demande de le prévoir, de concevoir son projet en circonstance.
Donc là encore pour info, de mon coté je mets vraiment un minimum de fichier au niveau du Host (soit www ou htdoc bien souvent), comme le index.php, les images, JS, Css.
En somme, uniquement les fichiers qui doivent être accéssible via HTTP.
Tout le reste, soit : fonctions, classes, etc ... est en dehors du Host, donc par définition inaccessibles via HTTP (il faut passer par le index.php).
Toute cette structure est protégée/renforcée par un .htaccess (deny all).
De plus, j'y rajoute en début de ligne de tous les fichier Php un code comme :

Code:

defined('UNE_CONSTANTE_QUI_DOIT_EXISTER') or exit('Aucun accès directe.');

Un somme, depuis quelque temps ma réflexion est la suivante : Si un fichier ne doit pas être accessible via HTTP, il n'a rien à faire dans le Host (ou virtualhost).
Rien que ça, ceci devrait éviter qu'un pirate puisse ne serait-ce lire le contenu du fichier, qui sait on jamais, peut très bien contenir des infos confidentielles (le pire, mettre son log/pass de MySQL ou FTP).

Ensuite, coté code Html généré en Php, prendre soin d'utiliser les fonctions htmlspecialschar ou htmlentities, car on le sait, un petit malin peu rajouter du code JS en paramètre, et sans ça il peu toujours être interprété et exécuté.
Etdes techniques il y a en bien d'autres, que finalement les codeurs/développeurs ne connaissent pas, ou mal, bien souvent.

En faite, je me dis qu'il sera peut être très difficile de savoir comment le gars à fait pour te modifier du contenu.
Je me dis alors qu'il serait bon de faire le point sur les règles de bases de la sécurité :
Droits sur les fichiers/répertoires, le .htaccess avec les restrictions qu'il doit avoir, la structure du site,
etc, etc ...
Il doit bien avoir des parties quelque peu permissives, non ?

Citation:

Envoyé par RunCodePhp

Salut

Tu n'as pas répondu à cette question, et vu que le fichier index.php aurait été modifié, je me dis que ça vaut le coup d'insister.
.................
Pour info, de mon coté, j'essaie de toujours prendre soin de les limiter comme ceci :
chmod 0444 sur tous les fichier et chmod 0666 sur les répertoires.
Un chmod de 0444 ne permet pas de modifier un fichier même par son propre code Php.
Enfin, théoriquement. ;)

Bon, je n'ai pas utilisé de .htaccess pour ça mais pour de l'url rewriting mais il y a un fichier index.html dans chaque sous-dossier du site!
Voici le contenu du .htaccess dont je suis entrain de déposer dans chaque dossier
Code:

1 2 3 4 5 6 7 8 9 IndexIgnore * RemoveHandler .php .phtml .php3 RemoveType .php .phtml .php3 php_flag engine off <Files ~ "^.*\.(cgi|pl|php[3-5]{0,1}|shtm?l?|aspx?|cfml?|jsp?)$"> order allow,deny deny from all </Files>
Concernant les droits, j'y ai pas touché mais y a-t-il des risques sauf si l'attaque est linux (SSH) ou FTP non?

15/03/2011, 21h56
pablofr

Pour faire vite ce soir car pas beaucoup de temps

- Oui je vérifie le TypeMime uniquement -> Très grosse faille de sécurité
- Oui mutualisé -> Donc ca peux aussi vernir de ton voisin sur la même plate de forme; certain hébergement (même très connue) protège mal leur mutualisé

- J'insiste sur le Propriétaire du faire index.php à l'heure où il a été modifier :
Soit il a changer et est www-data ou apache
Soit c'est toujours ton nom d'utilisateur FTP
si c'est www-data ou apache c'est qu'il est bien passé par php
si non FTP -> Je te parle de cela car il y pas mal de vers qui recupe les mots de passe FTP sur les machine. Ils sont très efficace et discret. A ma connaissance il y a que Avast Free qui les détecte bien.

- Si tu as les fichiers logs lance une recherche dedans de : %20

Et j'allais oublier, la version php de ton hébergement ?
16/03/2011, 06h56
randriano

Citation:

Envoyé par pablofr

Pour faire vite ce soir car pas beaucoup de temps

- Oui je vérifie le TypeMime uniquement -> Très grosse faille de sécurité
- Oui mutualisé -> Donc ca peux aussi vernir de ton voisin sur la même plate de forme; certain hébergement (même très connue) protège mal leur mutualisé

Malheureusement c'est le risque du mutualisé!!!

Très grosse faille de sécurité???!!! En effet, il me semble qu'on ne peut tester que les gif|jpg|png mais si c'est du pdf|xls|doc aucun moyen de détecter si c'est un faux.