Introduction

Le malware Kinsing est une menace bien connue visant les serveurs Linux, en particulier ceux mal configurés ou utilisant des applications vulnérables exposées sur Internet. Ce logiciel malveillant installe un mineur de cryptomonnaie sur le système compromis et se maintient par divers mécanismes de persistance.

Dans cet article de veille, je vais analyser comment mon propre VPS sous Debian, hébergé chez OVH et sur lequel j’auto-héberge les services Confluence (documentation) et WordPress (site web), a été infecté par Kinsing. J’expliquerai les symptômes observés, les étapes de résolution, et les contre-mesures mises en place pour éviter une future compromission. 

 

Symptômes et découverte

Les premiers signes de compromission sont apparus lorsque Confluence n’était plus accessible depuis le navigateur. En analysant l’état du service, le système indiquait une erreur de type OOM-Kill (Out Of Memory) liée au processus Confluence.

En creusant avec la commande systemctl status confluence, j’ai identifié deux processus anormaux encore actifs  que le service Confluence : /tmp/kinsing, /tmp/kdevtmpfsi

Voici une capture d’écran du statut du service Confluence, montrant la présence explicite des processus malveillants dans la hiérarchie du service :

 

 

Un audit rapide via un script maison  a confirmé la présence de fichiers exécutables suspects dans /tmp ainsi que l’écoute de ports inhabituels. Bien que les rootkits aient été exclus via rkhunter, le malware Kinsing n’avait pas besoin de privilèges root pour fonctionner.

Script utiliser pour réaliser un audit de sécurité

#!/bin/bash

echo « ==== AUDIT DE SÉCURITÉ RAPIDE ==== »
echo « Date: $(date) »
echo « Hostname: $(hostname) »
echo « Uptime: $(uptime -p) »

echo « == 1. Processus suspects == »
ps aux | grep -E ‘kinsing|kdevtmpfsi’ | grep -v grep

echo « == 2. Ports ouverts == »
sudo netstat -tunap | grep LISTEN

echo « == 3. Utilisateurs sudo == »
grep ‘^sudo:.*’ /etc/group

echo « == 4. Tâches cron anormales == »
sudo grep -r « kinsing\|kdevtmpfsi » /etc/cron* 2>/dev/null

echo « == 5. Fichiers récents dans /tmp == »
sudo find /tmp -type f -printf « %T@ %p\n » | sort -n | tail -n 10 | cut -d’ ‘ -f2-

Face à la compromission, j’ai choisi de réinstaller entièrement le VPS.

•  Sauvegarde des données critiques

(site WordPress, base de données, certificats SSL)

• Reformatage complet du VPS.

• Réinstallation sécurisée de Debian.

• Restauration des services nécessaires.

 

Contre-mesures mises en place

Pour éviter une nouvelle attaque, voici les améliorations appliquées :

• Mise en place d’un pare-feu UFW

udo apt update
sudo apt install ufw

# Politique par défaut
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Ouverture des ports nécessaires
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activation du pare-feu
sudo ufw enable

# Vérification des règles
sudo ufw status verbose

• Accès SSH par clé uniquement

• Alerte mail de connexion SSH

• Configuration des mises à jour automatique sur le VPS

Configuration de unattend-upgrades

• Fail2ban activé

 

Test d’un ban de mon IP suite à plusieurs tentatives de connexions échouées  (wordpress)

• Sécurisation /var/tmp/

Redirection de /var/tmp/ 

Bloquer les tentatives d’exécution qui utilisent  /tmp ( et /var/tmp)

Conclusion

Cette expérience m’a permis de vivre une attaque réelle, d’en comprendre les mécanismes, et surtout de mettre en place des mesures pour s’en protéger. Le malware Kinsing profite de la moindre faille pour miner silencieusement et alourdir le serveur. Une veille systématique et des bonnes pratiques de sécurité sont indispensables pour prévenir ce type d’incident.

Ce retour d’expérience est un bon exemple d’analyse de vulnérabilité

Source

Le monde informatique – une-faille-critique-touche-confluence-d-atlassian

Trend Micro – CVE Exploité