En se basant sur un rapport de Sansec, Bleeping Computer explique qu’il s’agit d’un Remote Access Trojan (RAT) qui cible « les boutiques en ligne et permet aux attaquants de voler des données de carte de paiement ».
Les développeurs du malware utilisent une nouvelle technique pour se cacher : des lignes syntaxiquement valides pour une tâche Cron (donc acceptées par le système), « mais qui généreraient une erreur lors de leur exécution.Cela n’arrive par contre jamais puisqu’elle devrait avoir lieu le 31 février », une date qui n’existe pas (durant les années bissextiles, février n’a que 29 jours).
Le code, caché sous plusieurs couches de compression et d’encodage, « inclut des commandes d’autodestruction, de synchronisation et un protocole personnalisé qui permet la communication avec un serveur distant ». Au final, le risque est élevé puisque les pirates peuvent exécuter à distance n’importe quelle commande sur le système compromis.
Commentaires (14)
#1
En attendant il passe allègrement sous la plupart des radars, en raison de la “relative simplicité de sa configuration”. Comment quoi les
plaisirsprogrammes les plus simples sont les meilleurs…#2
Comment ? En espérant qu’un admin système (ou une taupe) repositionne la tâche au 28 (ou 29) février ?
S’ils ont réussi à écrire dans le cron, ils auraient aussi bien pu l’exécuter directement.
#2.1
Il utilise le cron comme espace de stockage du code pour éviter que les antivirus le détecte. Le code n’est pas exécuté par le cron. C’est probablement combiné à autre chose mais l’article original n’est pas super exhaustif.
#2.2
Je pense plutôt que la tâche cron sert à stocker du code “sensible” qui serait facilement détecté par les antivirus. Et le reste du programme ne fait que l’extraire du fichier et l’exécuter. C’est ce que j’ai compris du moins, et ça n’est je pense jamais exécuté depuis cron directement.
#2.3
Après avoir lu les tweet du chercheur j’ai finis par comprendre que le cron est utilisé pour les 2. Dans le screenshot on voir une tache qui tourne tout les 30 min et qui est le point de départ. Et le reste du cron est utilisé comme espace de stockage.
#3
Peut-être que c’est un bug et que l’exécution du 31 février est un “reste” vu qu’il s’auto-supprime.
Sinon, vu la tronche des commandes, dans le cron, je ne pense pas qu’un admin les modifie sans se douter que c’est louche.
#4
En lisant le code on voit que seul le payload est stocké en base64 dans la cron au 31 février, pour échapper au anti-virus. Mais le morceau de code qui récupère cette payload et l’exécute est dans une cron normale qui tourne toute les 30 minutes.
Ceci dit c’est une brillante idée pour cacher des données. La communication TCP en bash est aussi intéressante à étudier.
#5
C’est malin ! merci pour l’info
#6
Donc l’info c’est plutôt que les antivirus ne scannent pas le cron ?
#7
J’ai rien compris, pas clair leur truc…
EDIT Un article plus clair : https://www.netcost-security.fr/actualites/61728/cronrat-le-dangereux-malware-linux-qui-devrait-sexecuter-le-31-fevrier/
#7.1
Bof, guère plus explicite.
Merci à sarbian et sebtx pour leurs explication de texte.
#7.2
Oui c’est bizarre ce truc.Bonne pub pour la société de sécu en tout cas.
#8
Merci, heureusement que vous êtes là :p
#8.1
Surtout que cette assertion est imparfaite car incomplète, il manque la définition d’une année bissextile: ce n’est pas simplement une année dont le millésime est divisible par 4; il faut exclure la dernière année du siècle (1900 par exemple) sauf si c’est la dernière année d’un millénaire (2000). C’était un des Y2K bugs possibles.