IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des chercheurs en sécurité ont découvert CronRAT, un nouveau cheval de Troie d'accès à distance (RAT) furtif conçu pour attaquer les systèmes Linux
Se cachant sous la forme d'une tâche planifiée

Le , par Sandra Coret

129PARTAGES

18  0 
Des chercheurs en sécurité ont découvert un nouveau cheval de Troie d'accès à distance (RAT) furtif, conçu pour attaquer les systèmes Linux. Baptisé CronRAT, ce malware cible actuellement les boutiques en ligne et permet aux attaquants de voler des données de cartes de crédit en déployant des skimmers de paiement en ligne sur les serveurs Linux.

Les chercheurs de Sansec avertissent que CronRAT "permet le vol de données Magecart côté serveur en contournant les solutions de sécurité basées sur le navigateur". C'est un phénomène particulièrement préoccupant.

CronRAT est décrit comme "une menace sophistiquée, dotée de techniques furtives inédites", et Sansec affirme que son mode de fonctionnement signifie qu'elle ne sera pas reconnue par les autres sociétés de sécurité avant un certain temps.

L'entreprise explique : "Sansec a découvert que CronRAT était présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays. En raison de son exécution inédite, nous avons dû réécrire une partie de notre algorithme eComscan afin de le détecter. CronRAT n'est actuellement pas détecté par les autres fournisseurs de sécurité".

La société de sécurité poursuit :

"La principale prouesse de CronRAT est de se cacher dans le sous-système calendrier des serveurs Linux ("cron" un jour inexistant. De cette façon, il n'attire pas l'attention des administrateurs de serveurs. Et de nombreux produits de sécurité n'analysent pas le système cron de Linux.
CronRAT facilite le contrôle persistant d'un serveur de commerce électronique. Sansec a étudié plusieurs cas où la présence de CronRAT a conduit à l'injection de skimmers de paiement (alias Magecart) dans le code côté serveur
."


Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février. Au lieu de cela, le véritable code du malware est caché dans les noms des tâches et est construit en utilisant plusieurs couches de compression et de décodage base64.

La véritable charge utile de CronRAT est un "programme Bash sophistiqué qui se caractérise par l'autodestruction, la modulation du temps et un protocole binaire personnalisé pour communiquer avec un serveur de contrôle étranger".

De plus, la connexion se fait sur TCP via le port 443 en utilisant une fausse bannière pour le service SSH Dropbear, ce qui permet également au malware de rester sous le radar.

Après avoir contacté le serveur C2, le déguisement tombe, envoie et reçoit plusieurs commandes, et obtient une bibliothèque dynamique malveillante. À la fin de ces échanges, les attaquants derrière CronRAT peuvent exécuter n'importe quelle commande sur le système compromis.

CronRAT a été trouvé sur plusieurs magasins à travers le monde, où il a été utilisé pour injecter sur le serveur des scripts qui volent les données des cartes de paiement - les attaques dites Magecart.

Sansec décrit le nouveau malware comme "une menace sérieuse pour les serveurs de commerce électronique Linux", en raison de ses capacités :

  • Exécution sans fichier
  • Modulation du temps
  • Sommes de contrôle anti-tampering
  • Contrôle via un protocole binaire et obscurci
  • Lancement d'un RAT en tandem dans un sous-système Linux distinct.
  • Serveur de contrôle déguisé en service "Dropbear SSH".
    Charge utile cachée dans les noms de tâches programmées CRON légitimes.


Toutes ces caractéristiques rendent CronRAT pratiquement indétectable. Sur le service d'analyse VirusTotal, 12 moteurs antivirus ont été incapables de traiter le fichier malveillant et 58 d'entre eux ne l'ont pas détecté comme une menace.

Source : Sansec

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Le ransomware "Hive" chiffre désormais les systèmes Linux et FreeBSD,
Mais cette variante du ransomware est encore boguée et ne fonctionne pas toujours


La NSA et le FBI dévoilent le nouveau malware Drovorub de fabrication russe ciblant Linux, les agences émettent une alerte commune contenant des détails techniques sur ce logiciel malveillant

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de eomer212
Membre confirmé https://www.developpez.com
Le 01/12/2021 à 11:51
encore un article fumeux pour foutre les jetons.
mais la seule chose qui serait interressante de savoir, c'est le mode de contamination.
j'aimerais bien savoir par quel moyen ce truc a pu s'implanter sur cron, voir meme etre enregistré sur le serveur et etre executé..
comme d'hab, on nous présente un épouvantail mais ca s'applique à ... personnne.
ils citent que ce cronrat serait présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays" et c'est tout. quel pays, quel magasin??
du vent, rien de plus.

si vous voulez être en sécurité, donnez vous les moyens de pouvoir réinstaller complétement votre serveur et tous ses services. en clair, vos services /serveurs doivent etre des phénix, aptes à renaitre de leurs cendres si besoin.
ca résoudra 2 problématqiues principales.
- plantage matériel.
- contamination par une mauvaise politique de sécurité. reinstaller un serveur est l'equivalent d'une petite revue, l'occasion de se demander. 'mais pourquoi on fait ca.? pourquoi ce code fait ca. ou pourquoi ce code est obscurci? ou inaccessible?'

les plugins ou les services developpés par d'autres, c'est pratique, mais c'est comme de laisser un ouvrier extérieur bosser sur la serrure de votre coffre fort, seul la nuit, sans surveillance, chez vous, sans meme savoir qui c'est. donc, mef...
developper ses propres services ou prendre le temps de controler ce que fait une lib, comprendre ce qu'elle fait et comment avant de l'implanter, c'est le minimum..
maitrisez vos sauvegardes, ayez vos propres serveurs de sauvegarde.. ca aussi c'est important. et ca coute pas un bras..

HA, github, c'est pas la panacée, surtout quand c'est maintenant géré par agrosoft.. qui a toujours bien compris les besoins de la NSA.. laquelle NSA bosse pour l'etat americain qui pratique l'espionnage economique, entre autres.

quand on est developpeur, la méfiance doit devenir une seconde nature.. si on veut assurer la sécurité de ses clients et sa tranquilité..
5  0 
Avatar de becket
Expert confirmé https://www.developpez.com
Le 01/12/2021 à 12:39


Le 31 février ? Même pas peur !
5  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 27/11/2021 à 20:11
Qu'en pensez-vous ?

Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.
6  4 
Avatar de greg91
Membre habitué https://www.developpez.com
Le 29/11/2021 à 12:30
Comment un site web pourrait compromettre crond ?
Je voie pas (si PHP est bien configuré).
2  0 
Avatar de Hominidé
Membre éprouvé https://www.developpez.com
Le 03/12/2021 à 7:36
Bonjour,
Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février.
Comment un cron qui ne s'exécute pas peut-il lancer un code?
1  0 
Avatar de Sve@r
Expert éminent sénior https://www.developpez.com
Le 08/12/2021 à 9:33
Bonjour
Citation Envoyé par tabouret Voir le message
cron n'arrive pas à la cheville des timers Systemd (pas de randomisation native, impossible de faire concilier day of month et day of week sous Cron sans passer par la commande "test" et j'en passe)
Normal puisqu'il n'a pas été fait pour ça !!! Ah ben ma voiture n'arrive pas à la cheville des avions (pas de ADI, pas de pilotage automatique, impossible de la faire voler sans lui rajouter des ailes et j'en passe)

cron contient 3 paramètres de datation
  • la datation horaire (à quelle heure dans la journée)
  • la datation mensuelle (quel jour du mois et quel mois de l'année)
  • la datation hebdomadaire (quel jour de la semaine)

avec possibilité souple dans l'expression des datations (ex 0-60/2 signifiant "toutes les 2 unités de temps entre 0 et 60) mais surtout avec cette spécification que si une datation mensuelle et hebdomadaire sont explicitement spécifiées (donc avec autre chose que l'étoile), il s'exécutera alors si l'une ou l'autre des dates se présente. Autrement dit je programme un truc le 31/12 le dimanche, le truc s'exécutera tous les 31/12 et aussi tous les dimanches. C'est comme ça que les concepteurs l'ont voulu et c'est comme ça que les concepteurs l'expliquent. Fatalement si ce n'est pas comme ça que toi tu veux l'utiliser, à toi de coder ce qu'il faut pour combler. Mais ce n'est pas parce que tu ne veux pas l'utiliser de la façon dont il a été conçu que ça doit être sa faute à lui !!! Justement Linux se veut assez souple et ouvert pour permettre l'utilisation d'autres outils plus adaptés (anacron, at, etc). Tu ne l'aimes pas ok, ce n'est pas une raison pour affirmer "qu'il n'arrive pas à la cheville d'autres trucs que tu aimes". Et puis ce n'est pas parce qu'un truc est plus récent, plus "moderne" qu'un autre qu'il sera forcément mieux tout le temps. Tout le monde se fout de la tronche des russes qui ont encore des ordinateurs à lampe en activité alors que nous on a des crays. Sauf que le jour où on se prend une IEM dans la tronche, les ordinateurs russes continueront à fonctionner tandis que nous, on sera dans le noir. Donc peut-être que dans d'autres situations que toi tu n'as pas mais que d'autres peuvent avoir c'est cron qui aura l'avantage.

Citation Envoyé par Ti-Slackeux Voir le message
tout faux.
N'importe qui sous Linux peut utiliser la commande
Code : Sélectionner tout
crontab -e
pour modifier sa propre crontab.
Je pense que tu n'as pas bien réfléchi à tout ça.

N'importe qui peut utiliser la commande crontab -e à condition de ne pas se trouver dans cron.deny (première barrière qui liste les utilisateurs interdits et qui donc autorise tous les autres) ou d'être dans cron.allow (seconde barrière qui, si elle est présente, supplante la première et qui liste les utilisateurs autorisés et qui donc interdit tous les autres).

Et même si cela reste possible, tu présentes ça comme très simple, comme un simple user qui peut faire un crontab -e ("utiliser la commande" as-tu dit). Mais pour "utiliser une commande" il faut déjà être dans le système !!!
Donc déjà il faut que le "virus" qui s'exécute sur le serveur linux (on parle donc déjà là d'un truc qui va forcer un serveur style apache à faire des trucs pour lui) fasse lui-même le crontab -e (qui n'est pas un éditeur de cron mais qui se contente juste de lancer l'éditeur standard, peut-être "ed", peut-être "vi", peut-être "emacs", ou même peut-être rien du tout si l'admin de apache a bien configuré le compte associé au serveur donc dans ce cas là, pas d'éditeur !!!). Donc déjà c'est bien bien chaud. Mais allez, admettons. Mais ensuite quoi? Le processus lancé par ledit cron reste un processus utilisateur et pas root (l'utilisateur étant donc apache et qui n'a donc accès qu'à ses propres fichiers). Question droits d'accès au système, il devrait pouvoir gérer ça facilement le serveur Linux...

Et enfin comme d'autres l'ont si bien dit, je ne vois pas comment crond pourrait détecter qu'on est le 31 février pour enfin lancer le processus. A la limite convertir un "31 février" en "3 mars" certains outils savent le faire (exemple datetime de Python) mais penser qu'un outil (système en plus) ait été programmé pour faire l'inverse...

Donc non, pas "tout faux"...
1  0 
Avatar de Sve@r
Expert éminent sénior https://www.developpez.com
Le 08/12/2021 à 15:21
Citation Envoyé par tabouret Voir le message
Oui sauf qu'un reboot une fois par semaine (possiblement) n'est pas acceptable pour la majorité des clients. Evidemment j'ai proposé une fois par semaine, ça a été refusé. D'où le cas d'utilisation du 3ème lundi du mois.
Hé voilà. Le souci du besoin. Toi tu as des clients qui comptent sur une HD de tes serveurs et pas moi. D'où le fait que le choix d'un outil plutôt qu'un autre se réfléchit au cas par cas.

Citation Envoyé par tabouret Voir le message
sed est plus facile à mettre en oeuvre que awk, c'est son seul avantage.
C'est pas ce que j'avais en tête. Je pensais plutôt à la "lourdeur" de l'un vis à vis de l'autre. Utiliser awk là où sed suffit, c'est utiliser un marteau pilon pour ouvrir une noix.

Citation Envoyé par tabouret Voir le message
Et non cron c'est les tâches régulières sur serveur.
Anacron, les tâches régulières sur PC.
Hum... j'ai du mal à voir la différence. Ou alors tu penses au fait qu'un serveur ne s'arrête jamais rendant alors anacron inutile. Perso je te dirai que j'ai jamais utilisé anacron et si mon PC est éteint au moment où la tâche devait se lancer ben tant pis, ça attendra la prochaine fois. Mais c'est pareil, encore une fois parce que j'ai pas ce souci de HD

Citation Envoyé par tabouret Voir le message
(d'ailleurs peu de gens savent comment paramétrer des timers Systemd en production).
Bah, ça doit s'apprendre comme le reste.

Citation Envoyé par tabouret Voir le message
Mais tu sais c'est exactement le même débat qu'avec policykit vs sudo.
Pour ma part, inutile d'installer sudo sur un système mais qui sait vraiment utiliser polkit? d'où le fait que nous laissons aussi sudo en production.
Pareil, je ne connais même pas cet outil polkit. Mais quelque chose me dit que même le jour où je le connaitrai, je continuerai à dire "ok, maintenant je connais deux outils donc j'ai deux fois plus de choix" et non pas "oh là là polkit est bien mieux que sudo, vite oublions cette erreur de la nature "
1  0 
Avatar de edrobal
Membre actif https://www.developpez.com
Le 03/12/2021 à 10:11
Citation Envoyé par defZero Voir le message
Qu'en pensez-vous ?

Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.
Pour modifier cron, il faut être root.
0  0 
Avatar de Ti-Slackeux
Membre confirmé https://www.developpez.com
Le 03/12/2021 à 12:16
Citation Envoyé par edrobal Voir le message
Pour modifier cron, il faut être root.
Bonjour et tout faux.
N'importe qui sous Linux peut utiliser la commande
Code : Sélectionner tout
crontab -e
pour modifier sa propre crontab.

hth,
0  0 
Avatar de tabouret
Membre éclairé https://www.developpez.com
Le 08/12/2021 à 11:10
Citation Envoyé par Sve@r Voir le message
Bonjour

Normal puisqu'il n'a pas été fait pour ça !!! Ah ben ma voiture n'arrive pas à la cheville des avions (pas de ADI, pas de pilotage automatique, impossible de la faire voler sans lui rajouter des ailes et j'en passe)

cron contient 3 paramètres de datation
  • la datation horaire (à quelle heure dans la journée)
  • la datation mensuelle (quel jour du mois et quel mois de l'année)
  • la datation hebdomadaire (quel jour de la semaine)

avec cette spécification que si une datation mensuelle et hebdomadaire sont explicitement spécifiées (donc avec autre chose que l'étoile), il s'exécutera alors si l'une ou l'autre des dates se présente. Autrement dit je programme un truc le 31/12 le dimanche, le truc s'exécutera tous les 31/12 et aussi tous les dimanches. C'est comme ça que les concepteurs l'ont voulu et c'est comme ça que les concepteurs l'expliquent. Fatalement si ce n'est pas comme ça que toi tu veux l'utiliser, à toi de coder ce qu'il faut pour combler. Mais ce n'est pas parce que tu ne veux pas l'utiliser de la façon dont il a été conçu que ça doit être sa faute à lui !!! Justement Linux se veut assez souple et ouvert pour permettre l'utilisation d'autres outils plus adaptés (anacron, at, etc). Tu ne l'aimes pas ok, ce n'est pas une raison pour affirmer "qu'il n'arrive pas à la cheville d'autres trucs que tu aimes". Et puis ce n'est pas parce qu'un truc est plus récent, plus "moderne" qu'un autre qu'il sera forcément mieux tout le temps. Tout le monde se fout de la tronche des russes qui ont encore des ordinateurs à lampe en activité alors que nous on a des crays. Sauf que le jour où on se prend une IEM dans la tronche, les ordinateurs russes continueront à fonctionner tandis que nous, on sera dans le noir. Donc peut-être que dans d'autres situations que toi tu n'as pas mais que d'autres peuvent avoir c'est cron qui aura l'avantage.

Je pense que tu n'as pas bien réfléchi à tout ça.
Je pense que tu n'as pas vraiment réfléchi au problème.
Cron a été crée pour faire des tâches planifiés, tout comme les timers Systemd. ils ont exactement le même but.
Définir un OU logique entre day of month et day of week est une erreur de conception que Systemd (agissant comme un ET logique), bien plus souple, à corriger.

La preuve, pour corriger ce défaut de conception de Cron, tu es obligé de rajouter la commande "test" si tu veux imiter le comportement de Systemd. Bref du bricolage degueula....Rajouter une commande dans la commande finale, tu y perds en lisibilité.

Idem pour la randomisation de démarrage, Cron en est tout à fait incapable. Et ce ne sont que des choses parmi d'autres qui font que les timers Systemd sont bien au dessus de Cron. Je ne crache pas sur Cron mais il faut savoir voir quand une chose est meilleur qu'une autre.

J'ajouterai que Cron ne fait strictement rien de mieux que ce que ne font déjà les timers Systemd et des cas d'utilisation j'en ai vu à la pelle sinon je t'en pris donne moi un seul exemple.
0  0