HACKING MS SQL SERVERS FOR FUN & PROFIT
=====================================================
by Mount Ararat Blossom
11/13/2000
mountararatblossom@usa.net
===================================================
I am not sure what you want to get out of this but basically this paper is intended on breaking merely MS SQL servers especially versions 6.5 and 7.0 via TCP/IP over the port 1433. There are not that many remote SQL server exploitation techniques. However there are some and i wanna join them together as to use in our Pen-Tests.
Most of the time MS SQL server runs on TCP port 1433, if not configured to run on another TCP port. There are some port scanners which verifies the running service on the open port. Retina from the folks at eEye can do this favour for us.
==========================================================
SQL Server Network Protocol Libraries & Weaknesses
Named Pipes:
- Uses NT SMB ports (TCP 139, UDP 137,138) to communicate. These are usually blocked in any decent firewall implementation, but that can be an advantage if all access is internal
- User names, passwords, and data can be sent unencrypted (not using Integrated Security) for anyone with a packet sniffer to see
IP Protocol:
- If you leave the TCP port with the default value of 1433, you open yourself up to port scanners that can immediately spot the SQL server
- Packet sniffer threat. As there is no encryption.
Multi Protocol:
- Client must support NT RPCs; in a heterogeneous environment this can be trouble
- Uses random TCP ports by default but can be configured to use fixed ports to ease firewall implementation (see KB article Q164667).
- Make sure the encryption option is selected; it's not selected by default
If you can get away with using Integrated (NT) Security over Named Pipes or Multi-protocol, then do it. If possible, try to use multi-protocol and enable encryption. If you can't use either of those, then use IP Sockets, change the default TCP port to something else, and pray you don't get a packet sniffer on your segment. Also, consider using a Web server or COM components as the business object layer for an application and use a secure channel between the middle tier and the SQL server. This will remove some of the client connection issues and allow you to focus on encapsulation of business logic as well. There are several third-party products that can encrypt traffic on a segment - look into them.
===========================================================
Security Modes of SQL 6.5 & 7.0
The security mode defines how SQL Server will authenticate users attempting to make use of its services. Check the following table for a description of these modes and a breakdown of the differences.
Security Modes
SQL Server 6.5
SQL Server 7.0 changes
Standard
Logins are defined within SQL Server and given passwords
SQL Server logins are separate from Windows NT accounts
Exclusive Standard Mode security is not available in SQL Server 7.0
Integrated
Use the Security Manager to create SQL logins for NT Server user accounts
Users do not have to specify a separate login and password when they connect to SQL Server
Passwords are never stored in applications and never transmitted in plain text over the network
SQL Server gains the benefits of using NT to authenticate users and use features such as account expiration and lockouts
Requires Named Pipes or Multi-Protocol libraries
Now called 'Windows NT only' mode
SQL 7 now supports integrated security across all network protocol libraries
Only works on NT - Windows 95/98 installs do not support this mode (duh!)
Can integrate directly with NT groups for added ease of administration. (Make note of the special BUILTIN group for assigning groups on the local machine. - See Books Online for more info.)
Mixed
Offers the features of Integrated but can fall back to support clients that cannot establish trusted connections
Let's face it - this mode may expose you to the weaknesses of both modes. Tightening the security of both modes is a lot of work.
Now called 'SQL Server and Windows NT' mode
Same deal - use with caution. Why use a weak security model if you don't have to?
Bottom line: If you can get away with 'Windows NT only' mode, then use it.
Logging-in is only the first step. Once a user logs in, he or she must access the individual databases. For this, an entry must exist in the sysusers table for each database for that user. Keep a close eye on that “guest” account in your databases and make sure you don't inadvertently give someone access to a database.
=========================================================================
Brute-Force Attack:
Most databases have some default and well-known passwords. Moreover, system administrator accounts can not be changed in many of the commercial databases. “sa” for SQL server and SYBASE, “sys” for ORACLE can not be renamed. There is no password lockout available for SQL server. SQL server does not require a strong password. Due to this facts, it is possible to launch brute-force password attacks against the database server with nothing to prevent us from patiently and persistently trying to break into the server at the highest level access.
My personnel choice is “sqlbf” from packetstorm.securify.com Once you get the administrative password, the game starts.
===========================================================
System Compromise Using Extended Procedures: (SQL 6.5)
Most database systems have powerful features that, while convenient for DBAs, are also potential backdoors into a database server's host operating system.
Most of the time, “sa” account has no password thanks to lazy or busy system admins. Anyway once we get the password, our ultimate aim is compromising the underlying operating system, once again most of the time it is a NT box.
By logging in as “sa”, an intruder has use of the “extended stored procedures” “xp_cmdshell”, which allows a SQL Server user to run an operating system command as if that person was running a command prompt at the server console. As an example, the following SQL command will add user foo with password bar into windows NT account and then to the administrators group.
Xp_cmdshell 'net user foo bar /ADD'
Xp_cmdshell 'net localgroup /ADD Administrators foo'
Now, the unscrupulous intruder is a NT administrator, lets hope this box is not a domain controller. This simple attack works because the commands are submitted to the operating system using the NT account under which the SQL server runs under.By default this is the “local system” account which is the most powerful account on the local NT system.
Another good way of compromising NT account is, as every one of us well knows, reading the sam._ file under winnt/repair/sam._ and cracking this hashed password file with our favorite tool LophtCrack.
To do this, we will use the extended stored procedure, xp_regread out of registry. Below is the function do attain sam._ file
Xp_regread 'HKEY_LOCAL_MACHINE','SECURITY\SAM\Domains\Account ','F'
Note that reading the passwords out of registry is something even the local NT administrator can not do. SQL server allows us to do this because SQL server by default runs using the “local system” account.
I suppose all you guys are asking for a tool performing all this things for us. Luckily we have a tool performing this activity for we guys. SQLPOKE and I believe you guys can find it from packetstorm tools factory. Take a check.
=============================================================
Local Password Compromise: (SQL 6.5 & 7.0)
SA password is stored in clear text within the registry.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\MSSQLServer\SQLEW\Registered Server\SQL 6.5.
Moreover
-Changing the password leaves residual text from the previous passwords in the registry
-Changing security mode does not remove password. Entire password is left with the exception of the first letter:
•example: “nopassword” - “opassword”
For MS SQL 7.0, we have another vulnerability. in the encryption used to conceal the password and login ID of a registered SQL Server user in Enterprise Manager for Microsoft SQL Server 7.0. When registering a new SQL Server in the Enterprise Manager or editing the SQL
Server registration properties, the login name that will be used by the Enterprise Manager for the connection must be specified. If a SQL Server login name is used instead of a Widows Domain user name and the 'Always prompt for login name and password' checkbox is not set, the login ID and password are weakly encrypted and stored in the registry.
When a DBA (database administrator) logs into a workstation with a roaming
profile, the login ID and password are stored in a registry key. This information is stored as the file NTUSER.DAT (for Windows NT) or USER.DAT (for Windows 95 or Windows 98) when the user logs off. An attacker can open this file in a text editor to view the DBA login ID and password encrypted. An attacker can reverse this encryption to gain access to the DBA login ID
and password.
Remote and local attackers who acquire the system administrator password
have full control over the database server software as well as full access to the content and integrity of the database.
The encryption used to conceal the password and login ID of a registered SQL
Server user in Enterprise Manager for SQL Server 7.0 can be reversed. The encryption scheme used is an alphabetic substitution where each Unicode character in the password is XOR'ed with a two byte value according to its position in the string. If the 'Always prompt for login name and password' checkbox is not set when registering a SQL Server, the login ID and password
is weakly encrypted and stored in the following registry key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\MSSQLServer\SQLEW\Registered Server X.
By design, the HKEY_CURRENT_USER registry hive is meant to be available only
to the currently logged on user. That is, when a different Windows NT user logs onto the system, a different copy of the HKEY_CURRENT_USER registry hive is loaded. In practice, the HKEY_CURRENT_USER registry hive is saved locally as the file NTUSER.DAT or USER.DAT when a user logs off. This registry hive can be opened in Notepad and the encrypted login ID and
password can be easily located. If the DBA has a roaming profile, the NTUSER.DAT file will be saved on every workstation the DBA logs into.
Conclusion:
All the information i have given you has been widely used in wild. However what i tried to do was just to collect all these information together as to check the security of our famous SQL 6.5 & 7.0 Whenever i encounter a SQL server during my pen-tests, i do check for these vulnerabilities and most of the time one of these works.
I hope that, what i written was helped you in some way. Thanks for reading it, please continue to support me as i continue to release this sortta papers. If you wanna learn more, please check the mentioned people's web sites for more details and you can even write to me.
Peace in mind
Watch your servers in wild