Un cheval de Troie infecte les systèmes Rasberry Pi

Si vous utilisez votre Raspberry Pi avec le login et le mot de passe par défaut, il a des chances d’être infecté par un cheval de Troie

Un cheval de Troie en informatique est un programme malicieux qui utilise une faille pour pénétrer vos défenses afin de réaliser d’autres opérations sur votre système. Les plus « gentils » vont juste chercher à se dupliquer encore et encore. Les plus méchants peuvent soit bloquer votre matériel, l’altérer ou tenter de voler vos données.

Il en existe un qui sévit sur Raspberry Pi depuis des années et le vidéaste John Hammond en explique les rouages sur une vidéo très didactique. Il y détaille la méthodologie employée et comment il cherche à infecter d’autres cartes de la fondation sur le réseau. C’est évidemment technique, en anglais de surcroit, mais cela reste intéressant.

C’est un utilisateur qui a alerté Hammond, lui fournissant la première piste. Sa carte, configurée avec les login et mot de passe fournis par défaut par le système, posait des problèmes. Notamment lors de sessions en SSH qui se clôturaient de manière impromptues. A chaque tentative de changement de mot de passe, celui-ci était changé à chaque redémarrage. 

Après avoir récupéré le fichier incriminé auprès de cet internaute, le  vidéaste a commencé à analyser son comportement et ses méthodes. Et le principe de base de ce cheval de Troie est d’utiliser IRC pour se propager sur la toile.  Recherchant d’autres cartes Raspberry Pi, avec les réglages d’installation de sécurité laissés par défaut. Ainsi, de carte en carte gagner du terrain. Ce « virus » semble exister sur la toile depuis 2017 et semble actif depuis lors. C’est la première fois que j’entends parler d’un malware de ce type qui cible spécifiquement les cartes de la fondation Raspberry Pi. D’habitude, les outils de ce type cherchent des machines performantes pour réaliser des tâches spécifiques. Comme miner des cryptomonnaies en tâche de fond en utilisant vos ressources ou faire partie d’un essaim de machines esclaves pour attaquer des serveurs ou autres. Ici le choix s’est porté vers un profil de machine particulier dans, semble t-il, une simple volonté de voir son programme malveillant évoluer.

Le plus simple pour éviter ce type d’infection est donc évidemment de ne jamais, même pour un projet local non connecté, utiliser le login et mot de passe par défaut du système. Préférer un login et mot de passe digne de ce nom, quitte  à le documenter si il s’agit d’un Raspberry Pi utilisé dans un projet partagé.


Soutenez Minimachines avec un don mensuel : C'est la solution la plus souple et la plus intéressante pour moi. Vous pouvez participer via un abonnement mensuel en cliquant sur un lien ci dessous.
2,5€ par mois 5€ par mois 10€ par mois Le montant de votre choix

Gérez votre abonnement

18 commentaires sur ce sujet.
  • 30 mai 2023 - 18 h 15 min

    Quand on a un ssh ouvert sur l’extérieur, le fichier /var/log/auth.log qui contient toutes les demandes de login, réussies ou non, montre beaucoup d’essais avec les divers couples utilisateur/mot-de-passe par défaut de tout ce qui existe d’équipements réseau, caméras, distributions…

    C’est quasi ininterrompu a un point que simplement avoir le bidule sur le réseau accessible de l’extérieur avec un ssh actif le temps de finaliser une installation avant de changer les identifiants peut suffire.

    Il n’y a pas que des truc performants de ciblés. N’importe quoi pouvant servir de relais à des attaques ou autre activité délictuelle est recherché… Avec le risque pour l’imprudent d’avoir un jour les amis du petit déjeuner défonçant la porte à 6h pétante si c’est vraiment grave.

    ssh est très visé (bien plus qu’un serveur https par exemple), car il donne accès à des unices qui niveau réseau permettent beaucoup de choses (tunnels, proxy…) en standard avec ce simple serveur couteau suisse.

    Répondre
  • 30 mai 2023 - 22 h 58 min

    @yann: Et je compléterai en évoquant Fail2Ban qui détecte et bloque ces tentatives d’intrusions. Et pour ma part j’ai configuré sshd pour interdire l’authentification par mot de passe et n’accepter que les certificats. C’est très efficace.

    Répondre
  • bob
    31 mai 2023 - 0 h 04 min

    C’est quand même la première bonne pratique de base.

    Il me semble que le logiciel de la fondation pour installer le système sur la carte sd oblige à saisir un nouveau user password.

    Ça fait des années que la fondation indique qu’il ne faut pas laisser user password par défaut.

    Répondre
  • 31 mai 2023 - 0 h 09 min

    Franchement, se connecter en ssh en gardant les réglages par défaut du serveur, en particulier mot de passe et port par défaut, c’est chercher les emmerdes quand même. Le béa ba c’est de se connecter avec le système clé publique/clé privée, ed25519 (préférable et de loin à rsa) et de changer le port pour un port au delà des 1024. Il y encore d’autres réglages qui renforcent ssh.

    Répondre
  • 31 mai 2023 - 9 h 17 min

    @aka_mgr:

    Oui, fail2ban est un outil efficace… Mais pour ma part le port ssh est désormais ouvert via ma domotique auto-hébergée en https si besoin, pour 30s laissant le temps de se connecter. https étant peu attaqué…

    Répondre
  • 31 mai 2023 - 9 h 38 min

    Si je devais ouvrir SSH vers l’extérieur ce serait uniquement avec du port-knocking.
    Autrement si vous n’utilisez pas SSh depuis l’extérieur alors redirigez 22 vers un tarpit, collectez les logs et faites tourner fail2ban, ça pénalisera quelques robots.

    Répondre
  • 31 mai 2023 - 10 h 31 min

    Il y a un tas de commentaires intéressants.
    Ou trouver une compilation correcte de tous ces conseils sans devoir passer un temps important à se former à la ligne de commande sous Linux ?

    Répondre
  • gUI
    31 mai 2023 - 10 h 40 min

    @Emmanuel: Malheureusement c’est comme tout, il faut passer du temps pour apprendre… Les recettes toutes faites, ça ne marche jamais tout simplement parce que chacun a un besoin particulier et que la recette ne correspondra jamais exactement à ce qu’il cherche.

    Répondre
  • gUI
    31 mai 2023 - 10 h 43 min

    @Cinos: Non le SSH est très bien pour une utilisation directement ouverte, à condition d’avoir respecté les conditions de base : pas de login/mdp par défaut, des mots de passes sérieux, et si possible uniquement des clés. Fail2ban histoire d’éviter de se remplir les logs de tentatives infructueuses et ça roule.

    D’ailleurs le port 22 SSH est la seule porte d’entrée sur mon réseau local depuis des années, ça se passe très bien (je m’en sers même de VPN du pauvre).

    Répondre
  • 31 mai 2023 - 12 h 34 min

    Les distribs pour les SBCs devraient forcer le changement de mot de passe, voir la création d’un utilisateur non privilégié avant de proposer d’ouvrir des ports de connexion. Voir si l’utilisateur veut configurer l’appareil en ssh lors de la première connexion distante.
    Ce cas me rappelle l’époque où WordPress proposait encore une installation avec des identifiants pas défaut.

    Répondre
  • 31 mai 2023 - 14 h 07 min

    @gUI:
    J’ai aussi SSH ouvert sur port 22 standard et sans clé. Bien sûr un user et mot de passe non standard. J’ai juste ajouté fail2ban avec un réglage à 2 échecs.
    Je suis attaqué à longueur de journée mais fail2ban fait son boulot et ça se passe bien comme ça depuis 15 ans.

    Répondre
  • 31 mai 2023 - 14 h 21 min

    @gUI:
    J’en conviens que c’est très bien depuis que ça a totalement remplacé le telnet mais il est préférable de ne jamais rediriger un port sauf si nécessaire et en connaissance de causes.
    Le UPNP c’est génial, suffit d’aller voir insecam.com pour se rendre compte de ce qu’un gadget IOT peut offrir.

    Donc de préférence désactiver l’UPNP de sa box internet est le strict minimum pour éviter qu’un Raspberry fraîchement connecté au réseau reçoive des attaques.

    Répondre
  • Luc
    31 mai 2023 - 18 h 15 min

    @Cinos: ah ben merci de m’avoir fait découvrir insécable.com je m’en vais explorer ça !
    J’adore le petit texte en page d’accueil qui illustre bien le problème des mots de passe par défaut et qui n’ont pas été changés  » If you do not want to contact us by e-mail, you can still remove your camera from Insecam. The only thing you need to do is to set the password of your camera. »

    En fait, c’est juste dingue. ..

    Répondre
  • 31 mai 2023 - 20 h 30 min

    Perso connexion ssh avec clés publique / privées et desactivation du ssh avec login, bien sûr avec passphrase sur ma clé. Les paranoïaques changeront régulièrement la clé mais je’ele fais pas.

    Répondre
  • 31 mai 2023 - 20 h 33 min

    J’étais persuadé de l’avoir lu ici, la suppression du mdp par défaut via une maj de l’OS. Pas trouvé via le moteur de recherche.

    Mais ça doit dater d’avril 2022 d’après cet article, par exemple :
    https://raspberry-pi.developpez.com/actu/332475/La-nouvelle-mise-a-jour-de-l-OS-du-Raspberry-Pi-supprime-l-utilisateur-et-le-mot-de-passe-par-defaut-Pour-se-conformer-aux-nouvelles-lois-qui-interdisent-les-identifiants-par-defaut/

    Donc tous les pi à jour d’un an ne sont pas concernés par ce cheval de Troie.

    Répondre
  • 1 juin 2023 - 7 h 11 min

    Très intéressant de lire vos commentaire et voir vos techniques pour sécuriser vos serveurs SSH. Pour ma part je change le mot de passe directement à la première connexion au raspberry pi. Je recommande comme dans les commentaires l’utilisation de fail2ban à minima pour une machine exposé sur internet et les clef à la place du mot de passe. même si pour ma part je n’applique pas à chaque fois le premier conseils et jamais le second.

    Répondre
  • 1 juin 2023 - 10 h 17 min

    @F4IFB: Ce qui serait vraiment cool, ce serait de rédiger collégialement un « guide ultime de sécurisation de SBC » sous Linux avec les bonnes pratiques, les bons outils et comment les paramétrer. Sur le forum de Minimachines par exemple. Ensuite je pourrais l’indexer sur le site et on aurait alors une source complète pour les lecteurs moins compétents.
    https://forum.minimachines.net/

    Répondre
  • 1 juin 2023 - 11 h 21 min

    @gUI:
    Je continue personnellement à privilégier les mots de passe pour tout: C’est quand même plus simple que d’avoir toujours sa clef sur soi car ici on n’a besoin que de sa tête!
    Surtout que le risque est aussi d’avoir un exploit visant le serveur ssh lui-même ou le système d’authentification qu’il utilise (et il y a bien du choix, tout ce qui est dispo via PAM en plus du natif).
    Comme dit par ailleurs, le port-knocking peut être utilisé mais depuis que mon FAI m’a passé en IPv6 knockd s’est révélé inadapté: Coincé à l’IPv4…
    Donc l’ouverture se fait via la domotique auto-hébergée en https (un switch virtuel déclenchant un script ouvrant le port 22 pour 30s), elle aussi utilisant une config fail2ban adaptée mais qui contrairement à ssh, ne me donne jamais de ban: L’examen des logs https est clair, ne montrant que des robots d’indexation de moteurs de recherche qui lâchent l’affaire au robots.txt ou la page de login.

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *