Connexion
Abonnez-vous

Perfctl, un malware Linux tenace

Perfctl storm

Perfctl, un malware Linux tenace

Hier soir, les chercheurs de la société Aqua Security ont publié un article détaillé sur le malware Perfctl. Ils y mettent en garde les utilisateurs contre ses capacités, qui allient une grande discrétion à une persistance tenace. Sa détection n’est pas assurée et les chercheurs estiment que le nombre de configurations vulnérables se comptent en millions.

Le 04 octobre à 12h15

Le nom du malware, donné par les chercheurs, est un agrégat de Perf, un outil d’analyse des performances, et de ctl, une abréviation courante pour les outils en ligne de commande. Selon Aqua Security, ce logiciel malveillant circule depuis au moins 2021 et serait présent sur au moins plusieurs milliers de configurations, pour l’essentiel des serveurs.

Un roi de l’évasion et de la persistance

Perfctl dispose de nombreuses capacités. Sitôt installé sur une machine, il supprime son binaire et continue de fonctionner comme service en arrière-plan. Parallèlement, il se copie depuis la mémoire vers plusieurs emplacements du stockage. Il se cache derrière des noms a priori anodins, semblables à des fichiers système, pour tromper la vigilance. Aqua Security a résumé ces noms dans un graphique :

Source : Aqua Security

Le malware modifie également le script ~/.profile (configuration de l’environnement à la connexion de l’utilisateur) pour assurer son exécution lors de l’ouverture de session. Il dispose aussi d’un rootkit s’exécutant à tous les redémarrages de l’ordinateur.

Perfctl est en outre discret. En plus des mesures citées précédemment, il peut mettre fin automatiquement à toutes ses activités « bruyantes » quand un utilisateur se connecte sur la machine. Ses différents composants communiquent en interne en ouvrant des sockets Unix et en externe via des relais Tor.

Il sait aussi manipuler le processus pcap_loop (via une technique d’interception) pour empêcher les outils d’administration d’enregistrer le trafic qui pourrait être perçu comme malveillant. Le détournement de pcap_loop participe également à la persistance, en permettant aux activités malveillantes de se poursuivre quand les charges utiles ont été détectées et supprimées. En outre, Perfctl peut supprimer les erreurs mesg pour éviter que des avertissements apparaissent pendant l’exécution.

Une provenance incertaine

Un grand flou entoure Perfctl, en dépit des nombreux détails découverts par les chercheurs. Ils ne savent ni d’où il vient, ni quel groupe malveillant pourrait en être à l’origine. Aqua Security estime cependant que le degré de technicité est très élevé. L’accumulation des méthodes prouve que le ou les auteurs connaissent parfaitement le fonctionnement de Linux.

Il est tout autant difficile de savoir combien de machines sont infectées. Perfctl cherche en premier lieu à exploiter certaines failles, dont CVE-2023-33426, une vulnérabilité critique de dangerosité maximale (10 sur 10) dans Apache RocketMQ. Même s’il n’en trouve pas, il peut quand même passer par d’autres moyens, en exploitant plus de 20 000 erreurs courantes dans les configurations. Dans ce cas, il tente d’exploiter la faille CVE-2021-4043 dans Gpac pour obtenir les droits root.

Source : Aqua Security

La détection est d’autant plus difficile que Perfctl arrête ses activités les plus visibles dès qu’une session est ouverte, comme déjà précisé. Les chercheurs mettent en avant de nombreuses conversations sur des comportements étranges de leurs serveurs, notamment sur Reddit. « Je n'ai pris conscience de l'existence du logiciel malveillant que lorsque ma configuration de surveillance m'a alerté de l'utilisation à 100 % du processeur. Cependant, le processus s'arrêtait immédiatement lorsque je me connectais via SSH ou la console. Dès que je me déconnecte, le logiciel malveillant reprend son cours en quelques secondes ou minutes », écrit ainsi un administrateur.

On trouve d’autres discussions du même type, dans diverses langues, sur des sites comme Stack Overflow, forobeta, brainycp ou encore Proxmox. Sur ces témoignages, les chercheurs d’Aqua ne peuvent être certains qu’il s’agit bien de Perfctl, mais ils indiquent que les symptômes correspondent.

À quoi sert Perfctl ?

Le malware est tenace et discret, mais à quelles fins est-il utilisé ? Les pics de consommation CPU donnent un indice : il sert essentiellement à miner de la cryptomonnaie Monero en installant le cryptomineur XMRIG. Les envolées à 100 % sur le CPU viennent du minage, extrêmement gourmand en puissance de calcul. Comme vu, l’activité s’arrête dès que l’on se connecte à une session.

Perfctl peut également réaliser du proxy-jacking. Il réutilise ainsi la bande passante non exploitée à d’autres usages. Dans un cas comme dans l’autre, la motivation est clairement financière.

En dépit de ces deux activités, Perfctl est décrit par les chercheurs comme très polyvalent. En fonction de la charge utile envoyée par le serveur de commande et contrôle (C2C), il peut se livrer à d’autres actions malveillantes, comme l’exfiltration de données.

S’en débarrasser n’est pas simple

On ne sait pas vraiment si les antivirus sont capables actuellement de détecter Perfctl et de le supprimer. Les chercheurs d’Aqua Security fournissent quand même une série de conseils, notamment sur la manière de reconnaitre la présence du malware.

Il y a deux principaux critères pour établir la présence du malware. D’abord, les pics d’activité CPU (ou des ralentissements a priori inexpliqués), particulièrement sur des processus nommés httpd et sh. Ensuite, la présence de binaires suspects dans les dossiers /tmp, /usr et /root. Des noms comme perfctl, sh, libpprocps.so, perfcc et libfsnkdev.so sont donnés en exemples.

Aqua recommande en outre de vérifier les journaux système à la recherche de modifications sur les fichiers ~/.profile, et /etc/ld.so.preload, ainsi que la surveillance des modifications à certains utilitaires système (comme ldd, top, lsof et crontab).

Les chercheurs recommandent également plusieurs mesures d’atténuation, dont la plus importante est de mettre à jour les composants du serveur, en particulier ceux touchés par des failles exploitées. Aqua suggère aussi de restreindre l’exécution des fichiers dans les répertoires accessibles en écriture, de désactiver les services inutilisés, d’appliquer une gestion stricte des privilèges et, bien sûr, de déployer des outils de sécurité capables de détecter des rootkits et malwares sans fichier.

Aqua estime qu’en tenant compte de la prévalence des failles ciblées et non corrigées, des millions de machines sont actuellement vulnérables à ce malware.

Commentaires (28)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
sympa le bestiau !
Peut-être que CrowdStrike peut s'en occuper :troll:
votre avatar
aquasec est spécialisée dans la sécurisation du cloud et des conteneurs. Pas très rassurant car on peut imaginer que ce machin se retrouve dans tout un tas d'images Docker, par exemple.
votre avatar
Ca parait peu probable, il faut poser la question au responsable de l'intégration dans une image docker. Par ailleurs quand même ce serait le cas, c'est la sécurité de l'OS qui fera barrière pour l'escalation de privilège (mais pas pour la conso CPU ce qui est moins grave).
votre avatar
Les images Docker sont utilisées depuis longtemps pour héberger des malwares, souvent des cryptomineurs. Dans le papier, il me semble comprendre que les traces du malware ont été cherchées dans un conteneur (cf. figure 20).
votre avatar
J'en ai bien conscience étant donné que n'importe qui peut créer un compte sur les grands registry publics et uploader une image docker avec n'importe quoi dedans. C'est comme les exécutables il ne faut pas télécharger tout et n'importe quoi depuis n'importe où d'où ma remarque sur la question de l'intégration.
votre avatar
La question que je me pose c'est : comment il s'installe initialement ? J'ai cru comprendre que personne n'en sait rien.

Y a-t-il un centre de commandement qui écoute les IP exposées et utilise des failles de protocoles comme SSH, Apache, Nginx, etc ?

Infiltration type worm ?

Supply chain ?

Infection de dépôt logiciels ?

Au vu de ses capacités, il est forcément installé avec des droits root. Donc soit il utilise une faille d'escalade de privilèges, soit il est amené au moment d'une opération parfaitement justifiée.

Les conseils prodigués sont effectivement les gestes habituellement recommandés : isolation, process qui ne tournent pas en root quand c'est pas justifié (container inclus, pas de putain de user root !), least privilege, isoler son réseau (entrée et sortie), mettre du WAF, maintenir le système ET les middlewares à jour, etc. Hélas, la réputation fausse de "Linux = pas de malware" est encore bien trop ancrée dans les esprits, cette désinformation créé des ravages en matière de sécurité IT.
votre avatar
Je parie un billet que c'est encore un service qui tourne généralement en root.
Cela dit, le truc chiant avec les produits Apache c'est que la fondation ne se limite qu'à fournir les sources, le binaire et la doc (+/- laconique selon les produits). Il n'y a jamais les paquets pour les distrib ou a minima des instructions claires d'intégration, donc l'intégration se fait souvent à l'arrache c-a-d en root, sauf pour les trucs vraiment connus type httpd qui sont maintenus côté distrib.

Je ne compte plus le nombre de fois où j'ai vu du ambari (et hadoop en général), cassandra, kafka, solr, zookeeper etc. tourner en root. (et accessoirement jamais mis à jour).
votre avatar
J'avoue que la vérole est bien velue. Merci pour la news.

Même question que mon vdd, comment elle s'installe ?
votre avatar
En relisant l'article et en diagonale le billet d'Aqua Security, j'ai l'impression que la piste privilégiée est bien celle des services vulnérables exposés. Ici avec l'exemple d'Apache RocketMQ.

Service qui tourne avec privilèges, utilisation d'une faille qui fait une escalade et kaboom. Je pense qu'avec du hardening (cf les différentes actions non exhaustives que je listais) les risques peuvent être déjà un peu plus mitigés.
votre avatar
Bon, il suffit de garder une session ssh ouverte et la bête reste endormie :D
votre avatar
Excellent idée, j'ouvres immédiatement mon Shell in a Box !
votre avatar
Il n'y a pas une AI pour transformer le beau graphique Aqua Security des fichiers connu en script de recherche de leur présence ?
votre avatar
migrons tous sous openBSD, haiku ou d'autres unix indépendants.. problème résolu :D
votre avatar
ou Windows.

Crowdstrike nous protégera en enfermant le PC dans une boucle spatio-temporelle de reboots infinie :D
votre avatar
À noter que Falcon, le maintenant bien connu agent de Crowdstrike, a aussi des versions pour les Unix. Sous Linux il nous avait provoqué quelques crashs il y a qq temps...
votre avatar
haiku ?
zyva, installes une béta en prod ...
votre avatar
Un petit script pour le traquer:

!/usr/bin/bash

MatchCount=0
ThreatFiles=("/tmp/.xdiag/hroot/cp"\
"/tmp/.xdiag/hroot/hscheck"\
"/tmp/.xdiag/tordata/state.tmp"\
"/tmp/.xdiag/hroot/cp"\
"/tmp/.xdiag/cp"\
"/tmp/.xdiag/exi"\
"/tmp/.xdiag/p"\
"/tmp/.xdiag/elog"\
"/tmp/.xdiag/int/.e.lock"\
"/tmp/.xdiag/uid"\
"/tmp/.xdiag/ver"\
"/tmp/.perf.c/Loader"\
"/tmp/.perf.c/perlctl"\
"/tmp/.apid"\
"/tmp/lgctr"\
"/tmp/lgctr2"\
"/usr/bin/.local/bin/ldd"\
"/usr/bin/.local/bin/top"\
"/usr/bin/perfcc"\
"/usr/bin/wizlmsh"\
"/tmp/lib/libfsnldev.so"\
"/tmp/lib/libcwrap.so"\
"/tmp/lib/libpprocps.so"\
"/root/.cache/pci.ids"\
"/root/.config/cron/perfcc"\
"/root/sedkBrgaa"\
)

echo "Let's chech files:"
for CurFile in "${ThreatFiles[@]}"; do
echo -e -n ' ├─ Looks for \E[34;01m'$CurFile'\E[0m : '
if [[ -e $CurFile ]]; then
echo -e '\E[31;01m✘\E[0m File found!'
((MatchCount++))
else
echo -e '\E[32;01m✔\E[0m No theat'
fi
done
if (( $MatchCount > 0 )); then
echo -e ' ╰─ \E[31;01mOH NOOOOOO! '$MatchCount' files found \E[0m'
else
echo -e ' ╰─ \E[32;01mGROOVY BABY!\E[0m'
fi
votre avatar
Merci!

Et pour surveiller le process le plus actif sur une machine (ça produit un csv dans le dossier courant avec le process le plus actif chaque minute, par défaut) :

#!/bin/bash

OUTPUT_FILE=${1:-cpu_usage_history.csv}
PS_ARGS=(-axo '%cpu,pid,ppid,user,group,nice,stat,start,time,command' --sort=-%cpu)
INTERVAL_S=${2:-60}

prefix_with() {
prefix="$1"
cat "$OUTPUT_FILE"

while sleep "$INTERVAL_S"; do
ps "${PS_ARGS[@]}" | sed -e '2p;d' | prefix_with $(date +%s) >> "$OUTPUT_FILE"
done
votre avatar
Pour le fun et être un peu plus sioux, dans cet article, il y a des md5 à chercher: https://www.aquasec.com/blog/perfctl-a-stealthy-malware-targeting-millions-of-linux-servers/
votre avatar
Très sympa de fournir ce genre de script ! :yes: :smack:

Juste 2 toutes petites typo "d'affichage" (sans importance) :

" No theat " >> " No threat "

" Let's chech files: " > > "Let's check files: "
votre avatar
J'ai plus tiqué sur le "bang" qui se retrouve sans son "she", mais j'imagine que ça sert de filtre pour éviter que ceux qui ne comprennent rien n'arrivent à casser leur machine à cause du script :)
!/usr/bin/bash ⇒ #!/usr/bin/bash
votre avatar
C'est juste un bon vieux copié collé foireux mais j'aime bien ton scénario.
Forcer les gens à se poser des questions avant de lancer un script pourrait être une bonne chose aussi.
votre avatar
Pour ceux qui n'auraient pas la fibre dev.
Remplacez "\" (en fin de ligne) par "," dans la liste "ThreatFiles". C'est un peu plus passe partout.

Et on n'oublie pas de lire le code AVANT de copier-coller pour les autres (sauf ton respect Wanou).


Accessoirement, une petite personnalisation pour le fun:

if (( $MatchCount > 0 )); then
echo -e ' ╰─ \E[31;01mOH NOOOOOO! They got Pablo! Free Pablo you evil dicks!!! '$MatchCount' files found \E[0m'
else
echo -e ' ╰─ \E[32;01mGROOVY (https://www.youtube.com/watch?v=FIJTvEo4N4Q)\E[0m'
fi



À noter que le problème sous-jacent n'est pas forcément vos serveurs dans le pro, mais aussi vos équipements perso. Un NAS, une imprimante 3D (ou tout IOT) qui héberge bien souvent des services sans pour autant que cela soit nécessaire ferait aussi une cible (facile ?). La puissance des SBC (et même d'un ESP32 sur lequel on peut faire tourner un Linux (hé oui)) est devenue intéressante.

Quand on détourne des I/O il n'y a pas de petites économies. Car il est un fait, on n'a pas toujours accès sur ces équipements de la façon dont on voudrait. Et donc se débarrasser d'une vérole pour madame Michu... Ca se complique.

À plus forte raison quand ces équipements ne sont pas suffisamment mis à jour (utilisateurs et constructeurs inclus). Pas de panique pour autant vos "box" font pas mal le boulot. Restera la gaffe d'installer un truc pas clean. Mais bon madame Michu... elle ne fait pas de Docker.





Ce genre d'épisode est le plus gros caillou dans la chaussure de l'Open / free source. On est passé de l'ère du "Oh putain ça marche!!! Groovy..." à celle de "hmm d'où ça sort ce truc ?". On commence à avoir du mal à compter les épisodes de fuite de donnée ou de détournement de package (Hein NPM!!!!). Bref "mettez des préservatifs", "Touches pas à mon pote", "Shampoing à l'Aloe Vera", "Mangez, bougez"* et tout ça quoi.
votre avatar
Si t'as l'habitude de monter ton /tmp en mémoire et de rebooter régulièrement ton serveur, ça doit bien l'emmerder pour vivre ...
votre avatar
Malheureusement, le délire du plus gros uptime reste présent dans les SI (les bécanes qui reboot deux fois dans l'année, c'est pas assez une exception...). Ce qui est antinomique avec des campagnes de patch management. :craint:
Et quand t'arrives à négocier un patch management mensuel avec le métier, tu débouches le champagne.

Une résultante aussi des architectures pour lesquelles la redondance a été écartée parce que "trop cher". Résultat, pour reboot un serveur, il faut une inter en HNO planifiée 6 mois à l'avance.

Vive les visions court terme, vive les VM, vive le IaaS, vive les projets à 2 millions d'euros sur trois ans pour changer quatre serveurs en CentOS 6.

Toute ressemblance blablabla...

(et j'arrive à voir le même délire sur du container...)
votre avatar
Je compatis, mon frère :smack:
votre avatar
La haute disponibilité n'est pas antinomique avec des redémarrages nécessaires à de la maintenance.

La partie la plus embêtante reste la gestion du brassage et la conception de mécanismes de rejeu en cas de perte/coupure d'un traitement en cours.
C'est de l'architecture d'infrastructure, et il y a des solutions techniques aux problèmes techniques.

Cependant, le souci vient majoritairement toujours d'ailleurs, et n'est pas technique : les DSI sont encore aujourd'hui vues comme des centres de coûts et non pas comme des centres d'investissement voire de création de valeur.
Ce malentendu empêche de ponctionner les revenus pour garantir un financement décent niveau technique & niveau humain.

Ce malentendu empêche aussi l'autonomie nécessaire des DSI, à qui on ne doit demander que de respecter des objectifs de service (SLO), qui vont déterminer le niveau de service ainsi que la durée d'évaluation, découlant parfois (mais pas toujours !) d'accords juridiques signés (SLA). Le point clé est qu'elles devraient rester libres de leur implémentation.

Il est grand temps qu'une culture informatique s'installe chez les moins techniques, afin notamment qu'ils mettent leurs peurs en sourdine, sans donc les déverser sur les connaisseurs et bloquant leurs moyens d'action, d'appliquer leurs connaissances, et ainsi de tout simplement faire leur métier.
Et quand bien même on se ferait de grandes séances d'onanisme à coups de SLO, shit happens.

Et il y a d'autres problèmes organisationnels, jusqu'à notre manière de travailler, mais commençons déjà quelque part.
votre avatar
Il y a aussi que souvent les DSI sont dirigées par des gens sans bagage technique autre que la presse pour DSI

Perfctl, un malware Linux tenace

  • Un roi de l’évasion et de la persistance

  • Une provenance incertaine

  • À quoi sert Perfctl ?

  • S’en débarrasser n’est pas simple

Fermer