Remove the xp_cmdshell permission of SA (absolutely practical)

When you get a server from an empty SA password, if you don't want other people to intrude into the server (selfish), you should first change the SA password, then, other security settings are being performed. However, when you have worked hard to ensure security, after a few days, you will find that the SA password is empty again :(
Haha, are you angry? Does SA change its password? Of course not, because the general website is built on ASP + SQL, so you have changed his SA password, so his website cannot run. So some very lazy administrators don't want to think about those things, and directly change the SA password to null. Very irritating, right? I have encountered such a problem. After I changed my password, the Administrator changed it to empty again within 2nd days, which made you laugh and cry. In fact, I think the Administrator is also speechless, why do I always change my SA password? Can you tell the Administrator a better way?

After a long time of hard work, I began to remove SA's mongoshell :)

Select Start -- program -- Microsoft SQL Server -- Query analyzer (Query
Analyzer)



Screen. width-333) this. width = screen. width-333 "border = 0>




Then you can see the following window:



Screen. width-333) this. width = screen. width-333 "border = 0>




First, let you add the SQL server address. Because I tested it on my machine
SERVER: enter 127.0.0.1

Check the following Connection InFORMation ):

Item 1: Use Windows NT authentication)

Item 2: SQL Server authentication)

Because I operate locally, select the first item. Of course, you can select the second item. (Note: if you are using the 3389 control operation, simply select the first option to omit the SA and password verification step.) then press OK to see the following window.



Screen. width-333) this. width = screen. width-333 "border = 0>




Then, in the query window, enter: if exists (select * from
Dbo. sysobjects where id = object_id (N [dbo]. [xp_mongoshell]) and
OBJECTPROPERTY (id, NIsExtendedProc) = 1)

Exec sp_dropextendedproc N [dbo]. [xp_cmdshell]

GO

Then press F5 to complete the command execution. Close the SQL queryer and ask if you want to save it. You can choose not to save and exit. Then you can use the SQL client or the SQL connection that comes with streaming to execute the NET command,



Screen. width-333) this. width = screen. width-333 "border = 0>




By now, the SA's mongoshell permission has been removed. Of course, you cannot use SA as a backdoor :(

The above test is passed in SQL7.0 and SQL2000

Now, even if someone else gets the SA password, they cannot execute the NET command. Do you have to worry? However, I am telling you that, since SA can execute the mongoshell permission, of course, SA can be restored to execute the mongoshell permission, and the SA's mongoshell permission can be restored, the commands used by SQL7.0 and SQL2000 are different. I will not write it here. If you are interested, you can test it on your own.

In the course of study, WAWA and sand have helped me a lot. Here, I would like to express my sincere thanks to you two and say: Hurry up and find GF !~

Supplement:
In fact, there are a lot of storage extensions in SQL, but basically the xp_mongoshell extension is not used. Of course, I also read it according to the SQL online manual, so it is determined that xp_mongoshell will not be affected after deletion. Use the SQL + ASP structure. If you select hybrid mode when installing SQL, you must use password verification. In SQL7.0, the default SA password is blank, some administrators do not understand the security issues, so they use a blank password for convenience. the asa file, that is, the database Authentication file. in that file, you can find the following sentence:

Application ("strConn_Comm") =
"Provider = SQLOLEDB.1; Password = 123; Persist Security Info = True; User
ID = sa; Initial Catalog = DBJobs; Data Source = 211. ***; Connect
Timeout = 15"



Application ("strConn_Manage") =
"Provider = SQLOLEDB.1; Password = 123; Persist Security Info = True; User
ID = sa; Initial Catalog = DBJobs; Data Source = 211. ***; Connect
Timeout = 15"



Application ("strServerIP") = "211 .***.***.***"

From the above connection statement, we can see that the SA password is 123. If the SA password is changed, unless you change the password value to the SA password in this file, otherwise, an ODBC data error occurs on his website. the number of rows on the asa and the number of rows are incorrect. Just like some friends are asking why SA's password is strong, but it can still be swept out of the SA's password? Now, we should understand why streaming can scan out complicated passwords, that is, the database connection statements in the global. asa file are read due to incorrect permissions set in the file. Therefore, if you do not want to use SA for verification when writing your own program, you can create a common user. If we intrude from SA, if we change the SA password and the global. asa file, the Administrator will find that his machine has been intruded. (Note: The preceding SA verification statement is only one of the methods, and the connection statements written by each programmer may not be the same.) If any of the above errors is correct