# [securite] machine gentoo hackée

## damsos

Bonjour à tous,

je me suis fait hacké ma machine  :Sad: 

des que je la branche au net, elle bombarde le reseau en tentatives de connection ssh (j'ai bloqué le protocole sur la livebox), qui rend

celui ci inutilisable.

Auriez vous un conseil à donner pour essayer de recupérer la situation ?

merci,

----------

## netfab

Au final, le meilleur conseil que tu auras sera de réinstaller le système. Fais toi une raison tout de suite  :Smile: 

----------

## sunseb7

Tu as une idée de comment tu as pu te faire hacker ?

----------

## aCOSwt

Pour commencer avec 2 centimes...

1/ Bloque le(s) ports concernés

2/ lsat te raconte-t-il des choses intéressantes

3/ Identifier les processus qui utilisent le(s) ports concernés

----------

## kwenspc

C'est toujours chiant cette utilisation du mot "hack" à tord et à travers... laissez ça aux journaleux qui ne pigent rien à rien.

Tu t'es fais piraté (hijhacked si tu veux) mais pas "hacké".

----------

## Poussin

 *kwenspc wrote:*   

> C'est toujours chiant cette utilisation du mot "hack" à tord et à travers... laissez ça aux journaleux qui ne pigent rien à rien.
> 
> Tu t'es fais piraté (hijhacked si tu veux) mais pas "hacké".

 

Je pertinente vigoureusement!

----------

## damsos

lsat ne donne rien de particulier. (merci pour le conseil)

je ne sais pas trop comment c'est arrivé, peut etre parceque

j'avais laissé le port ssh ouvert sur la livebox avec un mdp root un peu

trop evident.

C'est la premiere fois que je me fais rooté, ca me servira de lecon.

----------

## aCOSwt

 *damsos wrote:*   

> 
> 
> C'est la premiere fois que je me fais rooté, ca me servira de lecon.

 

Fais tourner un coup de app-forensics/chkrootkit

----------

## damsos

toujours rien  :Sad: 

----------

## aCOSwt

Quand ta bécane bombarde le réseau, tu dois avoir un certain nombre de sockets actives.

- Si besoin est, trouve les toutes avec find

- Puis passe fuser sur chacune d'elles.

----------

## Fenril

Mon post ne sert à rien mais je suis curieux : comment cela peut arriver ? Non pas dans le sens que j'émets de jugement, mais pour parer éventuellement si cela m'arrivais.

----------

## damsos

j'avais un process louche ssh

blackcube ~ # lsof -i :22

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

i       23916 root    2u  IPv4 257699      0t0  TCP blackcube.livebox.home:50889->ANantes-553-1-175-57.w2-0.abo.wanadoo.fr:ssh (ESTABLISHED)

des que j'ai tué le process, l'exploit a recommencé immediatement a bombarder en ssh.

il y'a des appels sur des machines louches genre ilove15.selfip.com

----------

## geekounet

À part le temps de chercher l'origine du piratage (à priori t'as déjà une petite idée de ce que c'était : pass root trop simple), ça ne sert à rien de garder l'install en vie. Dans tous les cas, il faut réinstaller à zéro rapidement pour être sur de ne garder aucune trace des trojans/rootkits installés et éviter ainsi que ton IP soit rapidement blacklistée partout.

----------

## damsos

en fait c'etait un rootkit signé "Opyum Team" installé automatiquement qui lancait  via cron

du spam avec sendmail, plus de peur que de mal, mais j'ai compris la lecon  :Wink: 

merci pour tous les conseils.

Damsos

----------

## guilc

Hmmmmmmm

Ce n'est pas parceque tu as trouvé ça en crontab que c'est la seule saleté sur ton système.

On va paraître lourds mais.. la SEULE option est le formatage et réinstallation au propre... Avec bien sûr la correction de l'origine du piratage !

Tu ne peux absolument pas considérer le système comme sain sans ça. C'est une règle de base dont on ne peut pas faire l’économie, même si ça fait perdre du temps !

----------

## aCOSwt

 *damsos wrote:*   

> en fait c'etait un rootkit signé "Opyum Team" installé automatiquement qui lancait  via cron
> 
> du spam avec sendmail

 

Bravo à toi !

Comment l'as-tu trouvé ?

----------

## nexus6

 *guilc wrote:*   

> Hmmmmmmm
> 
> On va paraître lourds mais.. la SEULE option est le formatage et réinstallation au propre... 

 

Et encore ... je dirais que c'est juste le 'minimum' (paraîtrait que certains malware soient très "résidents" ...).

Je suppose que tu perdra autant de temps si ce n'est plus, à rechercher d'autres malware ou à analyser les comportements du système sur la couche réseau (sans parler des faux-positifs), que de ré-installer un système au propre avec tous les avantages que cela apporte en comparaison aux inconvénients : repartir à zéro c'est pour au final retomber sur quelque chose qui sera toujours mieux... car on évite de faire les mêmes erreurs :p

----------

## d2_racing

Oui, la meilleur chose à faire c'est un beau format.

Regarde aussi si tu peux pas backuper ton home si ce n'est déjà fait.

----------

## mysix

Install fail2ban si tu ouvres ton ssh sur le net.

----------

## geekounet

Le backup du home c'est à faire avant de se faire pirater, ça sert à rien après. Restaurer un /home d'une machine piratée peut tout autant ramener des saletés.  :Smile:  On ne récupère pas un seul bit d'une machine piratée, on fait une réinstall complète et on récupère les données depuis un backup sain.

----------

## Zentoo

Au passage si ca peut aider pour le forensic:

Vérification des paquets système:

```
qcheck $(qlist -CI)
```

Lister les fichiers hors système:

```
diff -y <(find / -xdev | sort) <(qlist $(qlist -CI) | sort)
```

----------

## Zentoo

Bon en fait j'ai vu directement sur la box de damsos (le jour même) et il s'agissait d'une compromission du mot de passe SSH root trop faible.

L'intrusion était grossière et automatique (heureusement...).

En voici l'arbre des processus observé après blocage par iptable du port 22 (donc SSH) en sortie:

  |-cron

  |   `-cron

  |       |-f Opyum Team

  |       |  |-(f)

  |       |  |-(f)

  |       |  |-(f)

.......................

  |       |  |-(f)

  |       |  `-i

  |       |     |-i

  |       |     |-i

.......................

  |       |     |-i

  |       |     |-i

  |       |     `-i

  |       `-sendmail -FCronDaemon -odi -oem -oi -t

Trouver les binaires incriminés a été simple car il s'agissait de binaires 32 bits statiques sur un système 64 bits comportant majoritairement des binaires dynamiques. Une rapide passe sur les directory du PATH suivi d'un "file" ont permis de voir les binaires utilisés. De plus l'attaque de type "attaque par dictionnaire sur un port SSH ouvert" était rudimentaire.

En effet, le binaire "f" était flagué "immutable" sur les attributs étendus et la commande "chattr" permettant de changer cet état avait disparue (confirmé par un "qcheck sys-fs/e2fsprogs"). une recompilation du package incriminé ré-installant la commande, le binaire a pu être déplacé et effacé sans problème.

En fait le but du déploiement de l'attaque était de constituer un botnet par attaque systématique des ports SSH de plages d'adresses choisies en fonction d'une communication par mail. Hors sur la box incriminé, aucun mailer système n'était configuré donc la commande sendmail de base issue du paquet mail-mta/ssmtp renvoyait les mails vers le fichier "/root/deadletter". Aucune info n'est donc partie directement empechant la box de communiquer avec le reste du botnet et donc d'être plus coopérante dans le choix des plages réseaux cibles.

Le côté positif malgrès tout et que l'attaque étant rudimentaire et automatique, le système n'a pas eu le temps d'être conpromis en profondeur par un rootkit ou un cheval de troie. En effet à part le coup du binaire immutable et l'effacement de chattr, rien de bien compliqué mis a part le code des binaires (gros en l'occurence car embarquant les composantes du dictionnaires d'attaque). La signature de la "team" du botnet affiché dans l'arbre des processus montre bien le niveau de l'attaque. Préférer se faire de la pub que de se cacher efficacement en dis long sur les personnes qui sont derrière....

J'ai confié les binaires à des personnes spécialisées pour en savoir plus et voir si il serait possible de détruire le botnet en avertissant les possesseurs de box incriminés. J'essayerai de vous tenir au courant si vous êtes intéréssé.

Il n'empêche que conserver la trace des md5sums de l'ensemble des fichiers du système reste toujours une bonne chose en cas d'attaque. Normalement cet ensemble de traces étant stockés hors du serveur. Gentoo utilise un mécanisme partiel de traces de type md5sum pour l'intégrité des packages et pour connaître entre autre si des fichiers de conf sont à modifier ou pas (etc-update, dispach-conf). On peut donc facilement vérifié l'intégrité des packages installés. Il reste néanmoins à vérifier les fichiers hors packages du système ainsi que les fichiers du /home. Des logiciels tels que app-forensics/aide (remplacant du devenu commercial tripwire) permettant d'automatiser ce type de vérification.

----------

## aCOSwt

@Zentoo : Bravo ! Epaté je suis !

Au passage de ta découverte du binaire flaggé, les extended attributes cela pourrait finalement s'avérer aussi chiant qu'utile alors ?

----------

## Zentoo

En fait les attribus étendus sont très utiles pour avoir des droits plus fins que les droix unix posix classiques.

Tu peux par exemple flagué des fichiers tels que les logs pour qu'il ne soit pas effacés ou modifiés et dans lesquels tu ne peux que rajouter des données (mode append).

Ces attributs s'avèrent très utiles dans l'administration système et notamment pour la sécurité.

Néanmoins si un attaquant est root, il peut faire aussi bien que toi si il comprend/remarque les attributs que tu as mis.

Donc oui c'est utile mais il faudrait enlever les binaires le permettant pour qu'une compromission root ne permette pas de contourner ce qui a été choisi. C'est le rôle des mécanismes de type ACL que tu retrouves dans les politiques de sécurité comme SELINUX ou GRSEC qui permettent dans la pratique de limiter même root lui même.

----------

## aCOSwt

 *Zentoo wrote:*   

> Donc oui c'est utile mais il faudrait enlever les binaires le permettant pour qu'une compromission root ne permette pas de contourner ce qui a été choisi. C'est le rôle des mécanismes de type ACL que tu retrouves dans les politiques de sécurité comme SELINUX ou GRSEC qui permettent dans la pratique de limiter même root lui même.

 

 :Shocked: 

Donc en gros, un mec plus clever que moi en acl + xattrs (et c'est facile puisque en la matière je suis plus que n00b) peut, grâce à cela, faire de sorte que je ne contrôle plus ma propre bécane   :Exclamation: 

J'ai compris ! je vire tout cela lors de ma prochaine compilation noyau ! Et j'en reviens à un système comme j'en avais un (rwxr-x---) du temps... où on se préoccupait plus de gagner une milliseconde dans une routine qu'à penser à contrôler la bécane du voisin...   :Twisted Evil: 

On pourra alors peut-être prendre le contrôle de ma bécane en tant que root... mais... au minimum... on ne pourra m'empecher de l'être aussi...   :Razz: 

Merci encore à toi Zentoo pour ton travail et les explications   :Cool: 

----------

## Zentoo

 *aCOSwt wrote:*   

> 
> 
> Donc en gros, un mec plus clever que moi en acl + xattrs (et c'est facile puisque en la matière je suis plus que n00b) peut, grâce à cela, faire de sorte que je ne contrôle plus ma propre bécane  
> 
> J'ai compris ! je vire tout cela lors de ma prochaine compilation noyau ! Et j'en reviens à un système comme j'en avais un (rwxr-x---) du temps... où on se préoccupait plus de gagner une milliseconde dans une routine qu'à penser à contrôler la bécane du voisin...  
> ...

 

Cela ne servirai à rien... les attributs étendus sont là pour permettre des droits plus précis et étendus que ce que propose unix par défaut.

Si quelqu'un devient root sur ta machine, il a le contrôle tout simplement. Le coup d'effacer le chattr étant vraiment ridicule car cela se detecte facilement et surtout se remplace d'un coup d'emerge. Le but est plutot d'utiliser chattr (entre autre) pour sécuriser ton système pour que personne ne devienne root. Par exemple passer en mode "append" tous les logs empeche un attaquant de facilement effacer une partie des traces de son intrusion.

----------

