Home page logo

pen-test logo Penetration Testing mailing list archives

From: "Bevers, Brian" <bbevers () C3COM COM>
Date: Wed, 15 Nov 2000 11:20:21 -0600

Try to not be so obvious in your plagerism next time....or at least give
credit where its due.


-----Original Message-----
From: mount ararat blossom [mailto:mountararatblossom () USA NET]
Sent: Monday, November 13, 2000 8:58 AM

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

                                                by Mount Ararat Blossom

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
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
as to use in our Pen-Tests.
Most of the time MS SQL server runs on TCP port 1433, if not configured to
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


SQL Server Network Protocol Libraries & Weaknesses

Named Pipes: 
·       Uses NT SMB ports (TCP 139, UDP 137,138) to communicate. These are
blocked in any decent firewall implementation, but that can be an advantage
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
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
·       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

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
encryption.  If you can't use either of those, then use IP Sockets, change
default TCP port to something else, and pray you don't get a packet sniffer
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
middle tier and the SQL server. This will remove some of the client
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
make use of its services. Check the following table for a description of
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
        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
        Users do not have to specify a separate login and password when they
to SQL Server 
        Passwords are never stored in applications and never transmitted in
text over the network 
        SQL Server gains the benefits of using NT to authenticate users and
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

        Only works on NT - Windows 95/98 installs do not support this mode
        Can integrate directly with NT groups for added ease of
(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
clients that cannot establish trusted connections 
        Let's face it - this mode may expose you to the weaknesses of both
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
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
the individual databases. For this, an entry must exist in the sysusers
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

Brute-Force Attack:
        Most databases have some default and well-known passwords. Moreover,
administrator accounts can not be changed in many of the commercial
"sa" for SQL server and SYBASE, "sys" for ORACLE can not be renamed. There
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
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
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
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
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
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.

-Changing the password leaves residual text from the previous passwords in
-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
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
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
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
have full control over the database server software as well as full access
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
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.

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
please continue to support me as i continue to release this sortta papers.
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

  By Date           By Thread  

Current thread:
  • [PEN-TEST] MS SQL HACKING mount ararat blossom (Nov 14)
    • <Possible follow-ups>
    • Re: [PEN-TEST] MS SQL HACKING Bevers, Brian (Nov 16)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]