Discussion :

[Sandra Coret]

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

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

[defZero]

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.

[A3gisS3c]

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.

Tout à fait d'accord. Surtout qu'entre nous, 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).

[edrobal]

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.

[Ti-Slackeux]

Pour modifier cron, il faut être root.

Bonjour et tout faux.
N'importe qui sous Linux peut utiliser la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

crontab -e

pour modifier sa propre crontab.

hth,

[Sve@r]

Bonjour

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.

tout faux.
N'importe qui sous Linux peut utiliser la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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"...

[A3gisS3c]

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.

[greg91]

Comment un site web pourrait compromettre crond ?
Je voie pas (si PHP est bien configuré).

[eomer212]

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é..

[becket]

Le 31 février ? Même pas peur !

[MPython Alaplancha]

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?