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 2024 à 12h15

Commentaires (28)

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