Ne laissez pas votre serveur SQL vous attaquer avec un ransomware !

Ils peuvent procéder à du piratage plutôt direct et agressif en utilisant des vulnérabilités et des exploits pour contourner les contrôles de sécurité déjà en place et inciter vos serveurs à exécuter des logiciels qu’ils ne sont pas censés exécuter.

Ou bien, ils peuvent trouver comment entrer sans passer par du bricolage bas de gamme, en utilisant tout simplement des points d’entrée et des commandes système officiels.

C’est un peu comme prendre un taxi pour aller braquer une banque au lieu d’utiliser une voiture volée : c’est une technique plutôt surprenante pour un gangster, mais au moins votre plaque d’immatriculation passera totalement incognito durant votre déplacement.

Comme nos lecteurs réguliers le savent, l’un des véhicules les plus populaires utilisé par les cybercriminels diffusant des malwares à l’heure actuelle est Windows RDP, abréviation de Remote Desktop Protocol.

Malheureusement, nous avons souvent écrit ces dernières années sur les failles de sécurité RDP qui permettent à des attaquants d’entrer dans votre réseau comme s’ils étaient de véritables administrateurs système …

… sauf qu’au lieu de réparer, ils détruisent, puis demandent de l’argent pour réparer les dégâts causés (comme par exemple lors de l’utilisation de ransomwares).

Mais Windows RDP n’est pas le seul moyen populaire utilisé par les cybercriminels pour lancer des cyberattaques.

Nous avons récemment publié l’étude honeypot portant sur les attaques SSH, où SSH signifie Secure Shell, un système d’accès distant encore plus largement utilisé sous Linux et Unix que RDP sous Windows.

NB : SSH est également populaire sur les serveurs Windows, mais n’a pas été adopté à quasi-100% comme c’est le cas sur ses cousins ​​Unixy.

Notre étude a permis de brosser un tableau clair de la quantité d’énergie que les cybercriminels sont prêts à dépenser pour pénétrer dans votre réseau en utilisant des méthodes imparables.

Le fait d’utiliser des outils légitimes pour pénétrer de manière illégale ouvre non seulement la porte de la cybercriminalité à un ensemble beaucoup plus large d’acteurs malveillants, mais évite également la détection des exploits ou de provoquer une panne au niveau du serveur.

Malheureusement, les cybercriminels ne veulent pas se contenter d’utiliser SSH et RDP comme seuls outils d’attaque polyvalents.

Il existe de nombreux autres services en ligne, y compris certains services dont vous ne soupçonnez pas l’existence, qui sont aussi efficaces qu’une invite de commande, si seulement vous parvenez à vous y connecter au départ.

Par exemple, un serveur MySQL non sécurisé n’est pas seulement la porte d’entrée idéale pour commettre une violation de données.

C’est également une alternative très efficace, bien que peu orthodoxe, à RDP ou SSH pour l’exécution de logiciels à distance.

Voici un exemple fascinant capturé récemment par un honeypot des SophosLabs qui scrutait le port TCP 3306, le port d’accès par défaut de MySQL.

Le serveur ‘proto’ prétendait être une instance non sécurisée de MySQL à laquelle les pirates pouvaient avoir accès, se connecter et qui pouvait être analysée.

Les honeypots attirent délibérément les hackers afin de garder une trace des techniques d’attaque actuellement utilisées par ces derniers, dans une certaine limite bien sûr, car le honeypot ne doit pas permettre aux attaquants de causer un préjudice réel.

NB : Les opérateurs de honeypots doivent faire attention à bien faire partie de la solution et non pas du problème. Par exemple, si vous essayez d’attirer les spammeurs avec ce qui ressemble à un ordinateur zombie prêt à envoyer des emails indésirables, vous devez aller assez loin dans la démarche pour permettre aux cybercriminels de construire les messages qu’ils souhaitent envoyer, ajouter les pièces jointes qu’ils souhaitent distribuer et révéler le nombre de personnes qu’ils souhaitent atteindre. Mais vous ne devez laisser aucun de ces messages douteux partir véritablement, sinon vous offrez à ces pirates un service de spam gratuit.  

Dans l’attaque SQL capturée par les SophosLabs, les hackers ont tenté de transformer le honeypot du serveur MySQL en un robot d’exécution de code à distance, en utilisant une séquence comme celle-ci :

1. Connexion au serveur.
2. Récupération des identifiants d’un utilisateur autorisé, en les devinant, et connexion avec ces derniers.
3. Création d’une table de base de données à l’allure inoffensive et ajout d’un enregistrement de type texte qui est en fait un fichier exécutable Windows au format hexadécimal.
4. Décodage des données hexadécimales et enregistrement de ces dernières dans un fichier local appelé cna12.dll (un fichier DLL est un programme spécifique sous Windows conçu pour être chargé par une application déjà en cours d’exécution afin d’ajouter des fonctionnalités supplémentaires).
5. Demande faite au serveur pour charger le nouveau fichier DLL local en tant que plugin MySQL appelé UDF (User Defined Function).
6. Appel d’une fonction dans le nouveau plugin pour récupérer et exécuter des malwares à l’aide de HTTP.

Autrement dit, les cybercriminels ont utilisé MySQL comme un zombie d’exécution de code à distance généraliste, grâce au système de plugin UDF officiel de MySQL qui permet d’intégrer des fonctionnalités supplémentaires dans le serveur au moment de l’exécution.

L’attaque n’était pas particulièrement sophistiquée car les hackers n’avaient pas remarqué que le honeypot exécutait Linux et avaient chargé du code exécutable spécifique à la version Windows de MySQL.

Néanmoins, si le serveur avait utilisé Windows, le téléchargement HTTP indiqué à l’étape 6 ci-dessus…

… aurait déclenché un ransomware connu sous le nom de GandCrab.

Pour une description détaillée des techniques utilisées dans cette attaque, et pour obtenir les IoC (indicateurs de compromission) à utiliser pour effectuer des recherches et des test au niveau de vos propres serveurs, veuillez consulter l’analyse technique sur notre site Sophos.

Quoi faire ?

Avec toute la sagesse issue de notre expérience, vous ne devriez pas être vulnérable vis-à-vis de ce type d’attaque.

L’épidémie massive du virus SQL Slammer en 2003 aurait dû nous apprendre à garder nos serveurs SQL isolés d’Internet, et le risque d’utilisation abusive de la fonctionnalité UDF de MySQL est bien documenté depuis un certain temps maintenant.

Cependant, le fait que nous continuons à capturer des tentatives automatisées et peu sophistiquées pour pénétrer dans des systèmes via des ports SQL Internet, nous rappelle que nous commettons encore de vieilles erreurs.

Voici donc les mesures à prendre et les actions à mettre en place :

• Assurez-vous que vos serveurs SQL ne soient pas directement accessibles depuis Internet. S’ils le sont, il s’agit certainement d’une erreur. Si ce n’est pas une erreur, c’est une très mauvaise idée, et vous devriez trouver rapidement un autre moyen d’y accéder à distance. Pensez plutôt à utiliser un VPN ou SSH comme point d’entrée initial et insistez sur l’utilisation du 2FA au niveau de tous vos utilisateurs.
• Choisissez des mots de passe appropriés. L’attaque décrite ici ne peut pas être déclenchée par un utilisateur non authentifié. Ne prenez donc pas de risques avec des mots de passe faibles. Même si votre serveur SQL est uniquement accessible en interne, vous ne voulez certainement pas que n’importe qui puisse s’y connecter facilement, surtout en tant qu’utilisateur privilégié.
• Vérifiez vos paramètres de contrôle d’accès MySQL. Seuls les utilisateurs disposant de droits de type INSERT au niveau de la base de données principale mysql peuvent charger de nouveaux fichiers UDF. Ainsi, toute personne pouvant monter cette attaque dispose déjà de suffisamment de pouvoir pour mener de nombreuses actions malveillantes (ce serait bien de pouvoir désactiver les UDF si vous ne les utilisez pas, mais nous n’avons pas trouvé une telle option. Le seul moyen que nous avons trouvé pour empêcher le chargement des UDF est de construire votre propre version statique de mysqld à partir du code source).
• Envisagez des tests de pénétration. Vous connaissez probablement toutes les stratégies de défense énumérées ci-dessus et essayez de les suivre, mais il est utile de vérifier que vous les avez mises en œuvre correctement. Des erreurs se produisent et si vous n’y prêtez pas attention régulièrement, quelqu’un d’autre le fera certainement pour vous.

Billet inspiré de Serious Security: Don’t let your SQL server attack you with ransomware, sur Sophos nakedsecurity.