web-dev-qa-db-fra.com

Cryptomining Malware - Ubuntu - Stratum tcp

Mon serveur LAMP a été touché par une sorte de malware de crypto mining. Crontab est clair et inutilisé, Clam ne semble rien détecter.

Il semble créer automatiquement ces fichiers dans mon dossier/tmp à des moments aléatoires de la journée.

  • phpIij8W8.c
  • phpIij8W8_fkk2qr2rqjikiewz (a toujours un nom aléatoire après la suppression)

À l'intérieur de ce phpIij8W8_fkk2qr2rqjikiewz:

threads = 1
mine = stratum+tcp://44XNuUyCFUgjG23yPfCHp(cut for content...etc):[email protected]:3333/xmr

Ils commencent tous par "php" donc je suppose qu'une sorte de script PHP est sur le serveur qui crée automatiquement ces fichiers dans le dossier tmp et les exécute.

J'ai essayé d'utiliser iNotify pour déterminer ce que/comment ceux-ci ont été créés et tout ce que j'ai pu déterminer est le suivant:

Le fichier phpvlnebP_fkk2qr2rqjikiewz vient d'être créé par MOVED_TO

Quelqu'un peut-il me donner quelques conseils pour affiner le script qui crée ces fichiers aléatoires? Ou s'il existe un moyen d'obtenir iNotify pour me donner plus d'informations lorsque le fichier est créé/accédé. Ou diable, s'il y a un meilleur outil pour diagnostiquer ce problème.

Ubuntu 16.04.3

malwarelinuxubuntu
6
Taurian

J'ai eu le même problème, et je me suis rétréci, les pirates ont pu s'introduire dans certains wordpress anciens et non mis à niveau.

Probablement le meilleur et le plus rapide moyen de voir qui consomme combien de temps sur votre serveur Ubuntu 16.04.3 est d'installer htop

Sudo apt install htop

puis tapez Sudo htop

Il vous montrera sous quel nom d'utilisateur mange la quantité de CPU enter image description here

Et si vous identifiez un processus qui consomme beaucoup de CPU, vous pouvez le vérifier par lsof -p <pid>

lsof signifie list open files, pour voir son ensemble complet de commandes, tapez man lsof

Cependant, tout dépend de la façon dont votre PHP est exécuté, et de ce que les pirates ont réellement fait à votre système.

Une autre bonne façon de voir ce que fait exactement Apache est d'activer mod_status

Habituellement, sur les ubuntu plus récents, c'est:

Sudo a2enmod status

Et après cela, ajoutez ceci à votre site Web 000-default.conf:

<Location /server-status>
    SetHandler server-status
    Require ip 127.0.0.1
    Require ip ::1
    Require ip X.X.X.X
</Location>

Remplacez X par votre adresse IP réelle ...

Ou vous pouvez y accéder avec lync par exemple depuis la console de votre serveur comme

lynx 127.0.0.1/server-status

Et la sortie devrait ressembler à: enter image description here

Sur mon autre article https://security.stackexchange.com/questions/172396/some-bot-keeps-posting-this-to-my-server/172571 vous pouvez voir comment améliorer la sécurité de votre serveur et empêcher de telles attaques.

2
Aleksandar Pavić

Pour être clair, votre meilleur pari ici est de nuke de l'orbite . Vous avez probablement une copie de votre demande quelque part, ainsi qu'une copie de votre base de données. Si vous voulez vraiment essayer de le comprendre, alors vous devriez probablement partir du point de vue que vous avez un ou deux vecteurs d'intrusion:

  1. Votre application web
  2. Votre système

Bien que je devine énormément, il semble que ce soit un pari sûr que le fichier PHP que vous continuez à supprimer n'est pas le malware réel, mais plutôt un sous-produit du malware. Je sais vous le savez, mais pour être clair: vous n'avez rien fait pour supprimer le malware, juste ses symptômes. La découverte et la suppression du malware lui-même varient énormément selon qu'il se trouve ou non dans votre application Web ou dans votre système. . Qui est le propriétaire du fichier que vous supprimez toujours? S'il s'agit de l'utilisateur sur lequel votre serveur Web s'exécute, l'infection est probablement due à votre application Web. Si tel est le cas, voici quelques détails qui pourraient vous aider:

Intrusion d'application Web

  1. Vous savez quand la charge utile est créée dans votre répertoire temporaire. Vérifiez s'il existe des demandes suspectes dans vos journaux HTTP qui correspondent à cette période. Si le vecteur d'intrusion est votre application Web, il y a probablement des appels entrant via votre serveur HTTP à partir d'un serveur C&C qui déclenche l'exécution de la charge utile.
  2. Mettez immédiatement à jour votre application logicielle vers la dernière version, en supposant que vous déployez des logiciels tiers (wordpress, etc ...)
  3. Votre utilisateur Web a-t-il un accès en écriture au dossier où se trouve l'application Web? Si oui, vous êtes SOL. S'ils sont entrés via votre application Web, cela signifie qu'ils ont trouvé une vulnérabilité d'exécution de code à distance. Avec un accès en écriture à votre répertoire d'application, cela signifie qu'ils auraient pu installer des backdoors partout où ils le souhaitaient dans votre application. À moins que vous ayez d'anciennes sauvegardes et que vous puissiez déterminer avec certitude qu'aucun élément malveillant n'a été ajouté à votre base de code (ce qui est très difficile à faire), votre meilleur pari est de NUKE IT FROM ORBIT
  4. Inversement, il est possible que vous ayez une vulnérabilité ouverte qui n'est pas corrigée et que votre système lui-même ne soit pas modifié (plus probablement si votre serveur Web n'a pas accès en écriture à l'application Web). Dans ce cas, la charge utile continue de revenir car le serveur C&C continue de ré-exploiter la vulnérabilité de sécurité. En ce sens, le problème disparaîtra une fois que vous aurez corrigé vos problèmes de sécurité. Assurez-vous et mettez à niveau toutes les parties de votre application Web. S'il s'agit d'une application développée à la maison, vous pouvez très bien être SOL: à moins que vous ne puissiez trouver et fermer vos propres vulnérabilités, la neutraliser depuis l'orbite ne les empêchera pas de revenir. Dans ce cas, nous espérons que vous obtiendrez de l'aide de votre part. journaux du serveur. Si vous pouvez trouver des preuves de l'intrusion initiale dans vos journaux, cela vous aidera à trouver et à corriger la vulnérabilité.

Intrusion système

Celui-ci est probablement moins probable, mais il est possible que votre système lui-même ait été compromis (service non sécurisé, mots de passe SSH craquables, etc.). À défaut de fouiller dans les journaux, il peut être difficile de déterminer avec certitude si c'est votre système lui-même qui était le point faible. Il sera probablement beaucoup plus facile de déterminer que votre application Web est le problème (d'après ma propre expérience, c'est probablement votre application Web qui est le coupable de toute façon). Quoi qu'il en soit, si vous ne pouvez pas déterminer avec certitude qu'il s'agissait de votre application Web, votre système est le seul autre coupable.

La réponse

Quoi qu'il en soit, le problème est qu'il sera très difficile de déterminer avec certitude où le problème a commencé, et encore plus difficile de dire si vous les avez sortis ou non. Même si vous parvenez à empêcher le cryptominer de se mettre en place, quelles garanties avez-vous qu'il n'y a pas de processus plus silencieux et plus malveillant qui se cache ailleurs? Processus en arrière-plan qui efface votre base de données et l'envoie à un serveur C&C distant une fois par semaine? C'est un excellent moyen de divulguer les informations personnelles de toute personne qui se connecte à votre système. Sans parler de la menace pesant sur vos propres mots de passe et informations d'identification de compte. C'est pourquoi, peu importe où l'intrusion a commencé, il n'y a qu'une seule réponse:

  1. NUKE IT OF ORBIT
  2. Faites tourner un nouveau serveur en suivant toutes les meilleures pratiques (services minimaux, pare-feu approprié, tout est entièrement corrigé)
  3. Utilisez tous les nouveaux mots de passe pour tous les services.
  4. Trouvez une copie de votre application qui est CONNUE POUR ÊTRE PROPRE . Si vous utilisez un logiciel tiers, assurez-vous que la mise à niveau/correctif est complète.
  5. Restaurez à partir de la dernière copie de votre base de données. Assurez-vous qu'il n'y a pas d '"utilisateurs" supplémentaires avec un accès administrateur et modifiez tous les mots de passe administrateur
  6. Assurez-vous que la nouvelle base de données n'a pas de déclencheurs/procédures qui ne proviennent pas de vous.
  7. Si cette application est un système local, il est temps d'investir massivement dans la formation à la sécurité et de réécrire, à moins que vous ne soyez certain que votre système n'était pas en faute.
1
Conor Mancone

Un de mes serveurs a réussi à l'attraper dans un centre de données, mais 2 de mes autres serveurs exécutant le même logiciel, chacun hébergé chez un fournisseur différent, n'ont pas contracté l'infection - un vilain à cela, provoquant le CPU (quad core) au maximum.

Après avoir cherché une réponse, je suis tombé sur ce tableau et bien que j'aime l'approche NUKE IT OUT OF ORBIT, j'ai peut-être trouvé une solution après avoir essayé de nombreuses approches pendant des heures.

Voici les synopsis:

J'ai pensé que si je voulais arrêter le démarrage des processus existants, je devais évidemment supprimer les exécutables - pas exactement. Puisque nous avons affaire à une infection, les processus reviennent sans cesse après quelques millisecondes. Après avoir supprimé les exécutables, ils sont revenus - j'ai réussi à attraper une connexion SSH sortant vers le serveur C&C, je la posterai plus tard une fois que je l'aurai connectée sur ma machine expérimentale. L'étape suivante que j'ai faite pour l'empêcher de se lancer, a été de trouver tous les exécutables et au lieu de les supprimer, j'ai défini leur autorisation sur personne: personne et 444 (je voulais toujours examiner le contenu, vous pouvez le réduire). Cela a occupé le nom du fichier utilisé par le programme malveillant afin que la connexion SSH ne puisse pas remplacer le contenu du fichier et l'empêche également de s'exécuter, le rendant inutile. Cela semble fonctionner pour arrêter le démarrage automatique des processus et permettre l'exécution de code à distance et la mise en quarantaine efficace des exécutables.

Veuillez noter qu'il ne s'agit que d'une solution de correctif et non d'un remède pour résoudre le problème. Je vais revoir le code commit by commit (en git) et les fichiers journaux globaux pendant un certain temps jusqu'à ce que je comprenne comment la charge utile y est entrée en premier lieu.

CentOS7

Pas:

install htop:
#: Sudo yum install htop

#: htop

Trier par% CPU et noter le nom du processus consommant 99% ou 100%

trouver l'exécutable:

#: Sudo find / -type f -iname "[FILENAME]"

remplacez [FILENAME] par le nom que vous avez saisi sur htop

#: Sudo chown nobody:nobody /path/to/[FILENAME]
#: Sudo chmod 0444 /path/to/[FILENAME]

Arrêtez les exécutables en cours d'exécution

#: Sudo htop

trouver le processus, sélectionnez et appuyez sur la touche "K" pour tuer le processus. À ce stade, il ne devrait pas revenir. Si un nouveau processus est revenu, répétez les étapes ci-dessus.

Peut-être que quelqu'un aura le temps d'écrire un script sh pour le faire automatiquement.

[MISE À JOUR:] Attention également aux travaux CRON pour l'utilisateur Apache - s'exécute toutes les 15 minutes pour télécharger la charge utile.

0
Shib