SQL 7 SA Psw Attack - 18 Oct 1999 | ITPro Today: IT News, How-Tos, Trends, Case Studies, Career Tips, More

SQL 7.0 SA Password Attack
Reported December 9, 1999 by Kevork Belian

VERSIONS AFFECTED

SQL Server 7.0

DESCRIPTION

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 number of
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 than 16
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.

DEMONSTRATION

I have developed a simple program that sets the password of sa to "temp". It can also restore the old password.

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 lost.

DEFENSE

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).

VENDOR RESPONSE

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 additional information:

* By default, SQL files and folders are not shared. If the system
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
http://www.microsoft.com/sql/DeployAdmin/Security.doc.

Regards,
[email protected]"

CREDITS
Discovered by Kevork Balian

Comments

Plain text