SQL 7.0 SA Password Attack
Reported December 9, 1999 by Kevork Belian
Using a simple strategy, it is possible at
times to change the SA (system administrator) password on SQL 7.0 servers.
MS SQL Server 7.0 uses the sysxlogins table in master.mdf to store login information. The
password field is of type varbinary(256). Executing "select name, convert(varchar(256),
password) from sysxlogins" will return the string equivalents of the passwords. What"s
intereseting is that passwords are stored as 16 byte values. So even passwords less than
16 bytes generate a 16 byte encrypted string. This fixed length string is located in a
fixed location in sysxlogins. If the password is more than 16 characters, the first 16
bytes of the encypted string are still located in the same place. So changing the password
becomes a matter of
a) finding a suitable and known encrypted string.
b) finding the offset of sysxlogins
c) locating the record of sa
d) replacing the password field.
As you would agree, these are trivial to do.
I would like to make some points:
- There is no extra information about the structure of SQL databases
involved (I have used what"s documented in Books Online).
- I have tested the program on installations with a small
login accounts: sysxlogins occupying less than 8th pages. But it"s easy to modify the
program to handle bigger numbers.
- An interseting thing happens when the password is more
characters. The first 16 encrypted bytes are stored in the same fixed
location. Changing these will change the password. Restoring the same 16 characters will
restore the greater-than-16-character password.
I have developed a
simple program that sets the password of sa to "temp". It can also restore the old
The program doesn"t decrypt the password, but rather changes it"s value. While this not
might seem an elegant solution, it boils down to the same result: you gain access to SQL
Server, create an administrative accout and restore the old sa password (by the way, the
encryption algorithm used is worth further investigation).
For a successful change of password, SQL Server should be stopped and you should have
read/write access to the data directory of SQL. This certainly restricts the exploit, but
other techniques can be utilized to bypass this limitation (I"m working on some and will
post them to the list as soon as I have results).
The program was intended as proof of concept and can be
utilized as an adminitrative tool to regain access to a SQL Server whose sa password is
Since the exploit happens while SQL Server is stopped,
the easiest way to defend your installation would be to restrict file access to DATA and
BACKUP directories to the account SQL Server is running under (usually the System
Account). I wouldn"t bet on the fact that ordinary users on the net cannot stop services
on NT. A SQL crash will certainly be an opportunity (In a previous post I have
demonstrated a technique to crash SQL Server remotely with Null bytes).
Microsoft is aware of this issue and
released the following comments on the Win2KSecAdvice mailing list.
"The scenario that"s described does work, but it
relies on several critical mistakes having already been made by the system administrator.
A SQL server that"s secured as recommended is not vulnerable this attack. Here"s some
* By default, SQL files and folders are not shared. If the
were left at the defaults, the attacker would require the ability to
interactively log onto the SQL server in order to make the changes. The dangers associated
with letting normal users interactively log onto critical servers are pretty well known,
and we always recommend against allowing this to happen.
* SQL Server has two security modes: Windows NT
Authentication Mode and Mixed Mode. Windows NT Authentication Mode is strongly recommended
as the preferred operating mode, and in this mode the SA account can"t be used to log in,
regardless of the password.
An excellent reference for SQL Server security is available at
Discovered by Kevork Balian