Putaclic – Cyberattaque – SQL Server et la backdoor Maggie

Je donne très rarement dans le sensationnel mais j’avoue que les titres des quelques agrégateurs de News que je regarde me laissent pantois ce matin. On voit des articles relatant des certains d’instances SQL Server infectées par une porte dérobée, nommée Maggie. Ou bien que le malware Maggie s’attaque aux serveurs SQL de Microsoft.

Bon, il est temps de remettre les choses dans leur contexte.

Une équipe de chercheurs a bel et bien découvert quelque chose, de réel, soyons clair, et ne minimisons surtout pas l’impact que cela peut avoir sur votre système d’information. Donc oui, ce n’est pas à prendre à la légère.

Mais j’aurais tendance à dire que l’on est quand même dans la lignée des articles putaclic.

Remettons les choses dans leur contexte …

Ce malware ne s’immisce pas dans SQL server. C’est quelqu’un qui l’a volontairement ajouté ! Depuis que je travaille sur SQL Server, ¼ de siècle pour faire simple, SQL Server a toujours proposé une option pour ajouter du code « Externe », sous forme de DLL. Donc un gentil développeur créé du code, vous donne une DLL signée, et vous en tant que DBA vous allez l’ajouter dans SQL Server. Ensuite, ce code pourra tout simplement être appelé au travers de procédure stockées étendues.

Et depuis 25 ans, j’alerte sur les problèmes que cela peut engendrer niveau sécurité et déconseille fortement ce genre de choses. Soyons claire encore une fois. Il y a bien un risque, mais c’est quand même vous qui l’avez ajouté. Et puis un nom de DLL aussi bien choisi, « sqlmaggieAntiVirus_64.dll » on se dit, ben oui, je vais l’ajouter, y’a pas de risque …

Bon, vous allez me dire mais ce n’est pas nous qui l’avons ajouté. Ah, oui, je ne peux pas tout le temps prouver qu’effectivement ce n’est pas vous. Mais si je ne peux pas le prouver c’est encore votre faute car vous utilisez toujours SA pour effectuer vos tâches d’administration !!! Alors qu’un groupe de sécurité Windows, avec un login spécifique par administrateur, ce n’est pas très compliqué … Oui, mais quand on est sysadmin, on prend l’identité de l’utilisateur dbo dans les bases de données. Hey, les nouveautés de SQL Server datant d’une dizaine d’années, ça vous parle ? Utilisez la permission Control Server en lieu et place du rôle sysadmin et vous ne perdrez pas votre identité.

Heuu, et encore, une dernière chose, si ce n’est pas vous qui l’avez ajouté, dans ce cas, vous étiez déjà attaqué … puisqu’un Hacker était sysadmin de votre instance …. Premier réflexe de ces derniers : utiliser vos serveurs liés ! En effet, dès que l’on possède le droit de se connecter à SQL Server, on dispose de la permission d’utiliser les serveurs liés, que vous avez peut-être configurer pour utiliser le compte SA sur le serveur distant. Ben ouaip, c’est tellement lourd à gérer la sécurité SQL Server. Pas envie de s’embêter, donc allez, on y va avec SA !

Et puis, ajouter un fichier … Il faut aussi avoir accès au niveau OS … On peut aussi tourner le regarde vers les autorisations données pour faire du RDP, pour les accès disque et réseau … Sans compter avec le compte de service de SQL Server qui doit respecter les principes de moindre privilège …. Et que dire des Firewall qui sont désactivés sur les OS ….

Et donc c’est SQL server qui a une faille de sécurité et qui subit une attaque d’un malware. Désolé, mais le problème est clairement entre la chaise et le clavier. Alors, oui il est probable qu’il existe des failles de sécurité dans SQL Server, comme dans tout logiciel, mais clairement, les statistiques montrent que sur les 10 dernières années, voire plus, très très peu de failles ont été découvertes sur SQL Server, contrairement à certains concurrents … Je dis ça, je ne dis rien !

Bon, je crois que ce petit coup de gueule est terminé.

En conclusion : si vous ne savez pas gérer vos SQL, laisser faire ceux qui savent. La sécurité fait aussi partie des tâches qui incombent au DBA.