Forum Linux.debian/ubuntu et merde... un script kiddie !

Posté par ploum (site web personnel, Mastodon) le 30 janvier 2005 à 21:41.

Étiquettes : aucune

jan.

2005

Ben voilà. Pour causes d'exams, j'ai pas mis à jour mon serveur sous Sarge et voilà qu'un script-kiddie qui passait par là à profiter d'une faille dans awstat pour defacer tous les sites webs du serveur.

J'ai, du coup, mis à jour tout le serveur, bouchant par la même occasion une faille de cyrus.

Mais voilà, j'ai des couilles dont je ne sais pas si elles sont issues du piratage ou de la mise à jour.
Tous les détecteurs de rootkits restent muets, ça me rassure un peu.

Le binaire "logger" avait disparu ainsi que le répertoire /var/log. Un mkdir et un reinstall de bsdutils plus tard, plus de prob.

Mais :

apache refuse de se lancer (
Cannot load /usr/lib/apache/1.3/mod_log_config.so into server: /usr/lib/apache/1.3/mod_log_config.so: cannot open shared object file: No such file or directory )

et je n'arrive pas à résoudre le problème.

De plus, quand on se connecte par ssh, le password est toujours refusé les 3 première fois. (moi j'utilise les clés, c'est qqn d'autre qui m'a soufflé ça)

ploum@vulsini:~$ ssh ploum@frimouvy.org
Password:
Password:
Password:
ploum@frimouvy.org's password:
(et là, à la 4ème fois, ça marche)

Je n'arrive pas à trouver le problème. J'ai réinstallé login sans succès.

Bref, je demande de l'aide pour tout ça. De plus, que faire dans pareille situation ? Tous les conseils sont les bienvenus !

AU SECOURS !!!!

# j'oubliais..

Posté par ploum (site web personnel, Mastodon) le 30 janvier 2005 à 21:45. Évalué à 3.

Les logs de cyrus se remplissent de :

Jan 30 21:43:38 sol cyrus/lmtpd[29089]: FATAL: lmtpd: unable to init duplicate delivery database
Jan 30 21:43:38 sol cyrus/lmtpd[29090]: DBERROR: dbenv->open '/var/lib/cyrus/db' failed: DB_RUNRECOVERY: Fatal error, run database recovery
Jan 30 21:43:38 sol cyrus/lmtpd[29090]: DBERROR: init /var/lib/cyrus/db: cyrusdb error

et j'ai tenté un cyrreconstruct, mais sans succès.. :-(
Mes livres CC By-SA : https://ploum.net/livres.html
# pour courroner le tout...

Posté par ploum (site web personnel, Mastodon) le 30 janvier 2005 à 21:58. Évalué à 3.

Je me décide de faire un petit upgrade de fritalk.com, mon second serveur :

apt-get update
zsh: bus error apt-get update

Toutes les opérations apt-get me renvoie cette erreur ! Je suis maudit aujourd'hui :-(
Mes livres CC By-SA : https://ploum.net/livres.html
- [^] # Re: pour courroner le tout...
  
  Posté par doublehp (site web personnel) le 31 janvier 2005 à 05:10. Évalué à 1.
  
  $ dpkg -S /usr/lib/apache/1.3/mod_log_config.so
  apache-common: /usr/lib/apache/1.3/mod_log_config.so
  
  ->
  apt-get --reinstall install apache-common apt
  
  si apt refuse de marcher, telecharge le pakage apt.deb sur le site de debian, et installe le a la main:
  
  dpkg -i apt_*.deb
  
  puis:
  $ apt-cache show apt
  Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.4.1-3), libstdc++5 (>= 1:3.3.4-1)
  si reinstaller apt_*.deb ne resouds pas le pb, tu reinstall ces 3 dependances de la meme maniere, ou tu attaques:
  dpkg -S zsh
  puis reintalle a la main ceux qui te paraissent pertiments. Mais je n y crois pas.
  
  Pour finir, comme d autres te l ont conseille:
  compromission = reinstall
# Hum ...

Posté par Maillequeule le 30 janvier 2005 à 22:00. Évalué à 10.

Même si tu n'avais aucun problèmes avec ta machine, je n'aurais qu'un conseil à donner :

Machine compromise => formatage.

Maintenant tu fais ce que tu veux ...

M
- [^] # Re: Hum ...
  
  Posté par ploum (site web personnel, Mastodon) le 30 janvier 2005 à 22:06. Évalué à 2.
  
  Le problème c'est que c'est un serveur distant, et donc c'est pas évident du tout du tout.
  
  D'autres part, l'exploit utilisé ne donnait "que" les privilèges de www-data, pas de root
  Mes livres CC By-SA : https://ploum.net/livres.html
  - [^] # Re: Hum ...
    
    Posté par Bruno Michel (site web personnel) le 30 janvier 2005 à 22:34. Évalué à 5.
    
    Comment a-t-il fait pour effacer le répertoire /var/log et le binaire logger s'il n'avait que les droits de www-data ? Personnellement, je considérerais qu'il a utilisé un autre exploit pour gagner le root.
    
    Si tu es sur qu'il n'a eu que les droits de www-data, recherche tous les fichiers lui appartenant, fait en une sauvegarde, supprime-les et réinstalle ce qu'il faut.
    
    Mais l'idéal reste quand même un reformatage + une réinstallation complète.
    - [^] # Re: Hum ...
      
      Posté par ploum (site web personnel, Mastodon) le 30 janvier 2005 à 22:40. Évalué à 2.
      
      ben je ne suis pas sur que ce soit lié. J'ai fait un dist-upgrade un peu bourrin après l'attaque et c'est là que tous les problèmes ont commencés.
      
      J'aurais pas du faire l'upgrade direct, ça c'est vrai. J'y ai pensé un peu trop tard :-(
      Mes livres CC By-SA : https://ploum.net/livres.html
  - [^] # Re: Hum ...
    
    Posté par Maillequeule le 30 janvier 2005 à 23:30. Évalué à 4.
    
    Le problème c'est qu'à partir de maintenant, et même si tu ne trouves rien, tu ne peux plus considérer ton serveur comme sûr (en supposant qu'on le puisse à un moment donné).
    
    L'effacement de /var/log avec les droits www-data, ca me laisse songeur (ou alors c'était une installation de goret) :)
    
    Si tu es, comme je le suppose, sur un serveur dédié chez un hébergeur, tu peux te renseigner sur le coût d'une reinstall de la machine ... C'est peut être un faible prix à payer (au sens propre et figuré) pour repartir sur de bonnes bases.
    
    En attendant, considère ta machine comme morte, à moins d'aimer jouer avec le feu. Faire une analyse post-mortem, oui, mais une remise en production, certainement pas.
    
    M
  - [^] # Re: Hum ...
    
    Posté par Krunch (site web personnel) le 31 janvier 2005 à 15:52. Évalué à 5.
    
    Ca serait quand même une bonne idée de réinstaller tout parce que rien ne garanti qu'une faille locale n'a pas été utilisée pour rootkiter la machine avec un truc qui n'est pas détecté par chkrootkit et compagnie.
    
    Un moyen relativement sûr de faire la réinstallation à distance serait de commencer par compiler CryptCat ainsi que les binaires de base (BusyBox est ton ami) statiquement sur une machine sûre et les uploader sur la machine compromise. S'arranger pour ne plus utiliser que ces programmes. Notamment ne plus utiliser le sshd original qui peut avoir été compromis aussi. Tu devrais pouvoir obtenir un shell par cryptcat avec un truc genre "# cryptcat -e /safe/bin/sh -l -p 1234 -k mekmitasdigoat" et "$ cryptcat -k mekmitasdigoat example.org 1234". De la tu peux faire un chroot qui te forcerait à utiliser, les nouveaux binaires, dans ce cas, ne pas oublier de faire les mknod qui vont bien avant de passer à la suite.
    
    Debootstraper un système Debian de base sur une machine sûre, le mettre sur un système de fichiers qui va bien, uploader la "partition" sur la machine compromise à traver CryptCat, genre "# cryptcat -k mekmitasdigoat -l -p 4321 -q0 > /safe/dev/hda2" et "$ cryptcat -k mekmitasdigoat example.org 4321 < debian-base.ext3" avec hda2 une partition "libre" que tu as démontée préalablement (genre n'importe quoi sauf /, éventuellement la partition de swap si elle est assez grosse, pas oublier de faire un swapoff avant). Maintenant tu peux monter la partition, chrooter vers le nouveau système et installer le bootloader. Ensuite yapluka rebooter et prier.
    
    Si tu réussis, tu peux être raisonnablement sûr que tu as un système de bases propre. Si tu es paranoïaque, tu peux imaginer que le rootkit est au niveau du noyau et qu'il sait réinfecter un nouveau système que tu installes à partir de programmes non compromis ou que le sshd sait infecter les programmes qu'il voir passer de manière à ce qu'ils infectent à leur tour les fichiers qu'ils manipulent ou qu'il y a un daemon caché qui injecte du code malsain dans tous les nouveaux processes qu'il voit apparaitre ou qu'il y a quelqu'un connecté par une backdoor qui surveille ou bien... mais alors ya plus grand chose à faire à part réinstaller vraiment "from scratch".
    
    A l'avenir pour diminuer les risques de compromission complète du système quand un daemon se fait exploiter tu peux mettre un maximum de truc dans des "jails chroot" ou mieux: des machines virtuelles en utilisant User-Mode-Linux par exemple. Par ailleurs le manuel de sécurisation Debian contient plein de trucs intéressants et faire tourner Sarge sur un serveur disponible depuis internet n'est peut-être pas une très bonne idée (oui je sais Woody est pas à jour mais au moins il y a des màj de sécurité et apt-get peut être mis dans un cron sans risque).
    
    Bon amusement :/
    
    Bien entendu je ne saurais être tenu pour résponsable des dégats éventuels causés par l'applications de ce que j'ai décrit plus haut.
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
    - [^] # Re: Hum ...
      
      Posté par ploum (site web personnel, Mastodon) le 31 janvier 2005 à 16:51. Évalué à 2.
      
      finalement, on a opté pour la réinstallation par OVH. ça coute plus cher, mais c'est plus rapide et sans risque.
      
      En plus, comme je dois aussi réinstaller tout fritalk.com, je suis pas à ça prêt...
      
      Mais je note scrupuleusement tes conseils, merci :-)
      Mes livres CC By-SA : https://ploum.net/livres.html
# rkhunter

Posté par Dekany Brice le 30 janvier 2005 à 22:29. Évalué à 1.

Je te conseile d'utiliser "rkhunter" il fait des checks des binaires et des rootkits connus
- [^] # Re: rkhunter
  
  Posté par ploum (site web personnel, Mastodon) le 30 janvier 2005 à 22:32. Évalué à 3.
  
  j'ai essayé. Il n'a rien trouvé si ce n'est un warning dans les modules de mon noyaux. Ceux-ci sont :
  
  ext2 51176 1 (autoclean)
  dm-mod 29608 0 (unused)
  8139too 15240 1
  mii 2464 0 [8139too]
  crc32 2912 0 [8139too]
  rtc 7112 0 (autoclean)
  ext3 82536 2 (autoclean)
  jbd 42980 2 (autoclean) [ext3]
  ide-detect 288 0 (autoclean) (unused)
  piix 8904 1 (autoclean)
  ide-disk 16928 4 (autoclean)
  ide-core 111228 4 (autoclean) [ide-detect piix ide-disk]
  unix 15500 316 (autoclean)
  
  et ça semble correct.
  Mes livres CC By-SA : https://ploum.net/livres.html

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.