Comment faire un post-mortem d'un piratage de serveur


29

J'ai une machine Windows Server 2003 SP2 avec IIS6, SQL Server 2005, MySQL 5 et PHP 4.3 installé dessus. Ce n'est pas une machine de production, mais elle est exposée au monde via un nom de domaine. Le bureau à distance est activé sur la machine et deux comptes administratifs y sont actifs.

Ce matin, j'ai constaté que la machine avait été déconnectée avec un nom d'utilisateur inconnu toujours dans la zone de texte de connexion. Après une enquête plus approfondie, j'ai découvert que deux utilisateurs de Windows ont été créés, que l'antivirus a été désinstallé et qu'une poignée de fichiers .exe ont été déposés dans le lecteur C :.

Ce que j'aimerais savoir, c'est quelles mesures dois-je prendre pour m'assurer que cela ne se reproduise plus, et quels sont les domaines sur lesquels je dois me concentrer pour déterminer la voie d'entrée. J'ai déjà vérifié netstat -a pour voir quels ports sont ouverts, et rien n'y paraît bizarre. J'ai trouvé des fichiers inconnus dans le dossier de données pour MySQL qui, je pense, pourrait être le point d'entrée mais je ne suis pas sûr.

J'apprécierais vraiment les étapes pour effectuer un bon post-mortem d'un piratage de serveur afin que je puisse éviter cela à l'avenir.

Examen après enquête

Après une enquête, je pense avoir découvert ce qui s'est passé. Tout d'abord, la machine n'était pas en ligne pendant la période d'août 08 à octobre 09. Pendant cette période, une vulnérabilité de sécurité a été découverte, la vulnérabilité MS08-067 . "Il s'agit d'une vulnérabilité d'exécution de code à distance. Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait prendre le contrôle complet d'un système affecté à distance. Sur les systèmes Microsoft Windows 2000, Windows XP et Windows Server 2003, un attaquant pourrait exploiter cette vulnérabilité sur RPC sans authentification et pourrait exécuter du code arbitraire. " Cette vulerabilité a été corrigée avec la mise à jour de sécurité KB958644 publiée en octobre 2008.

Étant donné que la machine était hors ligne à ce moment-là et a raté cette mise à jour, je pense que cette vulnérabilité a été exploitée peu de temps après la remise en ligne de la machine en octobre 2009. J'ai trouvé des références à un programme bycnboy.exe qui a été décrit comme un programme de porte dérobée qui crée alors beaucoup de ravages sur un système infecté. Peu de temps après la mise en ligne de la machine, des mises à jour automatiques ont installé le correctif qui a supprimé la possibilité de contrôler à distance le système. Parce que la porte dérobée était maintenant fermée, je pense que l'attaquant a ensuite créé des comptes physiques sur la machine et a pu utiliser la machine pendant une semaine supplémentaire jusqu'à ce que je remarque ce qui se passait.

Après avoir agressivement recherché le code malveillant, les .exes et les .dll, supprimé les sites Web et les comptes d'utilisateurs auto-hébergés, la machine est à nouveau dans un état de fonctionnement. Dans un avenir proche, je surveillerai le système et examinerai les journaux du serveur pour déterminer si une répétition de l'incident se produit.

Merci pour les informations et les étapes qui vous ont été fournies.

Réponses:


28

Faire un post-mortem est un art noir en soi. C'est un peu différent à chaque fois car vraiment deux cambriolages ne sont pas identiques. Dans cet esprit, un aperçu de base de mon processus recommandé est ci-dessous, avec quelques notes spécifiques à votre situation:

  1. Déconnectez physiquement la machine du réseau. (Vraiment. Faites-le maintenant.)
  2. Étape facultative: faites une copie d'image binaire du disque dur pour une utilisation future.
  3. Faites une copie de tous les fichiers journaux, des données précieuses, etc. sur un disque dur amovible
    • Copiez éventuellement tous les "outils de piratage" que vous trouvez également
  4. Commencez l'autopsie réelle. Dans ton cas:
    • Notez tous les comptes d'utilisateurs nouveaux ou manquants. Voyez si leurs dossiers personnels ont un contenu "intéressant".
    • Notez tous les programmes / binaires / fichiers de données nouveaux ou manquants.
    • Vérifiez d'abord les journaux MySQL - Recherchez tout ce qui est "inhabituel"
    • Vérifiez le reste des journaux du serveur. Vérifiez si vous pouvez trouver les nouveaux utilisateurs en cours de création, les adresses à partir desquelles ils se sont connectés, etc.
    • Rechercher des preuves de dommages ou de vol de données
  5. Lorsque vous trouvez la cause du problème, notez comment l'empêcher de se reproduire.
  6. Nettoyez le serveur: formatez et réinstallez tout, restaurez vos données et collez le trou d'origine avec vos notes de # 5.

Vous effectuez généralement l'étape 2 si vous prévoyez d'impliquer les forces de l'ordre. Vous effectuez l'étape 3 afin de pouvoir consulter les informations une fois le serveur reconstruit sans avoir à lire la copie d'image que vous avez effectuée à l'étape 2.

Le niveau de détail de l'étape 4 dépend de vos objectifs: le simple fait de boucher le trou est un type d'enquête différent que de rechercher qui a volé des données précieuses :)

L'étape 6 est critique à mon humble avis. Vous ne "réparez" pas un hôte compromis: vous l'effacez et recommencez à partir d'un bon état connu. Cela garantit que vous ne manquerez pas une pépite de méchant laissée sur la boîte comme une bombe à retardement.

Il ne s'agit en aucun cas d'un schéma post-mortem complet. Je le marque comme wiki communautaire car je cherche toujours des améliorations au processus - je ne l'utilise pas souvent :-)


3
Je n'ai aucune expérience dans ce domaine, mais le conseil de Security Monkey si vous envisagez d'imaginer une machine pour enquête est de tirer le cordon d'alimentation, d'imager le disque dur, puis de commencer à enquêter. (Security Monkey: it.toolbox.com/blogs/securitymonkey )
MattB

1
Security Monkey est mort - Vous voulez geler la machine à froid (tirez sur le cordon d'alimentation) lorsque vous allez l'imaginer. l'arrêt et / ou le démarrage peuvent déclencher l'autodestruction ou le nettoyage du code et le fait d'appuyer sur l'alimentation empêche que cela se produise avant que vous puissiez créer votre image.
voretaq7

2
Aussi - je dirais que vous ne devriez pas faire confiance aux résultats des commandes "intégrées" sur le système piraté comme netstat (ou dir, etc.) Encore une fois, je n'ai aucune expérience directe avec cela au niveau de l'entreprise, mais je me souviens avoir été piraté sur les machines personnelles où une partie du hack devait remplacer les outils intégrés pour masquer ce qui se passait vraiment.
MattB

4
+1 étape 6 est vital, vous ne savez pas si netstat vous montre la vérité sans analyser le trafic réseau réel - et cela en soi peut être assez compliqué et un test de patience ... alors, essuyez-le. Ce n'est plus votre boîte. Analysez l'image tout ce que vous voulez, mais essuyez la foutue machine;)
Oskar Duveborn

1
Je dirais que vous feriez probablement mieux de faire l'étape 2 à chaque fois, car vous n'êtes pas entièrement sûr de ce que vous trouverez au cours de votre enquête. Avoir des images binaires signifie également que différentes personnes peuvent regarder différentes choses, en utilisant chacune une copie.
Vatine
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.