Dans une note publiée le 11 avril 2019, les développeurs de Matrix ont annoncé avoir découvert et heureusement corrigé une faille de sécurité. Précisons que Matrix est un standard ouvert pour la communication interopérable, décentralisée et en temps réel sur IP. Il peut être utilisé dans la construction d'une messagerie instantanée, la signalisation VoIP/WebRTC et la communication IdO (Internet des objets).Pour revenir à l'alerte de sécurité, « un attaquant a eu accès aux serveurs hébergeant Matrix.org. L'intrus a eu accès aux bases de données de production, ce qui lui a donné potentiellement accès à des données de message non chiffrées, à des hashs de mots de passe et à des jetons d'accès. Par précaution, si vous êtes un utilisateur de matrix.org, vous devez changer votre mot de passe maintenant », lit-on dans l'avis de sécurité.
Il est important de souligner que la faille de sécurité n'est pas un problème propre à Matrix. Le hacker a plutôt, selon l'avis de sécurité, exploité une vulnérabilité de l'infrastructure de production, plus précisément, « une version légèrement obsolète de Jenkins ». Les développeurs de Matrix utilisent Jenkins comme solution d'intégration continue pour le test automatique de leur logiciel. La version obsolète de Jenkins qu'ils utilisaient a une vulnérabilité qui permet à un attaquant de détourner des informations d'identification (clés ssh), et avoir donc accès à leur infrastructure de production.
Le rapport indique qu'ils n'ont « trouvé aucune preuve de grandes quantités de données téléchargées » par le hacker. L'attaquant aurait seulement eu accès à la base de données de production. Donc, seul « le contenu non chiffré (y compris les messages privés, les hashs de mots de passe et les jetons d'accès) pourrait être compromis », indiquent l'équipe Matrix. Pour le reste (code source, packages, etc.), rien ne semble avoir été compromis. Une situation qui laisse croire que « la cible [de l'attaquant] serait des informations d'identification internes en vue de les exploiter plus tard, et non des informations sur l'utilisateur final provenant du homeserver matrix.org. »
Précisons que, selon l'avis de sécurité, l'attaquant a compromis le serveur Jenkins CI un mois plus tôt (le 13 mars) et a eu accès à l'infrastructure de production le 4 avril. Mais le 9 avril, la vulnérabilité de Jenkins a été portée à l'attention de l'équipe Matrix par un hacker éthique, ce qui leur a permis de constater le lendemain que des machines avaient été comprises et d'évaluer l'ampleur de l'attaque.
Ce piratage a contraint les développeurs à mettre hors ligne, pendant plusieurs heures, les serveurs hébergeant Matrix.org et Riot.im (un logiciel de messagerie open source basé sur le protocole de communication Matrix). Malheureusement, cette opération a entrainé, pour certains utilisateurs, la perte d'accès à leurs messages chiffrés.
« Comme nous avons dû déconnecter tous les utilisateurs de matrix.org, si vous ne disposez pas de sauvegardes de vos clés de chiffrement, vous ne pourrez pas lire l'historique de vos conversations chiffrées », expliquent les développeurs de Matrix. « Cependant, si vous utilisez une sauvegarde de clés de chiffrement côté serveur (l'option par défaut dans Riot de nos jours) ou si vous effectuez des sauvegardes manuelles de clés, tout ira bien », assurent-ils.
« C'était un choix difficile à faire. Nous avons comparé le risque, pour certains utilisateurs, de perdre l'accès à leurs messages chiffrés au risque que tous les comptes d'utilisateurs soient vulnérables via les jetons d'accès compromis. Nous espérons que vous comprendrez pourquoi nous avons pris la décision de donner la priorité à l'intégrité des comptes plutôt qu'à l'accès aux messages chiffrés, mais nous sommes désolés pour le désagrément que cela a pu causer », ont-ils ajouté.
Telle est la communication qu'ont faite les développeurs de Matrix, avec ce qui pouvait s'apparenter à un sentiment d'avoir accompli leur devoir de protéger au mieux les utilisateurs après une violation de sécurité ; un piratage qui aurait pu avoir des conséquences bien pires, quand on voit les possibilités qui s'offraient au hacker. Mais une sortie de l'attaquant montre, au contraire, qu'il n'y a pas de quoi être fier du travail abattu par les développeurs de Matrix pour contenir l'attaque et sécuriser leur infrastructure. En effet, en ce qui concerne leurs pratiques de sécurité, le fait qu'ils utilisaient une version obsolète de Jenkins n'était que la partie visible de l'iceberg.
Une attaque qui n'aurait pas pu être possible sans de mauvaises pratiques de sécurité
Le 12 avril, le hacker a ouvert une série de problèmes (issues) sur la page GitHub de Matrix pour détailler comment il a réussi à pirater l'infrastructure, sans oublier de proposer des mesures correctives, ou, devrais-je dire, leur donner quelques leçons de sécurité. « J'ai remarqué sur votre blog que vous parliez d'opérations post mortem et des mesures à prendre. En tant qu'une personne connaissant très bien toute votre infrastructure, je pensais pouvoir vous aider », dit-il.
Le hacker explique d'abord que l'attaque complète aurait pu être évitée si les développeurs étaient interdits d'utiliser ForwardAgent yes ou n'utilisaient pas -A dans leurs commandes SSH. Il semble surpris par cela étant donné que, comme il le dit, les failles avec l'agent forwarding sont bien documentées.
Il note ensuite une violation du célèbre principe de sécurité connu sous le nom de « principe du moindre privilège » : une tâche ne doit bénéficier que de privilèges strictement nécessaires à son exécution. « L'escalade aurait pu être évitée si les développeurs n'avaient que l'accès dont ils avaient absolument besoin et ne disposaient pas d'un accès root à tous les serveurs », écrit le hacker.
Dans sa série de messages postés sur GitHub, l'attaquant explique encore qu'il a pu se connecter à tous les serveurs via une adresse Internet. « Il ne devrait y avoir aucune bonne raison d’exposer vos ports de gestion à l’ensemble de l’Internet. Envisagez de limiter l'accès à la production à un hôte VPN », suggère-t-il. Dans un autre issue, il livre un autre épisode de son opération, épisode dans lequel il explique que Git n'est pas un endroit pour stocker des données sensibles : « Le référentiel internal-config contenait des données sensibles et tout le référentiel était souvent cloné sur des hôtes et y était laissé pendant de longues périodes, même si la plupart des configurations n'étaient pas utilisées sur cet hôte. Les hôtes ne doivent avoir que la configuration nécessaire pour fonctionner, et rien d'autre », dit-il dans une énième leçon de sécurité.
Il évoque encore bien d'autres mauvaises pratiques de sécurité. Il explique par exemple que le piratage aurait pu être détecté par une meilleure surveillance des fichiers log et des alertes sur les comportements anormaux. Après tout, « le compromis a commencé il y a plus d'un mois », dit-il. Il explique aussi qu'alors qu'il était à la recherche de moyens d'obtenir un niveau d'accès plus élevé et d'explorer davantage le réseau de Matrix, il est tombé sur des clés GPG que les développeurs utilisaient pour signer leurs paquets Debian. « Cela m'a donné beaucoup d'idées néfastes », dit-il. Avant de donner un conseil : « Je vous recommande de ne conserver aucune clé de signature sur les hôtes de production, mais de vous connecter dans un environnement sécurisé. »
Bref, pour des professionnels qui développent un protocole de communication qui a une très bonne réputation en matière de sécurité, c'est un peu paradoxal de voir une telle négligence. Rappelons que le projet Matrix a déjà retenu l'attention de certains Etats, y compris la France. C'est en effet Matrix et Riot que la DINSIC a choisi pour mettre les hauts fonctionnaires et élus français à l'abri à la surveillance d'un pays étranger, estimant que les messageries chiffrées populaires telles que WhatsApp et Telegram sont de moins en moins crédibles. Ce piratage peut donc porter un petit coup à la réputation de Matrix. Sur GitHub, les développeurs du protocole ont dû modérer les messages des internautes qui avaient tendance à témoigner leur respect au hacker alors qu'il expliquait son exploit. GitHub est également intervenu pour retirer toutes les discussions (issues) ouvertes par le hacker. Mais les liens sont disponibles via Wayback Machine.
Sources : Blog Matrix, GitHub (via Wayback Machine)
Et vous ?
Que pensez-vous des pratiques de sécurité des développeurs de Matrix ? Considérez-vous cela comme quelque chose qui peut arriver à tout le monde ou un laxisme total ? 
