{"id":545,"date":"2023-12-25T20:27:15","date_gmt":"2023-12-25T19:27:15","guid":{"rendered":"https:\/\/www.slash-mnt.com\/?p=545"},"modified":"2024-02-02T16:36:00","modified_gmt":"2024-02-02T15:36:00","slug":"le-jour-ou-nous-avons-subi-une-tentative-de-cryptomining","status":"publish","type":"post","link":"https:\/\/www.slash-mnt.com\/fr\/2023\/le-jour-ou-nous-avons-subi-une-tentative-de-cryptomining\/","title":{"rendered":"Le jour o\u00f9 nous avons endigu\u00e9 une tentative de CryptoMining"},"content":{"rendered":"\n

La fin d’ann\u00e9e 2023 a \u00e9t\u00e9 marqu\u00e9e pour un de nos clients par une petite frayeur. Spoiler alert : tout a \u00e9t\u00e9 ma\u00eetris\u00e9, aucune donn\u00e9e leak\u00e9e, z\u00e9ro impact<\/strong> donc.<\/p>\n\n\n\n

Pour reproduire une suspicion de souci de performance sur le produit phare de ce client, il a \u00e9t\u00e9 jug\u00e9 n\u00e9cessaire de positionner une instance de debug de l’application sur l’environnement de production. Il s’agissait du seul environnement pouvant ressembler \u00e0 100% du cas de l’utilisateur final observant des bugs emp\u00eachant un travail op\u00e9rationnel convenable.<\/p>\n\n\n\n

L’application en question est d\u00e9velopp\u00e9e en Java qui, gr\u00e2ce au JRE ou JDK, permet le Remote Debug \u00e0 condition d’ouvrir un port. Cette instance n\u00e9cessitait donc d’une configuration sp\u00e9cifique pour permettre \u00e0 l’\u00e9quipe d\u00e9veloppement, en utilisant le Remote Debug, d’attacher des sondes pour comprendre au mieux l’activit\u00e9 de l’utilisateur final et surtout pouvoir ressortir des donn\u00e9es amenant \u00e0 l’analyse des bugs.<\/p>\n\n\n\n

Evidemment, ouverture de port, sur une production qui plus est, devient synonyme de risques et de cr\u00e9ation de surfaces d’attaques.<\/p>\n\n\n\n

Pour y rem\u00e9dier, avant l’ouverture de ce port, des nouvelles r\u00e8gles ufw<\/code> sont ajout\u00e9s pour n’autoriser ce port qu’en provenance d’une source s\u00fbre. Apr\u00e8s l’ajout des ces r\u00e8gles, un petit red\u00e9marrage d’ufw et l’\u00e9quipe de d\u00e9veloppement peut se mettre au travail.<\/p>\n\n\n\n

Environ 24h plus tard, surprise, nous recevons une alerte de CrowdStrike Falcon (l’anti-virus \/ analyseur de packets) nous notifiant le blocage d’un acc\u00e8s et d’une tentative d’installation d’un soft de CryptoMining. L’attaquant \u00e9tait pass\u00e9 par le Remote Debugger ouvert un peu plus t\u00f4t.<\/p>\n\n\n\n

D\u00e9j\u00e0, bonne nouvelle, CrowdStrike Falcon a su couper court aux intentions de notre ami attaquant.<\/p>\n\n\n\n

A partir de l\u00e0, il nous reste \u00e0 nous assurer que la porte permettant ce genre d’attaque soit d\u00e9finitivement close. Peu de scrupule \u00e0 ce niveau car il s’agit ici d’une instance de debug : arr\u00eat clair et net de cette derni\u00e8re.<\/p>\n\n\n\n

Apr\u00e8s (re)v\u00e9rification, ufw \u00e9tait bien configur\u00e9 pour ne laisser passer que les personnes autoris\u00e9es. Et pourtant…<\/p>\n\n\n\n

Petit rappel, certains OS utilisent ufw<\/code> comme logiciel de pare-feu par d\u00e9faut : Ubuntu depuis sa version 8.04 LTS, Debian, etc. Dans tous les cas, il s’agit d’un pare-feu utilis\u00e9 par un large panel de personnes dans le monde.<\/p>\n\n\n\n

Pour comprendre ce qu’il s’est pass\u00e9, nous commen\u00e7ons \u00e0 remettre tout simplement en question ufw :<\/p>\n\n\n\n

    \n
  1. Comment fonctionne t’il ? <\/strong><\/li>\n\n\n\n
  2. Est-il surcharg\u00e9 par quelque chose ?<\/strong><\/li>\n\n\n\n
  3. Qu’a t’on r\u00e9ellement fait lorsqu’on a cr\u00e9\u00e9 l’instance de debug ?<\/strong><\/li>\n<\/ol>\n\n\n\n

    Pour r\u00e9pondre \u00e0 la premi\u00e8re question, il suffit de se rendre sur sa documentation : UncomplicatedFirewall – Ubuntu Wiki<\/a>. On peut y lire qu’il r\u00e9dige une suite de r\u00e8gles iptables. Rien de surprenant jusque l\u00e0.<\/p>\n\n\n\n

    \n

    The Linux kernel in Ubuntu provides a packet filtering system called\u00a0netfilter, and the traditional interface for manipulating\u00a0netfilter\u00a0are the\u00a0iptables\u00a0suite of commands.<\/mark><\/p>\nUncomplicatedFirewall – Ubuntu Wiki<\/a><\/cite><\/blockquote>\n\n\n\n

    Seconde question, au d\u00e9but pas vraiment de r\u00e9ponse. On voit bien les r\u00e8gles iptables<\/code> qui sont pr\u00e9sentes. Par contre, ce qui est constat\u00e9 c’est une autre r\u00e8gle montre que le port en question est redirig\u00e9 vers une interface Docker.<\/p>\n\n\n\n

    Pour la derni\u00e8re question, vu le constat pr\u00e9c\u00e9dent, nous pouvons imaginer facilement que Docker \/ Docker Swarm est en conflit avec ufw. Pour ajouter du contexte, l’instance de debug \u00e9tait lanc\u00e9e avec un service Docker Swarm en publiant le port du Remote Debug.<\/p>\n\n\n\n

    Ce qui se passe donc, est que Docker \u00e9crit ses r\u00e8gles iptables avant ufw<\/code>. En lisant de haut en bas les r\u00e8gles, la r\u00e8gle Docker arrive en premier, donc dans le cycle de vie du paquet, il n’arrive jamais jusqu’\u00e0 la validation ufw : Docker bypass ufw dans ces conditions.<\/p>\n\n\n\n

    Maintenant que le probl\u00e8me et la cause se sont pr\u00e9sent\u00e9s, il n’est pas difficile de retrouver des ressources sur le web relatant de cela. La plupart d’ailleurs conseille de d\u00e9sactiver la gestion d’iptables par Docker. Cela semble int\u00e9ressant au premier abord, par contre nous comprenons vite que les fonctionnalit\u00e9s propres \u00e0 Docker en terme de networking sont donc inutilisables. Il existe mille raisons de ne pas s’arr\u00eater \u00e0 cette solution : r\u00e9seau de containers, l’acc\u00e8s au r\u00e9seau externe, etc.<\/p>\n\n\n\n

    Une solution difficile \u00e0 maintenir mais qui permet de conserver toutes les features de Docker et d’ufw<\/code> peut se trouver sur ce repository (chaifeng\/ufw-docker – Solving UFW and Docker issues)<\/a>. Ce ne sera pas la solution la plus \u00e9l\u00e9gante mais fait preuve, je trouve, d’efficacit\u00e9.<\/p>\n\n\n\n

    Le\u00e7on apprise sur plusieurs plan :<\/p>\n\n\n\n