Microsoft SQL Server is a popular and robust environment for many applications that use databases – it features excellent multi-access capabilities, comprehensive security coverage and can easily be transported to other database platforms. Unfortunately, such potential will not be realized – notwithstanding the use of
Microsoft SQL Server is a popular and robust environment for many applications that use databases – it features excellent multi-access capabilities, comprehensive security coverage and can easily be transported to other database platforms. Unfortunately, such potential will not be realized – notwithstanding the use of royalty-free MSDE (Microsoft Database Engine optimized for individual or small workgroup solutions) if adequate security protection to the databases is not provided as a minimum. Why is this must –have technology? Because high capabilities of the SQL Server are combined with high flexibility and too much flexibility may be detrimental if used in the wrong manner. This article aims to identify certain types of risks that might result from inappropriate management of the Microsoft SQL Server.
If properly configured, each SQL Server permits all users to access the master database, which contains all the settings for SQL Server – and all the information that SQL Server uses to open the databases. It also contains all SQL login IDs, data of connected servers etc. Of course, “normal” users are not allowed to access all information resources. Figure 1 illustrates how the server behaves if an attempt is made to access the account list – as can be seen, the server has prevented users from reading passwords. Nevertheless, account names and databases (including the information stored on them) may be accessed by unprivileged users. An example showing a piece of information taken by a user is illustrated in Figure 2 below.
FIGURE 1: A failed attempt to access the account list.
FIGURE 2: When a normal user manages to access the account list.
Scrolling to the bottom of the screen in the screenshot above gives the final few lines of screen ouput, shown below:
(4 rows affected)
1> select name,dbid from sysdatabases
(7 rows affected)
As can be seen it is difficult to keep your data secure from users’ prying eyes.
Of course, the reader may now wish to remark "But after all, my users are not allowed to run ad hoc queries on the SQL Server!” However, close examination shows this to be a rather dubious claim, because the possibility or impossibility of placing deliberately created queries in an SQL Server application does not necessarily imply that the same rule is valid for the server itself! Even though a specific application is apparently secured against such a situation, I would suggest that you reconsider this idea that all scripts are protected against SQL injection attacks"  What if the user, when defining query conditions, may attach a table to the results? And what is the server-defined authentication scheme to be applied for potential users? Even presuming that the application is well protected against unauthorized access to the data, the user himself cannot run standard communication tools on his computer to connect the SQL server- osql.exe, VBScript that uses ADO, or any other program that runs ODBC (or OLEDB) directly on the database server. Knowledge of the SQL Server password is the only prerequisite. Yet, in many situations, the possibility of authentication of local network users in the Directory Services is sufficient. However don't let paranoia set in - we must simply accept that the possibility of user authentication by the SQL Server is associated with the automatic right to ask probing, or even indiscreet questions.
What are the conclusions?
Let us look once again at the above example of a query that returns the account names – some of them are defined on the SQL server and are recognizable by the 0 value in the "isntname" column. If configured to perform authentication in Mixed Authentication Mode, the SQL Server will accept attempts to login on these accounts, while not disabling the account on repeated attempts. This is the drawback of the mechanism by which the SQL Server authenticates connections in mixed mode. Fortunately, its use is optional and even when it is present, it is not recommended, because it creates opportunities for a brute force attack in which each possible key or password is attempted until the correct one is found. Of course, a hacker may do this using a suitable program to automate such work (I, will not enter into details for obvious reasons). The most “appreciated” is an "sa" (System Administrator) account, which has access to everything as created specifically for the SQL server (It is similar to root on Linux or LocalSystem in Windows NT). It has the rights to manage any database (the "master" database included), full access to perform any function on the SQL Server and even to run processes that are inherited by the server’s service, namely the SQLSERVR.EXE process. Moreover, in many installations, SQL Server runs in the security context of the machine’s administrator - thereby the "sa" user can manage a computer with the MS SQL Server service installed, apart from managing all databases. When working with MSDE, the situation is even worse - the service is installed under LocalSystem, with a default "sa" account with a BLANK password! Figure 3 illustrates two consecutive attempts to hack the "sa" account, one failed attempt and another successful.
FIGURE 3: Two attacks on an "sa" account with a blank pass