SA without a password - Whats so bad about this?
-
I am supporting a user whose application INI file uses the SA ID to connect to SQL Server. What can I tell him that will scare him into putting a password on SA?
-
Tell him that anyone, and that does mean anyone can log into his server and do whatever the heck they want, from dropping all of his databases to removing all the logins...and even better than that they could login using sa, change the sa password to something and then drop all other logins, thus preventing anyone from logging into sql period.
Even with a password, you shouldn't leave the sa info sitting out in any file anywhere.
-
Even better...go in and detach his database, then tell him his db is gone...it'll put the wind up him, may be then he'll get the hint
-
Doesn't SA also operate in the same security context as the account used to run sql? Potentialy widening the risk to the entire server?
So the intruder could use xp_cmdshell to format the HD etc etc.
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors) -
When you say you are supporting this application, do you mean that if something happens to the db or server it's your head? If so then don't pussy foot around, if it's your responsibility to secure and maintian the server revoke all his access to the server until he complies. Regardless of respective authority. It's part of your job to protect people from themselves.
Dave
Trainmark.com IT Training B2B Marketplace
(Jobs for IT Instructors) -
Also if SQL is running under a domain account it allows you to go out and screw with stuff all over the place...lotsa fun to be had by all
-
Even if he weren't using the SA account without a password as long as he has any account that is potentailly exposed via that ini file that has more than read of non-sensitive data on the server you have a threat.
Give him no choice and require him to change the architechure of the application as he is a security violation in most all organizations.
-
Why are you not using NT only security. We do this on all our servers bar 1. The odd one is running some legacy web-based applications that require SQL authentication.
NT security works very well, and avoids the need to code accounts or passwords in INI files.
As for scaring this user, discuss it with your manager as this is a very serious security hole. As a minimum, tell the user you are applying a password to SA and will not divulge it. Your manager should support you 100% on this
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
With or without a password, a user should not have the SA user id and it should never be in an INI file. I hope it is at least encrypted.
-
If you can login to one server with the SA password then you can hack into any other SQL Server on the network.
Try sp_addlinkedserver!
Because SA always has id 1 you don't have to add any linked server logins! This means that if one server has a blank SA password then they ALL effectively have blank SA logins.
If I was hacking a system then sooner or later I would be able to find a SQL Server with something interesting on it.
-
Two words:
SLAMMER WORM!
The default of a blank password for the SA account was utilized by Slammer. The fact that so many people did not have the SA login protected made this a very nasty worm.
It is very well known that the default password for the GOD account (SA) is blank.
I like the idea of logging in as SA and detaching the database, moving the files and then sitting back and watching the person mess their pants trying to find out what happened. But I would only do it with the boss' permission. It could backfire on you.
-SQLBill
-
Don't fix this, just hand out the name of your server...
and we'll all fix this,
for you all!
Regards,Coach James
-
The use of the sa account, for any reason is generally discouraged for the reasons you've heard here. It is the superuser account and has full access to do anything within SQL Server. Also, with xp_cmdshell, that account gives a user the ability to do anything under the context of whatever user account is being used to run the MSSQLSERVER service. In a default install this is probably the SYSTEM account meaning full administrative rights on the computer in question. In cases where a domain account is used, that means the application and anyone coming through the application potentially has the rights of that domain account. This is why sa, or any sysadmin level account for that matter, is not used for applications connecting into SQL Server.
As for SQL Slammer, I think you might be thinking of SQL Snake or SQL Spida, SQLBill. SQL Slammer only went after the SQL Server Listener service. SQL Snake and a worm before it, whose name escapes me, both went after port 1433 and used sa with a blank password. While both of those worms were stopped in their tracks, it's not to say another one won't come down the pipe.
Finally, in security there is the principle of least privilege. This says you give out only the rights necessary and no more. The use of the sa account in this application is most likely a clear violation of this security best practice.
K. Brian Kelley
@kbriankelley -
Any hackers manual Chapter 1 Section 1 Paragraph 1 :
Logon with the default : for SQLserver user 'sa' password ''
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data/code to get the best help[/url]- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
-
Worms, such as the recent Slammer worm, can scour the Internet looking for SQL Servers on port 1433. If it finds your client's server, and without a password on the sa account, he is totally hosed. Check out the following for more information on locking down SQL Server...
http://www.microsoft.com/sql/techinfo/administration/2000/security/securingsqlserver.asp
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply