去除SA的xp_cmdshell权限（绝对实用）
当大家从SA为空密码入侵得到一台服务器的时候，如果你不想在被其他的人入侵（自私）那么应该是首先更改SA的密码，然后在做其他的安全设置。可是当你辛辛苦苦的把安全都做的很好的时候，几天之后你发现SA的密码又为空：（
哈哈，是不是很生气？难道SA会自己把密码改回来？那当然不是了，是因为一般的网站采用的是ASP+SQL架设而成的，所以你改了他的SA密码，那么就导致他的网站无法运行了。那么有的很懒的管理员才不去想那些事情，直接把SA的密码在改为空。很气人吧？我就碰到过这样的问题，我改掉密码后，管理员第2天准的又改为空，让你哭笑不得，其实我想管理员也是哭笑不得了，干吗老改我的SA密码啊？你能有更好的办法告诉管理员么？
倒了半天的苦水，还是开始如何去除SA的CMDshell了：）
选择 开始——程序——Microsoft SQL Server——查寻分析器（Query
Analyzer)如图：
然后你可以看到如下面的这个窗口：
第一项让你添写SQL的服务器地址，因为我是在自己的机器上测试的，所以就在SQL
SERVER：那里写127.0.0.1
在看下面的连接使用（Connection InFORMation）：
第一项：Windows身份验证（Use Windows NT authentication）
第二项：SQL Server身份验证（Use SQL Server authentication）
因为我是在本地操作，所以选择第一项，当然你选择第二项也可以，（注：如果你是3389控制操作那么直接选择第一项就可以省略输入SA和密码验证这一步）然后按确定（OK）即可看到下面的窗口如图：
然后在那个查询的窗口中输入：if exists (select * from
dbo.sysobjects where id = object_id(N[dbo].[xp_cmdshell]) and
OBJECTPROPERTY(id, NIsExtendedProc) = 1)
exec sp_dropextendedproc N[dbo].[xp_cmdshell]
GO
然后按F5键命令执行完毕。然后关闭SQL查询器是问你是否要保存，你选择不保存退出。然后你在用SQL的客户端或者流光自带的SQL连接上去看看，执行NET命令看看，如图：
到此SA的CMDSHELL权限就被去除了，当然你也不可以在使用SA作为后门了：（
以上测试在SQL7.0与SQL2000版本中通过
这下即使别人得到SA的密码也不能执行NET命令了，是不是不用担心了？可是我在告诉你哦，既然可以去除SA执行CMDSHELL权限，当然就可以在恢复SA可以执行CMDSHELL权限了，恢复SA的CMDSHELL权限也测试成功，只是SQL7.0和SQL2000版本使用的命令不一样。在这里我就不写出来了，有兴趣的朋友可以自己测试。
在学习过程中WAWA和沙子给了我很大的帮助，在这里向你们俩真心的感谢并附言：快点找GF呀，呵呵！~
补充：
其实在SQL中存储扩展很多，但是基本上不会用到xp_cmdshell这个扩展，当然我也是根据SQL的联机手册看的，所以才确定xp_cmdshell删除后不会造成影响。采用SQL+ASP的结构如果他是在安装SQL时候选择混合式那么就得使用密码验证，在SQL7.0中SA的默认密码为空，有的管理员不了解安全问题为了方便所以就使用空密码，那么使用密码验证都会有一个global.asa文件，也就是数据库验证文件，在那个文件中你可以找到以下这一句：
Application("strConn_Comm") =
"Provider=SQLOLEDB.1;Password=123;Persist Security Info=True;User
ID=sa;Initial Catalog=DBJobs;Data Source=211.***.***.***;Connect
Timeout=15"
Application("strConn_Manage") =
"Provider=SQLOLEDB.1;Password=123;Persist Security Info=True;User
ID=sa;Initial Catalog=DBJobs;Data Source=211.***.***.***;Connect
Timeout=15"
Application("strServerIP")="211.***.***.***"
从以上的连接语句中我们可以看出SA的密码为123如果SA的密码被改了，那么除非你在这个文件里把password的值改成SA的密码一样，否则他的网站遍出现ODBC数据错误，global.asa多少行多少行错误。就像有的朋友在问为何SA的密码设置的很强壮但是流光却还是可以把SA的密码扫出来？那么现在大家应该明白流光为何可以把那些很复杂的密码扫出来了，那就是因为文件设置的权限错误导致流光读取了global.asa文件中的数据库连接语句。所以大家如果自己写程序的时候最好不要使用SA来做为验证，可以建立一个普通的用户。如果我们是从SA入侵了，那么如果改掉SA的密码当然也的更改global.asa文件，那么管理员就会发现他的机器被入侵了。（注：以上的SA验证语句只是其中的一个手法，每个程序员所写的连接语句都不一定会一样）以上如果有错误请大家指正
哈哈，是不是很生气？难道SA会自己把密码改回来？那当然不是了，是因为一般的网站采用的是ASP+SQL架设而成的，所以你改了他的SA密码，那么就导致他的网站无法运行了。那么有的很懒的管理员才不去想那些事情，直接把SA的密码在改为空。很气人吧？我就碰到过这样的问题，我改掉密码后，管理员第2天准的又改为空，让你哭笑不得，其实我想管理员也是哭笑不得了，干吗老改我的SA密码啊？你能有更好的办法告诉管理员么？
倒了半天的苦水，还是开始如何去除SA的CMDshell了：）
选择 开始——程序——Microsoft SQL Server——查寻分析器（Query
Analyzer)如图：
然后你可以看到如下面的这个窗口：
第一项让你添写SQL的服务器地址，因为我是在自己的机器上测试的，所以就在SQL
SERVER：那里写127.0.0.1
在看下面的连接使用（Connection InFORMation）：
第一项：Windows身份验证（Use Windows NT authentication）
第二项：SQL Server身份验证（Use SQL Server authentication）
因为我是在本地操作，所以选择第一项，当然你选择第二项也可以，（注：如果你是3389控制操作那么直接选择第一项就可以省略输入SA和密码验证这一步）然后按确定（OK）即可看到下面的窗口如图：
然后在那个查询的窗口中输入：if exists (select * from
dbo.sysobjects where id = object_id(N[dbo].[xp_cmdshell]) and
OBJECTPROPERTY(id, NIsExtendedProc) = 1)
exec sp_dropextendedproc N[dbo].[xp_cmdshell]
GO
然后按F5键命令执行完毕。然后关闭SQL查询器是问你是否要保存，你选择不保存退出。然后你在用SQL的客户端或者流光自带的SQL连接上去看看，执行NET命令看看，如图：
到此SA的CMDSHELL权限就被去除了，当然你也不可以在使用SA作为后门了：（
以上测试在SQL7.0与SQL2000版本中通过
这下即使别人得到SA的密码也不能执行NET命令了，是不是不用担心了？可是我在告诉你哦，既然可以去除SA执行CMDSHELL权限，当然就可以在恢复SA可以执行CMDSHELL权限了，恢复SA的CMDSHELL权限也测试成功，只是SQL7.0和SQL2000版本使用的命令不一样。在这里我就不写出来了，有兴趣的朋友可以自己测试。
在学习过程中WAWA和沙子给了我很大的帮助，在这里向你们俩真心的感谢并附言：快点找GF呀，呵呵！~
补充：
其实在SQL中存储扩展很多，但是基本上不会用到xp_cmdshell这个扩展，当然我也是根据SQL的联机手册看的，所以才确定xp_cmdshell删除后不会造成影响。采用SQL+ASP的结构如果他是在安装SQL时候选择混合式那么就得使用密码验证，在SQL7.0中SA的默认密码为空，有的管理员不了解安全问题为了方便所以就使用空密码，那么使用密码验证都会有一个global.asa文件，也就是数据库验证文件，在那个文件中你可以找到以下这一句：
Application("strConn_Comm") =
"Provider=SQLOLEDB.1;Password=123;Persist Security Info=True;User
ID=sa;Initial Catalog=DBJobs;Data Source=211.***.***.***;Connect
Timeout=15"
Application("strConn_Manage") =
"Provider=SQLOLEDB.1;Password=123;Persist Security Info=True;User
ID=sa;Initial Catalog=DBJobs;Data Source=211.***.***.***;Connect
Timeout=15"
Application("strServerIP")="211.***.***.***"
从以上的连接语句中我们可以看出SA的密码为123如果SA的密码被改了，那么除非你在这个文件里把password的值改成SA的密码一样，否则他的网站遍出现ODBC数据错误，global.asa多少行多少行错误。就像有的朋友在问为何SA的密码设置的很强壮但是流光却还是可以把SA的密码扫出来？那么现在大家应该明白流光为何可以把那些很复杂的密码扫出来了，那就是因为文件设置的权限错误导致流光读取了global.asa文件中的数据库连接语句。所以大家如果自己写程序的时候最好不要使用SA来做为验证，可以建立一个普通的用户。如果我们是从SA入侵了，那么如果改掉SA的密码当然也的更改global.asa文件，那么管理员就会发现他的机器被入侵了。（注：以上的SA验证语句只是其中的一个手法，每个程序员所写的连接语句都不一定会一样）以上如果有错误请大家指正
相关文章
图文推荐
- 文章
- 推荐
- 热门新闻