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

Les logiciels libres (OSS) ont rapidement transformé la façon 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, bon nombre des outils qui ont permis la croissance de DevOps et de CI/CD, tels que Jenkins, Kubernetes et Docker, sont eux-mêmes des projets open source.

En 2019, le nombre global de CVEs 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 CVE à 968 CVE) et ont été 127 % plus élevées qu'en 2017 (435), qui comptait le deuxième plus grand nombre de CVE de 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, tant pour les développeurs que pour les équipes informatiques et de sécurité. Le serveur d'automatisation Jenkins a enregistré le plus grand nombre de CVE dans l'ensemble, avec 646, suivi de près par MySQL, avec 624. De même, ces projets sont à égalité pour le plus grand nombre de vulnérabilités armées avec 15 (vulnérabilités pour lesquelles il existe un code d'exploitation). Cet article examine les raisons de ces vulnérabilités logicielles et montre comment protéger les bases de données MySQL contre les incidents de sécurité potentiels.

Contenu :

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

2. Vulnérabilités dans MySQL 

3. Les dangers des serveurs de bases 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 sa place 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 dans les opérations internes de backend que dans les applications destinées au public, telles que les sites Web et les portails clients. Bien qu'il s'agisse d'une base de données open-source, MySQL a été racheté par Sun Microsystems qui a ensuite été racheté par Oracle. Introduite dans les années 1990, elle est rapidement devenue une option populaire à la base de données Microsoft SQL Server, qui dominait à l'époque. 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.

Actuellement, MySQL est 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 les infrastructures présentent de nombreux avantages, notamment une communauté qui contribue aux mises à jour, à la recherche de bogues et aux 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 bifurqué 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. Le résultat peut être l'exploitation du logiciel et une vulnérabilité de type "jour zéro" inconnue du développeur jusqu'à ce que l'exploitation ou la vulnérabilité du code soit trouvée. L'identification d'une vulnérabilité en cours d'exploitation peut prendre des années. Il est donc d'autant plus important pour les entreprises de corriger le logiciel MySQL dès qu'une mise à jour est publiée. Ces mises à jour protègent les systèmes de 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 à la disposition du public et que son code est open-source, le logiciel de base de données présente de nombreuses CVEs (Vulnérabilités et expositions communes) - 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 de 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 aussi récentes que 2020 permettent une élévation de privilèges, un accès réseau pour compromettre le client MySQL et l'exécution de code à distance (RCE).

La compromission d'une base de données est un événement critique pour la sécurité, car plusieurs autres problèmes peuvent découler de l'autorisation donnée aux attaquants d'y accéder. Selon l'exploit, les attaquants peuvent exfiltrer des données d'un serveur compromis, s'octroyer 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 ne code 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 attaquant peut exécuter ses propres logiciels malveillants sur le serveur, qu'il s'agisse de keyloggers ou de ransomwares.

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

A titre d'exemple, regardez CVE-2020-2934. Il existe plusieurs autres CVE liées à cette vulnérabilité, qui affectent toutes 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 les modifier.

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é, la confiance, les revenus et la productivité des clients. La plupart des organisations ne disposent pas d'une équipe interne de réponse aux incidents, ce qui oblige à faire appel à des consultants extérieurs 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 mesure corrective 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 chiffrer 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écessitent l'aide de consultants externes. Tant que la base de données reste hors service, 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é 100 millions de dollars chacun après avoir enfreint les règles de conformité au GDPR (General Data Protection Regulation), suite à des 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 de 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.

Étant donné que MySQL est un composant critique de l'infrastructure, les administrateurs et les administrateurs de bases de données (DBA) peuvent souvent programmer les correctifs pour une date ultérieure. Ils peuvent également attendre plusieurs semaines avant d'appliquer les correctifs afin de pouvoir effectuer des tests approfondis et d'éviter les temps d'arrêt sur 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 serveur MySQL non patché.

Avec plus de 1 300 CVE, les administrateurs et les administrateurs de bases de données peuvent avoir l'impression que la mise en place de correctifs sur le serveur est une bataille perdue d'avance. Tout temps d'arrêt d'un serveur de production est synonyme de perte de productivité et de ventes, et il est généralement difficile de le planifier, car les administrateurs ne peuvent pas interrompre les services pendant les heures de travail.

Conclusion

Pour maintenir les serveurs à l'abri des dernières vulnérabilités, la solution consiste à utiliser des correctifs en temps réel afin que le serveur reçoive des mises à jour en continu sans qu'il soit nécessaire de le redémarrer. KernelCare+ lancera bientôt une nouvelle fonctionnalité qui permettra aux administrateurs de mettre à jour leurs serveurs de bases de données sans avoir à les redémarrer. Grâce à KernelCare+, les administrateurs peuvent éviter des violations de données coûteuses et des temps d'arrêt, tout en protégeant les données critiques.