使用 cmdexec 有哪些安全风险？答案

【问题标题】：What are the security risks using cmdexec?使用 cmdexec 有哪些安全风险？
【发布时间】：2009-07-19 15:34:56
【问题描述】：

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

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

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

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

谢谢，拉杰

【问题讨论】：

【解决方案1】：

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

例如，如果用户可以创建一个将在您的 sqlagent 上下文中运行的作业，并且您的 sql 代理被过度授权（更改安全性的权利），她可能会授予自己提升的权限或损害您的机器。

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

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

典型的攻击向量是网站HTTP表单->SQL注入->xp_cmdshell->接管SQL宿主机->接管域。如果xp_cmdshell 被关闭，那么攻击者必须寻找其他手段将其攻击从 SQL 提升到主机。

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

如果xp_cmdshell 被阻止，攻击者可以使用其他命令和扩展程序，但它们鲜为人知。在每个 SQL 注入备忘单和论坛讨论中都使用xp_cmdshell 向量，因此每个人和他们的祖母都知道。

【讨论】：

我的问题是关于在 SQL 代理作业中使用 CmdExec 子系统。这和 xp_cmdshell 有什么关系？
好的，所以我离题了。我误读了你的问题。与 CmdExec 相关的风险是相似的，因为攻击者可以安排一个作业并将其用作升级向量，基本上取代了xp_cmshell，但这作为一个向量鲜为人知，因此风险大大降低。
这很好，我得到了 2 票反对，但没有人提供任何替代方案，哈哈
关于 xp_CmdShell 是最大的安全风险，我不得不说是垃圾！如果攻击者无法以“SA”身份进入，并且您还没有愚蠢到允许个人 priv 运行它，那么攻击者就无法进入它。如果攻击者可以作为“SA”进入，那么即使删除 DLL 也不会阻止黑客进入命令行，因为它可以使用 OPEN ROWSET 来完成。这就是你得到 2 票反对的原因。在谴责有史以来最有用的工具之一之前，您需要做一些功课。我承认在这种情况下很难找到正确的答案。