MYSQL Server Hacking [Part 2]

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" [1][2] 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.
http://multisoftware-worldwide.blogspot.com
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 password – the second attempt is successful.

Using the System Administrator account
First and foremost, the "sa" user has control over all SQL server data, scheme and setup. It is not necessary here to enter into details, because the list of system administrator privileges can contain almost anything. Instead, let us focus on certain purposely-selected types of malicious attacks. The simplest one consists in creating a new account with the same privileges as the "sa" user has. The listing below is an example:
1> sp_addlogin 'hacked','h4xor'2> goNew login created.1> sp_addsrvrolemember 'hacked','sysadmin'2> go'hacked' added to role 'sysadmin'.1> quitC:\>osql -U hacked -P h4xor -Q "SELECT DB_NAME(),USER_NAME()" -------- ------- master dbo(1 row affected)C:\>
In lieu of the "sp_addlogin" procedure one may use, for example, "sp_grantlogin" – the latter will establish an account being authenticated by the operating system on which the SQL server is running. I would like to note, that it is very easy to gain "sa" privileges – just by assigning the sysadmin role to the selected user (or a group of users defined at the SQL Server setup phase) account. Apart from this role, the SQL Server service makes it possible to exploit some other feature that, however, cannot be used to fully manage the server. I’ll refer those interested to [3]. Of course, it cannot be excluded that the administrator will detect such an account (even if its name does not stand out as anything unusual). If so, a hacker has no other options but to use the existent account – the simplest way would be to modify the password employing the "sp_password" procedure. If an intruder wishes to cover his tracks, he may attempt to decipher passwords, which give users access to the server. One might wish to remember at this point that in mixed mode authentication, the SQL Server can use its own authentication mechanism which stores information not only on account names (similar to the operating system based authentication) but also on passwords. This is done in the "password" column of the sysxlogins table- it contains a hash of the user's password produced by the pwdencrypt() function. This is a fairly well known fact brilliantly described by David Litchfield in [4]. The tools that can be used to perform brute force attacks are explained in [5]. If your SQL Server is not configured for SQL Server authentication, you don't have to worry about getting hacked in the above manner. A more malicious intruder may attempt to install a backdoor. Two possibilities are presented below.
Extended Stored Procedures
SQL Server features the possibility to run user-written procedures. These procedures can both be written in the SQL language and stored in any database, or they are dynamic link libraries (DLLs) that SQL Server can dynamically load and execute if required. This latter type is called "extended stored procedures" and means procedures that have interesting characteristics: they are added directly to the SQL Server and share the security context of the SQL Server executable. In practice, extended stored procedures can be made to run with „sa” privileges on the database. They can be defined only in the "master" database by which they can be added to the database by the administrator (the user "sa") only.
The default SQL Server configuration contains a virtually huge number of these procedures, however most of them are undocumented. Extended stored procedures can be made to run under different authentication schemes – certain procedures are made accessible for all users either by default or because the server’s functioning so requires. Only the system administrator can run other extended stored procedures. This creates a number of operational difficulties for the administrator especially in detecting “special” procedures that are likely to be embedded in the server by an intruder. It is sufficient to load a previously prepared DLL file to the computer (using the Open Data Services API, which is optionally installed with the SQL Server), then call the "sp_addextendedproc" procedure with its respective arguments, followed by granting the right to execute this procedure to all users (i.e. to the public user group). Such a procedure may then be used by a hacker to execute deliberate operations with “sa" privileges from any user account level!