Journal Un ransomware tout à fait déloyal ... et inquiétant

Posté par  . Licence CC By‑SA.
Étiquettes :
9
2
sept.
2016

Il semblerait que des serveurs linux aient été attaqués par un ransomware particulièrement violent. Il s'attaque aux fichiers systèmes non pas en les chiffrant, mais en les détruisant. Ce qui ne l'empêche pas de demander une rançon en assurant qu'il va restituer les fichiers.

La chose s'appelle Fairware… ce qui est particulièrement cocasse pour un truc aussi peu "fair" que possible.

Celui qui rapporte sa mésaventure précise :

ma machine Linux a été piratée (…) avec un accès root et le répertoire www a été supprimé

Et là, je me pose une question certainement très naïve… comment un virus peut-il avoir un accès root ? Quid du mot de passe ?

  • # Backups et root

    Posté par  (site web personnel) . Évalué à 1.

    J'avoue qu'avoir accès root indique une faille plutôt énorme. Il est vraiment important de faire des backups tous les jours et surtout de les dupliquer sur d'autres disques / serveurs.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Backups et root

      Posté par  (site web personnel) . Évalué à 4.

      comment un virus peut-il avoir un accès root ?

      dpkg -i, rpm -U, …

    • [^] # Re: Backups et root

      Posté par  . Évalué à -8. Dernière modification le 03 septembre 2016 à 14:58.

      C'est peut-être une stratégie de sécurité pour encourager les pirates à faire eux même tes sauvegardes !

      La technique est secure, il n'y a que de mauvais usages et parfois une confiance aveugle en l'outil.

      Alors la faille c'est quoi en l'occurrence : l'absence de backup, la sensibilité à un exploit ou la technique de Ransomware ?

      Des outils comme un IDS ou un Waf suffiraient ils à corriger le tir ?

  • # Peu crédible

    Posté par  . Évalué à 2.

    Une question posée dans un forum et hop, "les serveurs linux sont infectés". La source:
    http://www.bleepingcomputer.com/forums/t/625009/fairware-ransomware-help-support-read-metxt/
    Cela sent l'hoax…

    • [^] # Re: Peu crédible

      Posté par  . Évalué à 3.

      Cela sent l'hoax…

      Un des utilisateurs (si ce n'est pas un hoax/fake) indique que : "through log file, I noticed that they used brute force SSH attack.". Ce n'est sans doute pas un virus et il n'y a pas de quoi s'alarmer, mais en tout cas peut-être qu'un fail2ban peut éviter ce genre de problème.

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Peu crédible

          Posté par  (site web personnel) . Évalué à 7.

          Oui, enfin avec un mot de passe correct, un accès root désactiver et un fail2ban, c'est déjà largement suffisant…

          Perso, j'ai un accès par clés, mais j'utilise un login cryptique qui fait que déjà, je n'ai jamais vu quelqu'un trouver mon login dans mon auth.log.

          • [^] # Re: Peu crédible

            Posté par  . Évalué à 9.

            trouver mon login dans mon auth.log.

            Ils ont modifié ton auth.log !

      • [^] # Re: Peu crédible

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        en tout cas peut-être qu'un fail2ban peut éviter ce genre de problème

        On peut aussi utiliser les temps entre tentatives de connexion sur le firewall.
        Petit exemple avec PacketFilter :

        table <ssh-bruteforce> persist file "/etc/pf.table.fail2ban"
block in quick from <ssh-bruteforce>
pass in quick on $ext_if proto tcp from any to ($ext_if) port ssh flags S/SA keep state \
( max-src-conn 100, max-src-conn-rate 3/10, overload <ssh-bruteforce> flush global)

        Ensuite, moi, je rajoute du One Time Password en plus :)

        • [^] # Re: Peu crédible

          Posté par  (site web personnel) . Évalué à 2.

          on peut aussi ajouter le port knocking

          https://fr.wikipedia.org/wiki/Port_knocking

          ウィズコロナ

          • [^] # Re: Peu crédible

            Posté par  (site web personnel, Mastodon) . Évalué à 5.

            Ou mettre ssh sur un port autre que 22

            La gelée de coings est une chose à ne pas avaler de travers.

            • [^] # Re: Peucrédible

              Posté par  (site web personnel) . Évalué à 1.

              ça change quoi à part eventuellement ralentir l'attaquant ?

              • [^] # Re: Peucrédible

                Posté par  . Évalué à 10. Dernière modification le 02 septembre 2016 à 13:19.

                ça ne ralentit pas un attaquant. ça réduit le nombre d’attaquants.

                • [^] # Re: Peucrédible

                  Posté par  . Évalué à 0.

                  Ouais, débrancher la prise ethernet aussi, si tu vas par là…

                  Toutes ces techniques à base de bricolage me semblent relever de la sécurité par l'obscurité—en gros, on se débrouille pour avoir un comportement non-standard, et on espère que ce comportement non-standard va dérouter les bots malveillants. Certes, ça va peut-être dérouter les bots, mais ça va aussi dérouter les gens de bonne foi qui essayent d'utiliser le serveur, et qui ont peut-être des trucs plus intéressants à faire dans leur vie que de tenter de comprendre pourquoi ils n'arrivent pas à se logguer.

                  • [^] # Re: Peucrédible

                    Posté par  . Évalué à 10.

                    dérouter les gens de bonne foi qui essayent d'utiliser le serveur

                    Les gens de bonnes foi amenés à se connecter en SSH tu peux très bien leur communiquer un port alternatif…

                    Pour un service mail par exemple ça serait un peu plus galère (les clients mail sont configurés avec les ports par défaut), mais SSH ce n’est pas le bon exemple.

                    • [^] # Re: Peucrédible

                      Posté par  . Évalué à -3.

                      mais SSH ce n’est pas le bon exemple.

                      Tu as plein de raisons pour lesquelles tu peux vouloir te connecter à plusieurs machines, si à chaque fois tu dois te rappeler du numéro du port, tu n'es pas sorti de l'auberge… Tu vas aussi faire foirer tous les scripts qui font un scp, les synchro git par ssh, etc.

                    • [^] # Re: Peucrédible

                      Posté par  (site web personnel) . Évalué à 4.

                      Les gens de bonnes foi n'ont par contre pas tous la main sur le firewall entre eux et toi. Exemple typique, être chez un client pour une mission.

                      • [^] # Re: Peucrédible

                        Posté par  . Évalué à 4.

                        Si tu es chez un client, tu n'as pas à te connecter sur d'autres machines que les siennes. Donc elles sont en port 22 si l'admin a tout verrouillé.

                        Tu peux par contre avoir à te connecter à des serveurs qui appartiennent à ton entreprise afin de travailler pour ce client. Bon ok, il faut réouvrir le port 22 de ton serveur. Mais sérieusement, tu as eu combien de cas dans ta vie ? J'en ai eu 3, et à chaque fois avec des admins totalement incompétents.
                        Pour ma part ce n'est pas gratuit : « monsieur le PDG, votre réseau ne laisse pas passer les flux sortants, ce qui est mauvais signe quant à la pertinence de vos configurations. Nous devons adapter des choses imprévues, qui de plus impactent la sécurité. C'est 120 € ». Je n'ai pas encore d'exemple de refus. J'ai seulement des demandent d'explications, auquelles je réponds par une proposition de formation réseau de base ; la direction pige immédiatement et l'affaire est résolue.

                        • [^] # Re: Peucrédible

                          Posté par  . Évalué à 2.

                          Hou Hou, j'ai souvenir d'un client qui était venu nous voire justement pour trouer la sécurité (pas trop quand même, juste un tunnel ssh) pour faire fonctionner un morceau de l'appli, mais qui en raison de la politique de sécurité de l'entreprise, ne pouvait pas fonctionner. Le temps de mettre à jour la config, il a bien fallu passer autour. (Le problème des grosses entités, faut que ce soit validé par tous les n+[1-3], avec le risque que quelqu'un qui n'y connait rien bloque la procédure, ensuite demander au gestionnaire du réseau (qui est encore une autre entreprise), de mettre à jour la conf…

                          Bref t'en as pour 6 mois de procédure pour avoir ta mise à jour de configuration, le tout pour une passerelle qui va durer 8 mois; donc si on respecte la procédure, 2 mois d'activité.

                          Évidemment si une personne s'était penché sur la problématique avant la mep, on aurait pu faire la demande avant, mais le dev pensait que ça allait passer par les chemins habituels, pas de bol, on lui a spécifié ce détail pas longtemps avant le rendu :P.

                          Ah je vous avais dit que chez ce client faut se battre pour avoir les spec avant le début du développement (et encore quand c'est pas à nous de les rédiger à partir d'une expression du besoin).

                          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                        • [^] # Re: Peucrédible

                          Posté par  (site web personnel) . Évalué à 3.

                          Bof, ça ne me choque pas que les ports en sortie soit également bloqués pour ne pas faciliter l'exfiltration de données sensibles, surtout par un protocole comme le SSH ne permettant pas de voir ce qui passe dedans. Bien sûr, tout dépend du contexte (s'il n'y a pas de données sensibles ou que c'est de toute façon troué de partout, ce n'est pas la même histoire).

                          • [^] # Re: Peucrédible

                            Posté par  . Évalué à 2.

                            Bloquer les ports non standards ne va pas empêcher de faire sortir des données.
                            Si tu veux empêcher qu'on puisse sortir en SSH, il faut bloquer tout SSH, donc aussi le port 22. --> argument invalide.

                  • [^] # Re: Peucrédible

                    Posté par  (Mastodon) . Évalué à 10.

                    Toutes ces techniques à base de bricolage me semblent relever de la sécurité par l'obscurité — en gros, on se débrouille pour avoir un comportement non-standard, …

                    Oui, je suis bien d'accord, mais ça a quand même un gros avantage : ça réduit énormément le bruit dans les logs, ce qui facilite bien la mise en œuvre des actions de surveillance.

                  • [^] # Re: Peucrédible

                    Posté par  . Évalué à 4.

                    Moi je bloque complètement ssh et j'ouvre en grand telnet.
                    Plus aucun bot n'essaie ces trucs là
                    Et là le pirate, il arrive et il se dit "nan, trop gros, ça se peut pas, y'a un truc!" et du coup il soupçonne un truc archichiadé conçu pour le choper et il passe son chemin.

                    Et je l'ai trop eu, tu vois!

              • [^] # Re: Peucrédible

                Posté par  . Évalué à 10.

                S'il y a des gens qui sont susceptible de vouloir t'attaquer toi précisément, ça change pas grand chose, mais ça mange pas de pain (sauf si ça fait chier tes utilisateurs).

                Si ton risque c'est les bot qui fouillent le net à la recherche vulnérabilité, c'est efficace à près 100%.

                Mon expérience sur mon serveur perso :

                • sur le port 22 la machine était perpétuellement en train d'être brute-forcée
                • sur le port 2222 (port non standard presque standard) c'était juste occasionnel (genre deux séries de tentative par semaine)
                • sur le port xxxxx pas une seule tentative en plusieurs mois

                • [^] # Re: Peucrédible

                  Posté par  . Évalué à 7.

                  Perso j'ai une nette préférence pour fail2ban avec une limite à 10 tentatives. De toutes façons les bots se plantent sur les logins (seul un login peut facilement être devinable, et c'est pas dans les premier testés)

                  Le changement de port à tendance à bloquer lorsqu'on passe par des firewall un peu psychopathe qui limitent les ports de destination.

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Peu crédible

              Posté par  (site web personnel) . Évalué à 4.

              Ou utiliser un service en onion tor.

              point bonus si on utilise le système d’autorisation en mode "Stealth", y a 0 scan possible: https://www.void.gr/kargig/blog/2015/04/10/onion-service-authorization-cookie/

        • [^] # Re: Peu crédible

          Posté par  . Évalué à 0.

          Tu l'a configuré comment ton accès OTP sur ton serveur Linux ?

  • # Élévation des privilèges

    Posté par  . Évalué à 5.

    comment un virus peut-il avoir un accès root ? Quid du mot de passe ?

    Un "simple" bogue dans le noyau Linux suffit pour réaliser une Élévation des privilèges .
    Le net regorge d'exemples à ce sujet.

    • [^] # Re: Élévation des privilèges

      Posté par  . Évalué à 2.

      Il faut quand même avoir un compte sur la machine à infecter…

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Élévation des privilèges

        Posté par  (site web personnel) . Évalué à 4.

        Ou une faille sur un logiciel qui tourne sur la machine.

        blog.rom1v.com

        • [^] # Re: Élévation des privilèges

          Posté par  . Évalué à 6.

          Oui, l'attaque type, c'est une faille dans wordpress (ou jboss ou phpmyadmin ou…) qui permet d'uploader/exécuter un bout de code qui donnera un accès à la machine, et une élévation de privilège plus tard, on est root \o/.

          • [^] # Re: Élévation des privilèges

            Posté par  . Évalué à 4.

            Une faille de ce type devrait seulement donner accès à l'utilisateur www, qui n'a pas le droit de se logguer. Comment exploiter l'élévation dans ce cas? Il faut pouvoir la faire depuis l'appli elle-même!

            ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

            • [^] # Re: Élévation des privilèges

              Posté par  . Évalué à 8.

              Oui, une faille de ce type permet d'exécuter un programme en tant que www .
              Ce programme, l’attaquant le contrôle. Donc, ça peut être quelque chose genre "télécharger l'exploit, exécuter l'exploit => on devient root, et là, on ajoute par exemple notre clef publique à /root/.ssh/authorized_keys.
              Et, là, on peut se loguer. En root.

              Mais à aucun moment il n'y a besoin de se loguer en tant que www . Il "suffit" de pouvoir faire exécuter un programme de notre choix au serveur web, par l'intermédiaire d'une faille wordpress ou autre.

  • # Faille trouvée : Redis

    Posté par  . Évalué à 10. Dernière modification le 02 septembre 2016 à 10:07.

    La faille est dans le logiciel Redis, s'il n'a pas été mis à jour. Plus de détails dans cet article.

    Il est notable que :
    - les développeurs de Redis déconseillent de le déployer sur des machines accessible à Internet ;
    - il ont quand même sécurisé la configuration par défaut en Mai dernier ;

    Conclusion habituelle : ne jamais utiliser un logiciel en lui laissant les droits root.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Faille trouvée : Redis

      Posté par  (site web personnel) . Évalué à 6.

      Ce n'est pas une faille de Redis. C'est le comportement normal de Redis.
      Redis n'est pas prévu pour être accessible sur un réseau non sécurisé.

      Ce que la mise à jour de Redis fait, c'est d'insulter violemment le sysadmin qui essaie de lancer redis sur 0.0.0.0/:: (et refuse de se lancer)
      Je suis sûr que y aura quand même des gens pour listen sur l'ip de leur connexion internet et donc faire la même chose.

      • [^] # Re: Faille trouvée : Redis

        Posté par  . Évalué à 2. Dernière modification le 02 septembre 2016 à 14:57.

        On peut aussi utiliser Redis sans vraiment savoir se que c'est.
        Exemple : installer owncloud (il y a une alerte en rouge dans le panneau admin tant qu'on a pas installé redis)

        Curiosité : par défaut ça écoute sur 0.0.0.0 ou 127.0.0.1?

        Redis n'est pas prévu pour être accessible sur un réseau non sécurisé.

        Les devs de Redis ont alors ont une vision très retro de la sécurité ^ ^ (ça fait au moins dix ans qu'on conseil de coder en partant du principe qu'au moins une machine du réseau est compromise)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Faille trouvée : Redis

          Posté par  . Évalué à 2.

          Curiosité : par défaut ça écoute sur 0.0.0.0 ou 127.0.0.1?

          je réponds à ma propre question :

          └─ $ ▶ sudo cat  /etc/redis/redis.conf  | grep "bind" | grep  -v "#"
bind 127.0.0.1

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Faille trouvée : Redis

          Posté par  . Évalué à 6.

          Les devs de Redis ont alors ont une vision très retro de la sécurité ^ ^ (ça fait au moins dix ans qu'on conseil de coder en partant du principe qu'au moins une machine du réseau est compromise)

          Ça ne me choque pas outre mesure qu'un logiciel qui fait juste un stockage clé/valeur ne se pose pas de question de sécurité. Ça écoute sur un port quelconque, c'est le système autour qui doit faire en sorte que seules les personnes autorisées peuvent taper sur le port d'écoute de redis.

          On trouve exactement le même comportement avec elasticsearch. Ça oblige à mettre une surcouche pour faire l'authentification, mais au moins, ça laisse le choix de comment faire la sécurité (authentification basique, certificats, tunnel SSH… autant de choix qu'il serait difficile de maintenir dans chaque logiciel).

          • [^] # Re: Faille trouvée : Redis

            Posté par  (site web personnel) . Évalué à 5.

            On trouve exactement le même comportement avec elasticsearch.

            Plus depuis la version 2.

            La V2 n'écoute que depuis 127.0.0.1 donc n'est accessible que localement. Si tu veux écouter sur une autre IP tu dois le dire explicitement et donc aussi t'assurer que tu n'exposes pas ta machine.

            Idéalement on met Elasticsearch dans le backend comme n'importe quelle base.

            Developer | Evangelist at elastic

          • [^] # Re: Faille trouvée : Redis

            Posté par  . Évalué à 2. Dernière modification le 04 septembre 2016 à 18:53.

            @Guillaume Rossignol

            Ça ne me choque pas outre mesure qu'un logiciel qui fait juste un stockage clé/valeur ne se pose pas de question de sécurité.

            Les devs de redis sont en désaccord avec toi vu que par défaut ils ont limité sur 127.0.0.1 (voir mon message juste ci-haut). Et heureusement si non bonjour la faille exploitable par n'importe quel script kiddies.
            Ce fonctionnement n'empêche pas d'utiliser sa propre "surcouche" par dessus.

            Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # Question ...

    Posté par  . Évalué à 6.

    C'est quoi un ransonware loyal ? Ca existe ?

    • [^] # Re: Question ...

      Posté par  (site web personnel) . Évalué à 10.

      J'imagine qu'ici loyal voudrait dire « il te rend tes données en échange de ta thune », un peu comme le principe du « la bourse ou la vie » où on te laisse repartir si tu paies. Prendre l'argent sans contrepartie, c'est « déloyal » (en plus d'être illégal, pas sympatoche, non-altruiste, malveillant et bassement vénal).

      • [^] # Re: Question ...

        Posté par  . Évalué à 9.

        Ils tuent un peu le business du ransomware, de la même manière qu'un « la bourse ou la vie » tue le business s'il prend les deux.
        C'est important de fidéliser la clientèle, et que le bouche à oreille marche en ta faveur.

        • [^] # Re: Question ...

          Posté par  . Évalué à 5.

          Oui d'où l’intérêt pour certains services de prendre les sous et ne pas rendre les données (on peut imaginer pareil avec des otages, mais c'est plus limite coté éthique); et bien médiatiser le tout. Lorsque les gens seront persuadés à 99% de ne pas pouvoir récupérer leur données le business s'écroulera tout seul.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Question ...

            Posté par  . Évalué à 10.

            Je verrais bien un ransomware qui dirait « vos données vous seront restituées lorsque vous aurez mis en place un système de backup et sauvegarde solide ».

            • [^] # Re: Question ...

              Posté par  . Évalué à 5.

              Et forcément le mec il laisse ses coordonnées pour qu'on le contacte afin de lui prouver qu'on a bien mis en place un tel système et là… c'est le drame :-)

              Julien_c'est_bien (y'a pas que Seb)

            • [^] # Re: Question ...

              Posté par  . Évalué à 3.

              Un ransomware éducatif ? Un peu comme EduCrypt ?

    • [^] # Re: Question ...

      Posté par  . Évalué à 4.

      Dans le journal :

      La chose s'appelle Fairware… ce qui est particulièrement cocasse pour un truc aussi peu "fair" que possible.

      Du coup, j'ai lu ça comme un clin d'oeil au nom du malware en question (fair -> juste/équitable/loyal)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.