从未知来源恢复备份的安全隐患？

31

场景：您已经获得了数据库备份，并被告知将其还原到服务器上（该服务器已经托管了其他数据库），但是没有提供有关备份内容或是否应该信任源的有用信息。

问题1：还原很可能是恶意的备份有哪些潜在影响？

问题2：如何保护服务器/其他数据库中的数据免受还原潜在恶意备份的影响？RESTORE VERIFYONLY似乎是一个很好的第一步。最终的答案可能是“将数据库还原到无法访问外部环境的沙箱VM中”，但让我们假设该选项不在桌面上。在这种情况下还应该做什么？

sql-server backup security

— 西蒙·里格斯（Simon Righarts）
source

1

即使假设还原是仅数据的（没有存储过程等），也可能发生很多恶意事件。假设备份是针对包含用户表及其相应权限级别的Web应用程序的，则恶意备份可以将访问权限授予不应该拥有该用户表的用户，并且他们知道他们可以做什么。

— Lie Ryan

非常奇怪的是，没有人提到CLR程序或功能的潜在风险。（默认不再禁用）

— ALZDBA 2014年

21

数据库可能包含恶意代码，可能是一个过程，该过程将更改“ sa”登录名的密码或删除每个数据库。但是，我看到导致问题的唯一方法是个人还原数据库，然后手动执行该数据库中的任何代码。它不会以任何自动化方式执行。

数据库中没有可以应用的设置，以使SQL Server在将数据库还原到服务器时自动执行数据库中的某些代码。如果可以的话，我希望微软会放弃该产品的通用标准认证。这对我来说是一个DBMS所允许的错误。

— 肖恩·梅尔顿
source

如果在还原过程中重新启用了Service Broker（使用WITH ENABLE_BROKERet al等），则代码可以“自动”运行。显然，如果出于安全考虑，恢复器将不希望使用这些选项中的任何一个，但是它可能被埋在用户可能看不到的第三方供应商应用程序中。

— 乔恩·塞格尔

通过Service Broker可以执行哪种代码？我从不使用或设置它。

— 肖恩·梅尔顿

激活存储过程。technet.microsoft.com/zh-CN/library/…–

— 乔恩·塞格尔

2

也许还可以进行RESTORE HEADERONLY，以查看数据库是否启用了遏制。如果是这样，并且在服务器上启用了遏制，则用户无需您授予服务器访问权限就可以访问它。当然，这适用于SQL 2012或更高版本。如果未在服务器上启用遏制，并且备份中的数据库已启用，则还原将失败，因此主要是在服务器上启用遏制后才需要考虑的问题。

— 罗伯特·L·戴维斯

1

@JonSeigel我不认为那些会自动触发。某些东西必须通过将消息发送到服务来将其放入队列中，因此该数据库内必须进行某种交互才能插入记录或触发过程或其他操作。代理队列不只是在没有任何交互的情况下继续触发其激活过程，而是监视消息以显示在队列中。

— JNK

11

您可以采取一些预防措施。

确保只有一位系统管理员可以访问已还原的数据库。
还原完成后，将数据库置于单用户模式。
检查此数据库中所有存储过程和函数以及触发器中的代码。
执行dbcc checkdb以确保没有完整性问题。
检查曾经有权访问数据库的用户并删除所有用户。
开始允许访问，但仅限于您检查的特定对象。

就像Shawn所说的那样，代码本身不会执行，除非某些看起来像vbalid的存储过程有另一个恶意代码的执行程序。这是在将其置于多用户模式之前检查其中每个代码的原因。

— 尤鲁什卡
source

10

我到达这里，但我至少能想到一个危险的情景：如果您恢复，有一个数据库文件表，这些文件现在网络上的默认情况下（具体而言，在你的SQL Server）。您可以还原病毒。

当然，这本身不会做任何事情-病毒不会突然变得有意识-但是，如果您的用户随后尝试访问该文件，则可能会感染它们。（嘿，我说我要伸手去拿。）我正在构想一种情况，外部黑客想要在门上安装恶意软件，然后他向电子邮件发送一封电子邮件给Bob，说：“这是文件：\ sqlserver \ filetableshare \ myvirus.exe”-到那时，它已被防火墙检测到，没有被发现，现在我们可以使用内部的防病毒和防恶意软件工具。

— 布伦特·奥扎尔
source

2

您也可以将其表示为“数据库包含必须阅读和应用的有关我们人员的操作说明”。如果他们遵循恶意的方法，他们将向莫斯科发射火箭。这将是普通的varchar ina表...同上，如果您还原二进制文件并邀请员工运行而无需验证原点，那么它就来了。

— Remus Rusanu 2014年

@RemusRusanu在莫斯科发射火箭，哈哈哈，太好了！

— 布伦特·奥扎尔

热爱社会工程学的观点。带有.bak文件的目标电子邮件可能很诱人，具体取决于目标。

— Max Vernon 2014年

7

恢复VERIFYONLY似乎是一个不错的第一步。最终的答案可能是“将数据库还原到无法访问外部环境的沙箱VM中”，但让我们假设该选项不在桌面上。在这种情况下还应该做什么？

Restore verifyonly会验证数据库的完整性，它不会告诉您备份是否包含恶意代码，而RESTORE VERIFYONLY不会尝试验证备份卷中包含的数据的结构。极不可能的是，如果备份来自您工作所在的公司内部，则可能是恶意的，但如果备份来自某个第三方，则需要小心，如Shawn所指出的那样。

Microsoft Online文档说

•出于安全目的，我们建议您不要从未知或不受信任的源附加或还原数据库。此类数据库可能包含恶意代码，这些恶意代码可能执行意外的Transact-SQL代码或通过修改架构或物理数据库结构而导致错误。在使用来自未知或不受信任来源的数据库之前，请在非生产服务器上的数据库上运行DBCC CHECKDB，并检查数据库中的代码，例如存储过程或其他用户定义的代码。

— 香克
source

7

这个问题主要集中在包含恶意软件的备份上，但是还可能从还原操作本身中获得有害的和潜在的恶意行为。

我过去不小心发现，尝试还原损坏的备份文件可能导致SQL Server崩溃，导致SQL Server尝试读取备份文件末尾而崩溃。我不确定哪个版本容易受到感染，或者确切地说是重现该问题所需的版本。几年前遇到此问题时，我在这里记录了一些有限的详细信息。

— 詹姆斯·L
source

好点子。我并不一定要专注于“包含恶意软件的有效备份”，通过无效备份使SQL Server崩溃也是对“可能出什么问题？”的完美答案。

— Simon Righarts 2014年

5

从未知来源还原未知数据库有什么风险？没有。

让未知的应用程序使用sysadmin帐户连接到该数据库并开始运行代码有什么风险？很多！如果应用程序帐户仅具有数据库内的权限，而没有服务器级别的访问权限，则它在数据库之外实际上无能为力。基本上，这归因于首先要在服务器上设置适当的安全框架。

— 姆丹尼
source

2

您已获得数据库备份，并被告知将其还原到服务器（该服务器已经托管了其他数据库），但是未获得有关备份内容或源是否值得信任的有用信息。

真好您要求任何告诉您执行此操作的人都签署一份书面声明，以使他们对后果承担全部责任。如果他们不愿意这样做，则应在检查备份文件后（如有可能）在沙盒中测试安装，并彻底检查所有表，过程等。如果有任何气味，请不要放在任何地方生产系统。即使这样，您也应该（向您的老板和上司）清楚地表明，您从未信任过备份，并且仅在直接命令下才这样做。

如果他们不会签署这样的声明，请在做任何事情之前警告其上级。作为专业人士，不管某些机智的上级可能命令您做什么，您都有责任尽可能多地保护系统。您可能会被解雇，但可以昂首阔步，知道自己做对了。

— 菲尔·佩里
source

2

除了这里建议的一些深远的危险外，每个人所说的没有很多危险。如前所述，很难在数据库备份本身中包含自动执行的内容。它需要某种外部触发机制。

如果许可存在问题，请使用旧的笔记本电脑/台式机以及数据库软件（SQLExpress）的评估版。将备份文件复制到计算机上，拔下网络/无线网络，然后进行还原。然后开始挖掘。花费所有时间，因为有很多地方可以隐藏东西，其中大多数已经被该线程中的其他帖子覆盖了。

与上级下达的任何命令相比，DBA的完整性和生产环境的舒适性更为重要。

— 菲利普
source