Conséquences pour la sécurité de la restauration d'une sauvegarde à partir d'une source inconnue?

31

Scénario : vous recevez une sauvegarde de base de données et vous êtes invité à la restaurer sur un serveur (qui héberge déjà d'autres bases de données), mais vous ne recevez aucune information utile sur le contenu de la sauvegarde ou sur la fiabilité de la source.

Question 1 : Quelles sont les implications potentielles de la restauration d'une sauvegarde qui pourrait bien être malveillante?

Question 2 : Que pouvez-vous faire pour protéger votre serveur / les données d'autres bases de données de l'impact de la restauration d'une sauvegarde potentiellement malveillante? RESTORE VERIFYONLYsemble être une bonne première étape. La réponse ultime est probablement «restaurer la base de données dans une machine virtuelle sandbox sans accès au monde extérieur», mais supposons que cette option est hors de propos. Que faut-il faire d'autre dans cette situation?

sql-server backup security Simon Righarts
la source
1
Même en supposant que la restauration ne concerne que les données (pas de procédures stockées, ou quelques-unes), il peut y avoir beaucoup de malveillance. Supposons que la sauvegarde concerne une application Web contenant une table d'utilisateurs, avec leurs niveaux d'autorisation respectifs, une sauvegarde malveillante pourrait accorder l'accès aux utilisateurs qui ne devraient pas les avoir, et qui sait ce qu'ils pourraient en faire.
Lie Ryan
Très étrange, personne n'a mentionné le risque potentiel de procédures ou de fonctions CLR. (n'est plus désactivé par défaut)
ALZDBA

Réponses:

21

Une base de données peut contenir du code malveillant, éventuellement une procédure qui va changer un mot de passe pour la connexion "sa" ou supprimer chaque base de données. Cependant, la seule façon dont je peux voir que provoquer un problème est pour un individu de restaurer la base de données, puis d'exécuter manuellement tout code dans cette base de données. Il ne s'exécuterait pas de manière automatisée.

Aucun paramètre ne peut être appliqué dans une base de données pour que SQL Server exécute automatiquement un peu de code dans la base de données lors de sa restauration sur un serveur. Si c'était le cas, je m'attendrais à ce que Microsoft perde la certification Common Criteria pour le produit. C'est trop un bug pour m'avoir permis dans un SGBD.

Shawn Melton
la source
Si Service Broker est réactivé dans le cadre de la restauration (à l'aide de WITH ENABLE_BROKERet al), le code peut s'exécuter «automatiquement». Il est évident que le rénovateur ne veulent utiliser l' une de ces options si la sécurité est une préoccupation, mais il pourrait être enterré à l' intérieur d' une 3ème partie app fournisseur où l'utilisateur pourrait ne pas le voir.
Jon Seigel
Quel type de code peut être exécuté via Service Broker? Je ne l'utilise ni ne l'installe.
Shawn Melton
Activation des procédures stockées. technet.microsoft.com/en-us/library/…
Jon Seigel
2
Peut-être aussi faire un RESTORE HEADERONLY pour voir si le confinement est activé dans la base de données. Si tel est le cas et que le confinement est activé sur le serveur, les utilisateurs pourront y accéder sans que vous leur accordiez l'accès au serveur. C'est pour SQL 2012 ou plus récent, bien sûr. si le confinement n'est pas activé sur le serveur et que la base de données dans la sauvegarde l'a activée, la restauration échouera, donc principalement un problème uniquement si elle est activée sur le serveur.
Robert L Davis
1
@JonSeigel Je ne pense pas que ceux-ci se déclencheront automatiquement. QUELQUE CHOSE doit mettre un message dans une file d'attente en l'envoyant à un service, il doit donc y avoir une certaine interaction dans cette base de données pour insérer un enregistrement ou déclencher une procédure ou quelque chose. Les files d'attente des courtiers ne se contentent pas de déclencher leurs procédures d'activation sans aucune interaction, elles surveillent les messages à afficher dans la file d'attente.
JNK
11

Vous pouvez effectuer certaines étapes de prévention.

  1. Assurez-vous que personne sauf un administrateur système n'a accès à la base de données restaurée.
  2. Mettez la base de données en mode mono-utilisateur une fois la restauration terminée.
  3. Vérifiez le code dans toutes les procédures et fonctions stockées et les déclencheurs dans cette base de données.
  4. Effectuez une vérification dbcc pour vous assurer qu'il n'y a aucun problème d'intégrité.
  5. Vérifiez les utilisateurs qui avaient accès à la base de données et supprimez-les tous.
  6. Commencez à autoriser l'accès, très limité à des objets spécifiques vérifiés par vous.

Comme l'a dit Shawn, le code ne s'exécutera pas de lui-même à moins qu'une procédure stockée qui semble vbalid ait un exécutable d'un autre code malveillant. C'est la raison de vérifier le code à l'intérieur de chacun d'eux avant de le mettre en mode multi-utilisateur.

yrushka
la source
10

J'arrive ici, mais je peux penser à au moins un scénario dangereux: si vous restaurez une base de données qui a un fichier , ces fichiers sont maintenant sur votre réseau par défaut (et plus précisément, sur votre serveur SQL). Vous pouvez restaurer un virus.

Cela ne fera rien en soi, bien sûr - le virus ne devient pas soudainement sensible - mais si vos utilisateurs tentent ensuite d'accéder au fichier, ils pourraient être infectés. (Hé, j'ai dit que j'atteignais.) J'imagine un scénario où un pirate extérieur veut avoir des logiciels malveillants dans la porte, et il envoie ensuite un e-mail à Bob en comptabilité en disant: "Voici le fichier: \ sqlserver \ filetableshare \ myvirus.exe "- à ce stade, il est passé votre pare-feu sans détection, et nous sommes maintenant à vos outils antivirus et anti-malware internes.

Brent Ozar
la source
2
Vous pouvez également exprimer cela comme «la base de données contient des instructions pratiques pour notre personnel qui doivent être lues et appliquées». S'ils suivent la procédure malveillante, ils lanceront les roquettes sur Moscou. Ce serait une varchar ordinaire dans une table ... Idem si vous restaurez des binaires et invitez des employés à l'exécuter sans valider l'origine, vous l'avez fait venir.
Remus Rusanu
@RemusRusanu lance les roquettes sur Moscou, hahaha, chouette!
Brent Ozar
J'adore la perspective de l'ingénierie sociale. Un e-mail ciblé avec un fichier .bak pourrait probablement être très attrayant selon la cible.
Max Vernon
7

RESTORE VERIFYONLY semble être une bonne première étape. La réponse ultime est probablement «restaurer la base de données dans une machine virtuelle sandbox sans accès au monde extérieur», mais supposons que cette option est hors de propos. Que faut-il faire d'autre dans cette situation?

La restauration vérifie uniquement l' intégrité de la base de données, elle ne vous dira pas si la sauvegarde inclut un code malveillant ou non. RESTORE VERIFYONLY n'essaie pas de vérifier la structure des données contenues dans les volumes de sauvegarde. Il est très différent que si la sauvegarde vient de l'intérieur de l'entreprise où vous travaillez peut être malveillante, mais si elle provient d'un tiers, vous devez être prudent, comme l'a souligné Shawn.

La documentation de Microsoft Online indique que

• Pour des raisons de sécurité, nous vous recommandons de ne pas attacher ou restaurer des bases de données à partir de sources inconnues ou non fiables. Ces bases de données peuvent contenir du code malveillant qui pourrait exécuter du code Transact-SQL involontaire ou provoquer des erreurs en modifiant le schéma ou la structure de la base de données physique. Avant d'utiliser une base de données provenant d'une source inconnue ou non fiable, exécutez DBCC CHECKDB sur la base de données sur un serveur non productif et examinez également le code, tel que les procédures stockées ou tout autre code défini par l'utilisateur, dans la base de données.

Shanky
la source
7

La question se concentre principalement sur une sauvegarde contenant des logiciels malveillants, mais il est également possible d'obtenir un comportement indésirable et potentiellement malveillant de l'opération de restauration elle-même.

J'ai accidentellement découvert par le passé qu'il est possible de planter SQL Server en essayant de restaurer un fichier de sauvegarde corrompu qui fait que SQL Server essaie de lire après la fin du fichier de sauvegarde et se bloque. Je ne sais pas quelles versions sont susceptibles ou exactement ce qui est nécessaire pour reproduire le problème. J'ai documenté quelques détails limités ici lorsque j'ai rencontré ce problème il y a quelques années.

James L
la source
Bon point. Je ne voulais pas nécessairement me concentrer sur "une sauvegarde valide contenant des logiciels malveillants", planter le serveur SQL au moyen d'une sauvegarde non valide est également une réponse parfaitement pertinente à "qu'est-ce qui pourrait mal tourner?"
Simon Righarts
5

Quel risque y a-t-il à restaurer une base de données inconnue à partir d'une source inconnue? Aucun.

Quel risque y a-t-il à laisser une application inconnue se connecter à l'aide d'un compte sysadmin pour se connecter à cette base de données et commencer à exécuter du code? BEAUCOUP! Si le compte d'application n'a que des droits dans la base de données et aucun accès au niveau du serveur, il ne peut rien faire en dehors de la base de données. Cela revient essentiellement à avoir une configuration de cadre de sécurité appropriée sur le serveur pour commencer.

mrdenny
la source
2

On vous remet une sauvegarde de base de données et on vous dit de la restaurer sur un serveur (qui héberge déjà d'autres bases de données), mais vous ne recevez aucune information utile sur ce que contient la sauvegarde ou si la source doit être approuvée.

Agréable. Vous exigez une déclaration écrite signée de la personne qui vous dit de le faire, qui accepte l'entière responsabilité des conséquences. S'ils ne veulent pas le faire, vous devriez tester l'installation dans un bac à sable après avoir examiné le fichier de sauvegarde (si possible), et examiner soigneusement toutes les tables, procédures, etc. Si quelque chose sent drôle à un moment donné, ne le mettez pas sur le système de production. Même dans ce cas, vous devez indiquer clairement (à votre patron et à ses supérieurs) que vous n'avez jamais fait confiance à la sauvegarde et que vous ne le faites que sur ordre direct.

S'ils ne signent pas une telle déclaration, prévenez leur (s) supérieur (s) avant de faire quoi que ce soit. En tant que professionnel, il est de votre devoir de protéger votre système autant que possible, peu importe ce qu'un supérieur intelligent peut vous ordonner de faire. Vous pourriez être viré, mais vous pouvez garder la tête haute et savoir que vous avez fait la bonne chose.

Phil Perry
la source
2

Il n'y a pas beaucoup de dangers à proprement parler, à part certains de grande portée suggérés ici. Comme cela a été mentionné, il est difficile d'avoir des éléments auto-exécutables dans une sauvegarde de base de données elle-même. Il a besoin d'une sorte de mécanisme de déclenchement extérieur.

Obtenez un ancien ordinateur portable / bureau et une version d'évaluation de votre logiciel de base de données (SQLExpress) si la licence pose problème. Copiez le fichier de sauvegarde sur la machine, débranchez le réseau / sans fil et effectuez la restauration. Commencez ensuite à creuser. Prenez tout le temps dont vous avez besoin, car il y a de nombreux endroits où les choses peuvent se cacher, la plupart déjà couvertes par d'autres articles de ce fil.

Votre intégrité DBA et le bien-être de votre environnement de production sont plus importants que toute commande donnée par un supérieur.

Philippe
la source