使用cmdexec有哪些安全风险？

Question

我们正在从SQL 2000迁移到SQL 2005.我们有数百个DTS pacakges，开发团队不愿意使用SSIS进行重新开发。

将这些软件包迁移到SSIS时，我遇到了一个问题 - 许多软件包都是从Excel文件中读取的。

鉴于我的生产Box是64位，我被迫使用CmdExec子系统来调用32位运行时来执行这些包。

我的问题是：使用CmdExec子系统将这些SSIS包安排为SQL代理作业涉及哪些安全风险？

谢谢， 拉吉

Answer 1

无论运行该作业的任何帐户都可能有权从命令行运行命令 - 因此您需要考虑它将如何运行以及该帐户将拥有哪些权限。

例如，如果用户可以创建一个在sqlagent的上下文中运行的作业，并且您的sql代理程序被过度使用（更改安全性的权限），则可以授予自己较高的权限或损坏您的计算机。

Answer 2

SQL 2008为DTExec引入了一个开关，允许您使用SSIS的本机SQL代理任务以32位模式运行软件包。在作业步骤属性的执行选项卡上有一个32位的复选框，在查看命令行视图时会转换为“/ X86”开关。

如果您使用SQL 2005，那么CMDEXEC选项是我所知道的唯一选项。

Answer 3

xp_cmdshell是SQL Server中最大的安全风险，因为它允许受攻击的SQL Server框将攻击提升到主机操作系统本身，并从那里升级到整个网络。

典型的攻击媒介是网站HTTP表单 - ＆gt; SQL注入 - ＆gt; xp_cmdshell - ＆gt;接管SQL主机 - ＆gt;接管域名。如果xp_cmdshell被关闭，则攻击者必须找到其他方法将其攻击从SQL升级到主机。

存在其他情况，例如内部用户使用它来提升权限，或者将cmdshell用于其他目的，例如。窃取数据库。所有这些都基于xp_cmdshell允许在主机上执行任意命令的事实，并且在某些情况下，执行的命令也继承了SQL Server服务帐户权限。

如果xp_cmdshell被阻止，攻击者可以使用其他命令和扩展程序，但它们知之甚少。使用xp_cmdshell向量是在每个SQL注入备忘单和论坛讨论中，所以每个人和他们的大马都知道。