Je suppose, bien que vous ne le disiez pas, que vous avez été piraté et que vous cherchez des moyens d'éviter que cela ne se reproduise.
Je ne pense pas que vous puissiez contrôler le type de fichier qu'Apache exécutera de cette manière, si vos gestionnaires sont configurés de telle sorte qu'ils considèrent que tout ce qui se trouve dans un répertoire est un CGI. Si vous modifiez vos gestionnaires de sorte que seuls les fichiers avec un certain type d'extension soient interprétés comme des exécutables CGI, l'attaquant pourrait simplement changer le nom du fichier. Linux interprétera tout exécutable à peu près de la même manière, donc tant qu'il a un en-tête ELF ou un shebang en haut, ou qu'il est autrement exécutable, son nom n'a pas vraiment d'importance (et apache n'a pas besoin de s'en soucier non plus). Ainsi, empêcher apache d'exécuter Shell Shell n'est pas facile à faire (je ne pense pas que ce soit réellement possible). En outre, le véritable problème était qu'un attaquant était en mesure de mettre des fichiers arbitraires dans des emplacements de confiance sur votre ordinateur.
Ce que je vous suggère de faire, c'est de déterminer comment cela s'est produit. Avec les plugins wordpress, cela peut être de plusieurs façons. Par exemple, il a certainement pu être téléchargé en utilisant un compte FTP ou SSH volé. Il a également pu être téléchargé par le biais d'un rootkit (c'est pourquoi je reconstruis toute boîte qui a été piratée). Cependant, étant donné qu'il s'agit de Wordpress, le scénario le plus probable est beaucoup plus stupide.
Lorsque wordpress est autorisé à se mettre à jour et à mettre à jour ses plugins, et à installer du contenu en utilisant son interface web, vous vous ouvrez à cette possibilité. Si quelqu'un obtient l'accès à un compte wordpress privilégié, ou usurpe un serveur à partir duquel ce contenu peut être téléchargé, ou ajoute simplement sa charge utile à un plugin et attend que vous fassiez la mise à jour, vous vous êtes fait avoir. Bien que wordpress semble apprécier cette fonctionnalité, moi et tous ceux que je connais dans le domaine de l'infosécurité recommandons fortement qu'elle soit désactivée ; apache ne devrait jamais avoir un accès en écriture à son propre webroot, et cela est particulièrement vrai pour les emplacements CGI.
