[PEN-TEST] MS SQL HACKING

[mount ararat blossom <mountararatblossom () USA NET>]

Hi Folks,
here is some information for SQL server pen-testers.
i will also send a word-doc attached one.
cheers
mab-

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









____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1