CronRAT, un cheval de Troie discret sur serveurs Unix

Gloops · Le 26/11/2021, à 09:23

Bonjour,
J'ai souvent lu qu'il était inutile de protéger les systèmes Unix car le faible déploiement ne motive pas les pirates.
Méfiance.
Des serveurs commerciaux sont gérés sur Unix. Ils font de la vente en ligne, et donc voient passer des numéros de cartes de crédit valides.
CronRAT se cache, sous une forme cryptée, dans une tâche planifiée Cron, à une date invalide (31 février), un endroit où personne ne va penser à aller voir.
Et quand un certain nombre de conditions sont réunies, il contacte un autre serveur, et là les attaquants ont le champ libre pour prendre le contrôle de la machine.

https://www.bleepingcomputer.com/news/s … lid-dates/

Une fois ceci développé, l'expérience acquise, une fois le développeur en électron libre, l'effort est moindre ensuite pour aller épier Madame Michu.

Vobul · Le 26/11/2021, à 11:06

Un meilleur lien : https://sansec.io/research/cronrat

Mais j'ai pas compris comment ils arrivent sur le système. J'imagine via diverses failles du serveur web non mis à jour mais ce n'est pas clair... Et j'ai du mal à voir comment il peut obtenir les données de carte bancaire, car la plupart du temps les sites d'e-commerce redirigent sur un service certifié PCI-DSS, donc le site tout pourri sous wordpress/magento lui ne voit jamais les données de la carte. Bon bien sûr il doit y avoir des exceptions. Mais si madame michu achète sur des sites réputés et utilise la fonction "carte unique", y'a pas de soucis !

J'ai souvent lu qu'il était inutile de protéger les systèmes Unix

Déjà il faut différencier les serveurs qui sont attaqués en permanence par des centaines d'ip et les ordis à la maison derrière une box. C'est pas le même threat model du tout. Ensuite il ne faut pas utiliser le terme "Unix". On utilise GNU/Linux, et GNU is Not Unix !!!

EDIT: plus d'infos sur le type d'attaque : https://www.riskiq.com/what-is-magecart/

Dernière modification par Vobul (Le 26/11/2021, à 11:13)

Gloops · Le 26/11/2021, à 11:29

Vobul a écrit :

Un meilleur lien : https://sansec.io/research/cronrat
Mais j'ai pas compris comment ils arrivent sur le système. J'imagine via diverses failles du serveur web non mis à jour mais ce n'est pas clair... Et j'ai du mal à voir comment il peut obtenir les données de carte bancaire, car la plupart du temps les sites d'e-commerce redirigent sur un service certifié PCI-DSS, donc le site tout pourri sous wordpress/magento lui ne voit jamais les données de la carte. Bon bien sûr il doit y avoir des exceptions.

Normalement, ça devrait être comme ça. Parfois on tombe quand même sur un développeur à qui on a dit de développer le truc, qui est supposé savoir le faire alors il n'a pas bronché, mais quand même ça aurait été mieux de sous-traiter.
Ça se voit aussi avec de grosses administrations qui tirent les coûts vers le bas.

Mais si madame michu achète sur des sites réputés et utilise la fonction "carte unique", y'a pas de soucis !

Oui, de même que quand on va au distributeur de billets, il faut avoir l'idée de regarder au-dessus si il n'y aurait pas un bidule louche d'installé, c'est arrivé. Heureusement c'est rare, mais c'est comme de regarder derrière avant d'ouvrir sa portière : neuf fois sur dix il n'arrive personne, mais en ne regardant pas on joue à "paf ! le cycliste".

La e-carte c'est bien, mais c'est quand même plus lourd comme procédure, alors on s'en sert si on a un doute sur le commerçant, voire envie de mettre des guillemets à commerçant.
La dernière fois que je suis allé sur le site de la Banque Postale pour avoir ça, je ne l'ai pas trouvé. Ça s'est soldé par une opposition à la carte la semaine d'après. Récemment ils m'ont balancé une pub pour ça, alors ils ont dû le remettre.

Après, on ne va pas insister sur les gens qui vous offrent un service "gratuit", mais qui ont besoin de votre numéro de carte bleue pour vérifier que vous êtes majeur
Bien sûr si votre carte bleue est périmée vous n'êtes pas majeur.

J'ai souvent lu qu'il était inutile de protéger les systèmes Unix
Déjà il faut différencier les serveurs qui sont attaqués en permanence par des centaines d'ip et les ordis à la maison derrière une box. C'est pas le même threat model du tout.

Exact. De même que quand un camion est braqué pour sa cargaison, Madame Michu n'est pas directement concernée, mais ça lui rappelle quand même de verrouiller sa portière au feu rouge, surtout si c'est [modéré].

Ensuite il ne faut pas utiliser le terme "Unix". On utilise GNU/Linux, et GNU is Not Unix !!!

Ça m'a toujours fait rire, ça. On sait juste ce que ce n'est pas, quoi. Ce que c'est, n'avez qu'à aller voir ...

Dernière modification par Gloops (Le 26/11/2021, à 11:31)

bruno · Le 26/11/2021, à 12:27

Un cheval de Troie tellement discret qu'il n'est connu et repérable que par une seule entreprise qui vend des solutions de sécurité.
Bien entendu, il n'est fait aucune mention des méthodes et des failles exploitées pour arriver à l'installer sur un serveur.

Bref, dans la langue d'origine de l'article : FUD and Bullshit.

Gloops · Le 26/11/2021, à 13:01

En effet, c'est un aspect à prendre en compte.

Ah en revanche je vois qu'il faut éviter de parler des menaces de la vie courante. Dommage ...

bruno · Le 26/11/2021, à 13:08

Tu peux éventuellement parler des menaces de la vie courante mais c'est hors-sujet dans une section d’entraide sur Ubuntu. D'ailleurs j'ai modéré uniquement la remarque que j'ai considéré comme sexiste. Fin du HS.

Gloops · Le 26/11/2021, à 13:48

C'est une appréciation possible. Mais que des menaces ciblent spécifiquement une partie de la population signifie que c'est la vie qui est sexiste. Pas le fait de le dire.

Ça juste pour dire pourquoi j'ai trouvé que ça entrait dans le cadre de la discussion. Après, OK rien à ajouter.

iznobe · Le 26/11/2021, à 16:00

Bonjour , il suffit de tester s ' il est effectivement possible de planter une tache cron bidon en date du 31/02 pour verifier la veracité du truc .
Si toutefois c' etait possible , null doute qu ' un patch sortiras bientot pour corriger ce probleme .

EDIT : je viens de tester , on peut bien installer une tache cron en date du 31 / 02 .
cela ne prouve pas pour autant l ' existence du cronRAT .

Si vous voyez passez une MAJ de crontab et d ' autres trucs sous peu , il est alors possible que ce truc existe .
wait and see

De plus , empecher de programmer une date du 30 ou 31 lorsque le mois de fevrier est selectionné ne me semble pas insurmontable a coder .

je comprends pas pourquoi il serait indetectable sauf pour eux , la simple commande crontab - l , fait apparaitre toutes les taches cron de l' user , et sudo crontab -l celle de root , qu ' est ce qui empecherait de voir la tache ?
ca sent plutot le fake ce truc là .

Dernière modification par iznobe (Le 26/11/2021, à 16:09)

Gloops · Le 26/11/2021, à 16:20

iznobe a écrit :

De plus , empecher de programmer une date du 30 ou 31 lorsque le mois de fevrier est selectionné ne me semble pas insurmontable a coder .

J'imagine. Il y a des systèmes qui stockent les dates sous forme numérique, par calcul du nombre de jours passés depuis le démarrage du calendrier utilisé.

Je crois bien que j'ai essayé un jour, si on saisit une date comme 31/02, ça va être stocké comme étant le 3 mars, je suppose que pour une année bissextile ça sera le 2 mars. Du coup pour ce qui est de l'aspect furtif, c'est raté.

Au fait c'est quoi l'enjeu, si la date n'est pas valide la tâche n'est pas affichée dans l'interface utilisateur ?

Autrement pour faire un système vulnérable il n'y a qu'à demander à Microsoft : quand on agrandit un peu la police système dans Windows 10, la moitié du système est illisible, donc le pirate qui réussit à avoir un accès à la machine peut faire tout ce qu'il veut, après.

Mais prendre ça comme exemple n'est pas forcément le meilleur moyen de tirer tous les enseignements que ce "truc" peut apporter.

iznobe · Le 26/11/2021, à 16:35

Gloops a écrit :

iznobe a écrit :
De plus , empecher de programmer une date du 30 ou 31 lorsque le mois de fevrier est selectionné ne me semble pas insurmontable a coder .
Au fait c'est quoi l'enjeu, si la date n'est pas valide la tâche n'est pas affichée dans l'interface utilisateur ?

mouais peut etre , mais bon , suffit de faire " crontab -l ou sudo crontab -l " , et tu as la liste complete des taches , un admin ne passera pas a coté ... peu importe les dates .

Apres on sait tres bien ( suffit de voir croc soft ) que les GUI c ' est jamais au top et que les devs peuvent effectivement occulter des dates non valides dans un contexte GUI . apres faut en vouloir pour se casser la tete a faire un GUI et planquer les 2 dates invalides du 31 et 30 / 02 , ca revient au meme que de le faire directement dans la crontab pratiquement .

Dernière modification par iznobe (Le 26/11/2021, à 16:39)

bruno · Le 26/11/2021, à 17:33

Le truc du 31 février c'est déjà assez fumeux. Mais je vous invite à aller regarder le script Bash qui est horriblement alambiqué pour faire des trucs parfois très simples et dont on voit pas vraiment l'utilité. Je ne parle pas des techniques ridicules utilisées pour tenter de cacher le code (il ya d'autres moyens bien plus efficaces).

Autre truc qui me fait marrer, dans l'article il parlent « d'une fonctionnalité exotique du noyau pour établir une communication TCP » alors que l'utilisation des pseudo périphériques sous /dev/tcp est tout de même bien connue (exemple1, exemple2. Encore une fois c'est tordu, car on peut faire cela beaucoup plus simplement.

Gloops · Le 26/11/2021, à 17:38

Donc, apparemment, ça cible plutôt ceux qui ne connaissent pas trop le système ?

iznobe · Le 26/11/2021, à 17:43

ca ressemble fortement a un fake pour les non initiés oui .

kamaris · Le 27/11/2021, à 15:43

Un article sur developpez.com : https://securite.developpez.com/actu/32 … planifiee/

Nuliel · Le 27/11/2021, à 17:00

Pour info un RAT est déployé après qu'une vuln (ou simplement une mauvaise configuration) est exploitée. Un RAT tout seul ne sert à rien.
Pour donner un exemple, il y a quelques jours ma mère a reçu un mail imitant Colissimo (assez mal fait d'ailleurs), et contenait un lien vers un script obfusqué lançant powershell (donc tourne pas sous linux de base) et allait chercher un RAT. C'est l'action de l'utilisateur qui amène à télécharger un RAT de façon indirecte.

Des RAT, il y en a plein d'autres (pupyRAT, cobalt strike, empire, ...), et utiliser cron c'est pas nouveau...

Dernière modification par Nuliel (Le 27/11/2021, à 17:03)

Gloops · Le 27/11/2021, à 18:19

kamaris a écrit :

Un article sur developpez.com : https://securite.developpez.com/actu/32 … planifiee/

Ah oui là on est tout près de la traduction de ce que j'ai cité l'autre jour.

Dernière modification par Gloops (Le 27/11/2021, à 18:26)

Gloops · Le 27/11/2021, à 18:23

Nuliel a écrit :

Pour info un RAT est déployé après qu'une vuln (ou simplement une mauvaise configuration) est exploitée. Un RAT tout seul ne sert à rien.
Pour donner un exemple, il y a quelques jours ma mère a reçu un mail imitant Colissimo (assez mal fait d'ailleurs), et contenait un lien vers un script obfusqué lançant powershell (donc tourne pas sous linux de base) et allait chercher un RAT. C'est l'action de l'utilisateur qui amène à télécharger un RAT de façon indirecte.
Des RAT, il y en a plein d'autres (pupyRAT, cobalt strike, empire, ...), et utiliser cron c'est pas nouveau...

Ah oui des faux mails de Colissimo envoyés du serveur digitalocean.com à New York, j'en ai reçu un sacré paquet, et La Poste me prenait méchamment le chou à ne pas bouger.

Longtemps j'ai écrit au service abuse de digitalocean, et quand j'ai compris qu'ils se moquaient de moi j'ai arrêté et j'ai signalé ça à signalspam.fr, depuis ça s'est arrêté.

Autrement, des rats, on en trouve dans certaines caves, aussi. OK je sors ...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/11/2021, à 09:23

CronRAT, un cheval de Troie discret sur serveurs Unix

#2 Le 26/11/2021, à 11:06

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#3 Le 26/11/2021, à 11:29

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#4 Le 26/11/2021, à 12:27

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#5 Le 26/11/2021, à 13:01

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#6 Le 26/11/2021, à 13:08

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#7 Le 26/11/2021, à 13:48

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#8 Le 26/11/2021, à 16:00

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#9 Le 26/11/2021, à 16:20

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#10 Le 26/11/2021, à 16:35

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#11 Le 26/11/2021, à 17:33

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#12 Le 26/11/2021, à 17:38

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#13 Le 26/11/2021, à 17:43

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#14 Le 27/11/2021, à 15:43

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#15 Le 27/11/2021, à 17:00

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#16 Le 27/11/2021, à 18:19

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

#17 Le 27/11/2021, à 18:23

Re : CronRAT, un cheval de Troie discret sur serveurs Unix

Pied de page des forums