COMMAND
MS SQL
SYSTEMS AFFECTED
MS SQL 6.5, 7.0
PROBLEM
'mount ararat blossom' posted following. He released another
paper about SQL hacking. 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... Note that text in this
advisory is based on Chip Andrews's site regardirn sqlsecurity.
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.
- 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).
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.
Our 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
If the system has applied syskey, which is default in Win2k, then
this approach will be useless. You'd have to be able to upload
other tools, which you may or may not be able to do.
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.
Luckily we have a tool performing this activity for us. SQLPOKE
can be found 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.
- 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.
SOLUTION
Watch your servers in wild.