MYSQL Server Hacking [Part 3]

Why not revoke authorization?
Chris Anley in his document entitled "Violating Database - Enforced Security Mechanisms" [6] described an approach to enhancing security, which involves a modification of SQL Server functioning to ignore queries from anyone but “sa” users. His invention is based on the idea of handling authorization procedure exceptions by the SQL Server code. “Rather than attempting a static analysis of the entire SQL server codebase, a little debugging up front will probably point us in the right direction”. Of course, such a change is feasible under particular conditions – either by manipulating the executable file that contains the SQL server codebase or by making operations on the in-memory image –in both cases, the SQL Server System Administrator is the only person authorized to do this. However, this is a simplified situation. The reality is rather bleak. Before entering in further detail, let me remind you that the observance of current security bulletins is of top importance, otherwise the buffer might overflow.
Why is a buffer overrun problem of concern? As you may remember, SQL Server has many default extended stored procedures i.e. DLL functions that come with SQL Server. They are written in any high level language (for example C) and then compiled as a DLL. On starting to run, they read user’s parameters to the memory buffer. However as may happen for whatever reason, the programmer may forget to encrypt the data check being placed into variables in the program – and if an attacker sends too much data, it is possible for the data to "overflow" the predetermined size and write the data to adjacent areas of the computer buffer. This buffer overflow may allow malicious users to run arbitrary commands on the remote system. (See, for example, “Analysis of Buffer Overflow Attacks “ by Piotr Frej and Maciej Ogórkiewicz). The problem is that Microsoft SQL Server contains procedures that are vulnerable to buffer overflow attacks. These are both the previously described extended stored procedures as well as functions implemented in the Transact-SQL language (an example may be the previously mentioned "pwdencrypt" function). This may also happen with OLEDB libraries, which are COM objects loaded in the client process. Remember, that in the COM context, every component-based program becomes a client. Whenever the OPENROWSET command is activated, SQL Server becomes a client of the data provider, which makes it automatically vulnerable to errors in the code of a particular OLEDB. For those interested, you might wish to read various security bulletins [7] for details of problems and proposed solutions. If so, be aware that a successful buffer overflow attack means that every user may run arbitrary code on the SQL server in the context of a local administrator account. And as we already know, these (“sa”) privileges allow for arbitrary manipulation of SQL service, nevertheless we are still left with the following problem – how powerful are the "sa" privileges in the operating system context?
They are equally powerful to the SQL service and, reasoning strictly in security terms, these privileges correspond to those of the SQLSERVR.EXE process. By “standard” default, SQL Server includes several very powerful extended stored procedures to communicate with the operating system. Just to mention some of them:. "xp_cmdshell", "sp_OACreate", "xp_regwrite", "xp_instance_regwrite", "xp_adsirequest". Though some of them are documented (two first ones), we are still uncertain of the effects of others. Using these procedures, SQL Server administrators can interact with the operating system only limited by the authorizations for the MSSQLServer service. If it were a case of running this service in the LocalSystem account, the "sa" would have been granted top privileges to access the Desktop but not the network directories.
http://multisoftware-worldwide.blogspot.com
The attacker may make use of these privileges as illustrated in Figure 4.
FIGURE 4: Using the "sa" account to upload a program from the Internet to the server.

If, instead, we run the service with a domain account, which has access to the network, then the “sa” user might access the whole network. However, for regular user accounts this will be a surprise. The "sa" account privileges depend on how the MSSQLServer service has been configured. In the SQL Server documentation it is clearly stated that the MSSQLServer account is a user account and not a system account. Even though recently we have read in Microsoft Security Bulletins dealing with SQL Server: “SQL Server 2000 can run under a non-administrator account, however it requires full access to registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer”
Having this access level, the SQL server process is able to modify an "ObjectName" value in the registry. It contains the name of the account that is necessary to run the service. This is enough to re-configure the service to run as LocalSystem. Hence, an attacker who is able to run code under an SQL Server account is able to re-configure a service to run under the highest possible local privileges, even if SQL Server is running as a regular user! This problem has been addressed in the third section of the Microsoft Security Bulletin MS02-034 [8]. To read about the permissions required by SQL Server, refer to the SQL Server 2000 Security document [9]
LocalSystem by default?
Microsoft SQL Server 2000 Desktop Edition (MSDE 2000), the latest version of MSDE is installed with the LocalSystem account as a default. Of course, this creates potential vulnerability to attacks as described above. Naturally, patching SQL Server to Service Pack 3 enhances security – but of the SQL Server service itself, not the machine on which it is running. Instead, having installed SP3, you can experience problems if the server is running somewhere other than the LocalHost. This is a consequence of the permissions that are set to the registry key and the file system with the installation of SP3. Of course, minimizing unwanted privileges is a positive factor but leaving this approach with insufficient documentation is bad practice. Included below is some basic information to help one complete the documentation as required.
In order to reduce MSDE –associated privileges in the operating system:
Replace both the MSSQLServer and SQLServerAgent service accounts (with LocalSystem) with a selected account
Provide this new account with the right to read in the C:\Program Files\Microsoft SQL Server\MSSQL directory, remembering to check the "Reset permissions on all child objects" option in the Advanced dialog box
Grant full privileges in DATA and LOG sub-directories for this new account
Run the registry using regedt32.exe (in such a manner so as to allow for editing of privileges - use regedit.exe if in Windows XP) and grant full permissions for the account in the registry key: HKLM\SOFTWARE\Microsoft\MSSQLServer. Re-run the "Reset permissions on all child objects ..."
Grant read permission to the account (read only!) in the registry key HKLM\SYSTEM\CurrentControlSet\Services\MSSQLSERVER
Run the MSSQLServer service
Add the service account to the sysadmin server role (to support the SQLServerAgent service), using the following SQL commands:
1> sp_grantlogin 'COMPUTER\account_sql'2> goGranted login access to 'COMPUTER\account_sql'.1> sp_addsrvrolemember 'COMPUTER\account_sql','sysadmin'2> go'COMPUTER\account_sql' added to role 'sysadmin'.
Run the SQLServerAgent service
SQL commands are to be run using the osql.exe program under the system administrator account specifying the E parameter. Obviously, you should specify the real name of the SQL service account that must be preceded with the machine name. If you not wish to grant access to your MSDE server from the network, disable the following registry key:
HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib
For obvious reasons, it is good practice to export this registry key to the .reg file earlier on. If problems arise with starting MSDE service, use FileMon and RegMon programs available at www.sysinternals.com - these are very useful tools when analyzing and remedying difficulties resulting from over-restrictive constraints posed on registry keys or file systems. It is also worth consulting the SQL Server 2000 Documentation