Renforcer la sécurité des bases de données MySQL tout en éliminant les temps d'arrêt

Les logiciels libres ont rapidement transformé la manière dont les applications modernes sont construites et leur code sous-jacent. L'accès à des projets de logiciels libres robustes et de haute qualité a permis aux développeurs d'intégrer rapidement de nouvelles fonctionnalités dans leurs applications sans avoir à réinventer la roue. En conséquence, on estime aujourd'hui qu'entre 80 et 90 % du code de la plupart des applications modernes est constitué de composants open source. De même, de nombreux outils qui ont permis la croissance de DevOps et CI/CD, tels que Jenkins, Kubernetes et Docker, sont eux-mêmes des projets open-source.

En 2019, le nombre global de CVE open-source publiés (968) a plus que doublé par rapport à toutes les années précédentes. Les vulnérabilités ont augmenté de 130 % entre 2018 et 2019 (421 CVEs à 968 CVEs) et ont augmenté de 127 % par rapport à 2017 (435), qui avait le deuxième plus grand nombre de CVEs dans l'étude. Cette augmentation ne semble pas être un feu de paille, car la découverte de nouveaux CVE reste également à des niveaux historiquement élevés jusqu'aux trois premiers mois de 2020. Ce volume accroît la complexité de la gestion de la surface d'attaque d'une organisation pour les développeurs, les équipes informatiques et les équipes de sécurité. Le serveur d'automatisation Jenkins compte le plus grand nombre de CVE avec 646 et est suivi de près par MySQL avec 624. De même, ces projets sont à égalité en ce qui concerne le nombre de vulnérabilités exploitées avec 15 (vulnérabilités pour lesquelles il existe un code d'exploitation). Cet article étudie les raisons de ces vulnérabilités logicielles et montre comment protéger les bases de données MySQL contre d'éventuels incidents de sécurité.

Contenu :

1. Un bref aperçu de MySQL et de son importance sur le marché des bases de données relationnelles

2. Vulnérabilités dans MySQL 
3. Les dangers des serveurs de base de données non corrigés

4. Les logiciels de base de données vulnérables doivent être corrigés rapidement

5. Conclusion

Un bref aperçu de MySQL et de son importance sur le marché des bases de données relationnelles

Il existe plusieurs bases de données sur le marché, mais MySQL est l'une des plus utilisées, tant pour les opérations internes que pour les applications publiques telles que les sites web et les portails clients. Bien qu'il s'agisse d'une base de données à code source ouvert, MySQL a été acquis par Sun Microsystems, qui a ensuite été racheté par Oracle. Elle a été introduite pour la première fois dans les années 1990, mais est rapidement devenue une option populaire face à la base de données Microsoft SQL Server, qui était alors dominante. La syntaxe de MySQL est similaire à celle des autres langages SQL (Oracle et Microsoft, par exemple), ce qui en fait un choix pratique pour les développeurs et les organisations qui ont besoin d'une base de données plus abordable.

MySQL est actuellement l'un des systèmes de gestion de bases de données relationnelles (SGBD) les plus utilisés sur le marché. A 2019 étude a montré que MySQL représentait 38,9 % du marché, suivi de MongoDB avec 24,6 % et de PostgreSQL avec 17,4 %. Les logiciels de base de données open-source dominent une majorité de sites web, de systèmes backend et d'autres serveurs de stockage de données gérés par des entreprises.

Les logiciels libres qui font fonctionner l'infrastructure présentent de nombreux avantages, notamment une communauté qui contribue aux mises à jour, à la recherche de bogues et de fonctionnalités, des chercheurs en sécurité qui peuvent trouver des vulnérabilités avant que les pirates ne les trouvent et ne les exploitent, et un référentiel partagé qui peut être forké et personnalisé par d'autres développeurs. Ces avantages s'accompagnent toutefois d'un inconvénient. Si un attaquant trouve un bogue, il peut l'exploiter plutôt que de le signaler. Il peut en résulter une exploitation du logiciel et une vulnérabilité de type "zero-day" inconnue du développeur jusqu'à ce que l'exploitation ou la vulnérabilité du code soit découverte. L'identification d'une vulnérabilité en cours d'exploitation peut prendre des années, ce qui rend d'autant plus important pour les entreprises de corriger le logiciel MySQL dès qu'une mise à jour est publiée. Ces mises à jour corrigent les systèmes des vulnérabilités qui pourraient exister depuis des mois, voire des années. Si l'exploit affecte une base de données MySQL de production qui stocke des informations sensibles, il est impératif que l'organisation corrige le système dès que possible.

Vulnérabilités dans MySQL 

Depuis que MySQL est accessible au public et que son code source est ouvert, le logiciel de base de données présente de nombreuses CVE (Common Vulnerabilities and Exposures) - 1308 au total. Certaines de ces CVE sont liées à des applications ou des logiciels tels que les fichiers d'application PHP qui permettent l'injection SQL pour manipuler le contenu web et exécuter des scripts intersites persistants (XSS), mais d'autres ciblent le cœur du moteur de la base de données. Certaines vulnérabilités datant de 2020 permettent l'escalade des privilèges, l'accès au réseau pour compromettre le client MySQL et l'exécution de code à distance (RCE).

Une base de données compromise est un événement critique pour la sécurité, car plusieurs autres problèmes peuvent découler de l'accès des attaquants à cette base de données. En fonction de l'exploit, les attaquants peuvent exfiltrer des données d'un serveur compromis, se donner des privilèges administratifs sur le serveur ou injecter leurs propres données dans les tables. Dans le cas d'une attaque XSS persistante, toute application qui n'encode pas les données de la base de données peut être vulnérable au vol de données ou de cookies. Si un attaquant peut procéder à une élévation de privilèges sur le serveur, il peut manipuler des données, exfiltrer des données vers un serveur contrôlé par l'attaquant ou effectuer des déplacements latéraux dans les bases de données de l'entreprise. L'exécution de code à distance est particulièrement dangereuse, car un pirate peut exécuter ses propres logiciels malveillants sur le serveur, qu'il s'agisse d'enregistreurs de frappe ou de rançongiciels.

Les dangers des serveurs de base de données non corrigés

A titre d'exemple, on peut citer CVE-2020-2934. Il existe plusieurs autres CVEs liées à cette vulnérabilité, toutes affectant les connecteurs MySQL, les clients et les sessions réseau. L'exploitation réussie de cette vulnérabilité pourrait permettre à un attaquant d'exécuter des commandes CRUD (Create, Read, Update, or Delete) sur le serveur de base de données ou de lancer une attaque par déni de service (DoS). Un attaquant ayant la possibilité d'exécuter des commandes CRUD peut lire vos données ou y apporter des modifications.

Les violations de données sur une base de données sont considérées comme critiques et ont un impact durable sur la fidélité des clients, la confiance, le chiffre d'affaires et la productivité. La plupart des organisations ne disposent pas d'une équipe interne d'intervention en cas d'incident, ce qui oblige à faire appel à des consultants externes qui facturent des centaines de dollars de l'heure. Dans certains cas, les administrateurs informatiques choisissent d'éteindre les systèmes critiques pour contenir la brèche et bloquer l'accès des pirates au serveur de base de données. Cette solution temporaire empêche le pirate de voler davantage de données, mais elle interrompt également les applications qui ont besoin d'accéder à la base de données pour fonctionner.

Les violations graves où un attaquant utilise un ransomware pour crypter les données ou corrompre les fichiers nécessitent des sauvegardes et un plan de récupération des données. Même dans les grandes entreprises, les plans de récupération peuvent échouer et nécessiter l'aide de consultants externes. Tant que la base de données reste indisponible, l'organisation perd des revenus en raison des temps d'arrêt, qui peuvent représenter des milliers de dollars par heure dans les grandes entreprises.

Le coût d'une violation de données sur un serveur de base de données dépend fortement du type de compromission, de la quantité de données volées et de l'efficacité de la réponse à l'incident. À titre d'exemple, le prêteur canadien Mouvement Desjardins a dépensé 53 millions de dollars après une violation de données qui a révélé des informations personnelles sur 2,9 millions de ses membres. British Airways et Marriott ont dépensé chacun 100 millions de dollars après avoir enfreint les règles de conformité du GDPR (General Data Protection Regulation), à la suite de violations de données.

Les logiciels de base de données vulnérables doivent être corrigés rapidement

Un point commun à tous les CVE répertoriés dans la base de données MITRE pour MySQL est que toute application répertoriée avec des vulnérabilités doit être corrigée. Les CVE peuvent être des logiciels tiers qui permettent l'injection SQL et d'autres exploits ou vulnérabilités peuvent être trouvés dans le moteur de base de données MySQL lui-même. Vous pouvez ne pas utiliser l'application tierce, mais toute vulnérabilité de la base de données MySQL doit être corrigée dès que possible.

MySQL étant un composant critique de l'infrastructure, les administrateurs et les administrateurs de bases de données (DBA) peuvent souvent programmer les correctifs à une date ultérieure. Ils peuvent également attendre plusieurs semaines avant de patcher le système afin de pouvoir effectuer des tests approfondis et d'éviter l'indisponibilité d'un serveur de base de données de production. Chaque jour qui passe est une fenêtre d'opportunité pour un attaquant d'exploiter le logiciel du serveur MySQL non corrigé.

Avec plus de 1300 CVE et plus encore, les administrateurs et les administrateurs de bases de données peuvent avoir l'impression de perdre la bataille pour appliquer les correctifs sur le serveur. Tout temps d'arrêt d'un serveur de production se traduit par une perte de productivité et de chiffre d'affaires, et il est généralement difficile de le planifier, car les administrateurs ne peuvent pas interrompre les services pendant les heures d'ouverture.

Conclusion

Pour que les serveurs soient patchés et protégés contre les dernières vulnérabilités, la solution consiste à utiliser des correctifs en direct afin que le serveur reçoive des mises à jour en continu sans redémarrage. KernelCare+ lancera bientôt une nouvelle fonctionnalité qui permettra aux administrateurs de corriger leurs serveurs de base de données sans avoir à les redémarrer. Grâce à KernelCare+, les administrateurs peuvent éviter les violations de données coûteuses et les temps d'arrêt, tout en protégeant les données critiques.