What security threats does the SA account and other known account names pose to security?

Question

Does an known account name like sa, pose a security threat to database? When using windows authentication on SQL Server does it impose the same password policy(if it was set to say account lockout after 5 times)?

Answer 1

Does an known account name like sa, pose a security threat to database?

A "god" user account with a known name is generally considered a worse idea than a god user with a less well known name. It makes brute force attacks that bit easier as the attacker only has to guess the password and not the username and the password.

Also having a god user anyway can be dangerous. You are generally better off having specific users with specific rights for what they need to do. This sort of privilege based security is easier to implement from scratch than it is to retrofit into your environment later.

Disabling sa and giving specific users specific admin rights as needed in SQL server is essentially the same recommendation as disabling root and handing out admin rights as needed via sudo under Linux and similar. You can always re-enable sa once directly connected to the machine with adequate privileges should anything go wrong and you end up dropping all the rights your users need to operate (and fix the issue) just the same as you can engineer root access to a Linux box if you have physical access to the box - so disabling the account is no magic bullet (but once an attacker has physical access to your machine, or full Administrative access via RDC or SSH, all bets are off anyway).

When using windows authentication on SQL Server does it impose the same password policy(if it was set to say account lockout after 5 times)?

When using Windows Integrated Authentication SQL server has no control over account lockouts and such - it just maps a Windows user to an SQL user and asks the OS to vouch for the fact that the user has provided appropriate credentials. For interactive human users this means any lockout would occur as the user attempted to authenticate with Windows, not as they logged in to SQL Server.

Answer 2

It's not a bad idea to make it so that the default admin user (admin/root/postgres/sa/etc) don't actually exist in your system. You can always create a privileged account under a different name.

If nothing else, people trying to exploit your system don't have quite as easy of a time as if they're working blind (eg, sql injection without having some interactive shell nor being able to see direct output from their commands)

As for account lockouts -- if someone's managed to get far enough to even be able to attempt to log into your machine, unless you specifically allow direct login from users, you've already lost the battle. Personally, I'm not in favor of lockouts for the most part, because it gives someone the ability to create a denial of service if they manage to get the name of any of your users. (and having them lock out the super user? not fun).

I'd recommend looking over the CIS Benchmarks ... they don't have them for every database, but they have recommendations for Oracle, MS SQL, DB2 and MySQL. If you're running something else, it's still worth looking over the general sorts of things they recommend.

Answer 3

I didn't see anyone else mention this so I'll add it. With SQL Server 2005+ if your server is part of a domain and the domain has a password policy you can enable the password policy to be enforced on SQL logins. This includes password complexity requirements and the ability to force password changes at login.

Note that this can at times cause problems with some software installers that haven't been updated to work with SQL 2005+ and create SQL logins with insecure passwords.

Answer 4

There are two authentication modes used in SQL Server: Windows authentication and mixed mode (enables both Windows authentication and SQL Server authentication)

The first mode is less vulnerable to brute-force attacks as the attacker is likely to run into a login lockout (the Account Lockout Policy feature) after a finite number of attack attempts. Every production environment, if using Windows Authentication mode, should utilize the lockout policy feature, as it makes brute-force attacks impossible

When it comes to SQL Server authentication brute-force attack vulnerability, the situation is not so favorable. SQL Server Authentication has no features that allow detecting when the system is under a brute-force attack. Moreover, SQL Server is very responsive when it comes to validating the SQL Server authentication credentials. It can easily handle repeated, aggressive, brute-force login attempts without negative overall performance that might indicate such attacks. This means that the SQL Server Authentication is a perfect target for password cracking via brute-force attacks

Also, brute-force methods are evolving with each newly introduced encryption and password complexity method. For example, attackers that use rainbow tables (the pre-computed tables for reversing the cryptographic hash values for every possible combination of characters) can easily and quickly crack any hashed password

In order to protect your SQL Server from brute-force attacks, you should consider the following:

• Don’t use SQL Server Authentication mode - force the attacker to hit the login lockout via Windows Authentication
• In case you need to use SQL Server Authentication mode, disable or remove the SA login – that way the attacker must guess and pair both the user name and password

Answer 5

The sa account, when enabled can do anything on the SQL Server. If an attacker were to get into this account they could do anything on the SQL Server instance (and possibly the host OS) that they wanted.

Answer 6

The SA (and other well known account names) are well known points that hackers can attack. Some of the Oracle ones were poorly documented and thus the default passwords were not always changed. Once you've got control of the SA account in SQL Server, you control the server it is running on and can run any code or install anything you wish. In my more cowboy days, I remember not being allowed (it needed paperwork I wasn't going to fill out) to install an ActiveX control on a webserver that was also hosting the SQL Server - so I used xp_cmdshell to copy and install the control.