SQL SERVER Database Password Vulnerability

I tracked the login process of the SQL server database SERVER and found that password computing is very fragile. The weak password of the SQL SERVER database reflects two aspects:

1. Password Encryption Algorithm for network login

2. Password Encryption Algorithm stored in the database.

The following sections describe:

1. Password Encryption Algorithm for network login

SQL server network encryption passwords have always been very fragile. There are many comparison tables written on the Internet, but no specific algorithm processing is available. In fact, you can trace the SQL

SERVER login process, it is easy to obtain its decryption algorithm: Okay, let's demonstrate the assembly process:

Log on to the TDS package 4126a4 and run it.

004DE72E: generate a buffer of the corresponding size based on the received size field for the next copy.

004DE748 copy the LOGIN information from the received tds buf offset 8

004DE762: call sub_54E4D0: process the new copy buffer for parameter check.

Process the information in the TDS package in sequence. The climate of each field should have the length of each region, and compare the length with the offset 0x24.

The following Assembly Code implements the network encryption and decryption algorithm:

. Text: 0065C880 mov cl, [edi]

. Text: 0065C882 mov dl, cl

. Text: 0065C884 xor cl, 5

. Text: 0065C887 xor dl, 0AFh

. Text: 0065C88A shr dl, 4

. Text: 0065C88D shl cl, 4

. Text: 0065C890 or dl, cl

. Text: 0065C892 mov [edi], dl

. Text: 0065C894 inc edi

. Text: 0065C895 dec eax

. Text: 0065C896 jnz short loc_65C880

. Text: 0065C898 jmp loc_4DE7E6

It is easy to replace it with the C code. It can be seen that its encryption is simple, and there is no difference with the text, you can embed this code in SNIFFER to decrypt the sniffing TDS login package. In fact, 0XA5 is not the demarcation symbol of the specific SQL SERVER password field, the encryption algorithm will automatically encrypt the 0x0 value in the Two-byte form of ASC to 0xa5. However, if the dual-byte password is allowed, this is not the main reason for determining the demarcation.

Void sqlpasswd (char * enp, char * dnp)

{

Int I;

Unsigned char a1;

Unsigned char a2;

For (I = 0; I <128; I ++)

{

If (enp [I] = 0)

Break;

A1 = enp [I] ^ 5;

A1 = a1 <4;

A2 = enp [I] ^ 0xaf;

A2 = a2> 4;

Dnp [I] = a1 | a2;

}

Dnp [I] = 0;

Dnp [I + 1] = 0;

Wprintf (L "passwd: % s \ n", (const wchar_t *) dnp );

}

2. Password Encryption Algorithm stored in the database.

The encryption method for SQL SERVER passwords to database storage is also weird. The process is as follows:

After obtaining the password for network decryption

Call SQLSORT_14 at 005F9D5A to implement a buffer for converting to uppercase passwords for saving.

Then, at 004def6d, call a function to retrieve the encrypted PASSWORD in the database. The format is as follows:

2 bytes header 0x0100 (fixed)

4-byte HASH and secret KEY

HASH1 of 20 bytes

HASH2 of 20 bytes

Example:

Fx: 0x0100 1751857F DFDEC4FB618D8D18EBA5A27F615639F607CD46BE DFDEC4FB618D8D18EBA5A27F615639F607CD46BE

Fixed KEY HASH1 HASH2 supplement

Password: 123456

SQL first uses a 4-byte HASH and secret KEY to buffer the two passwords. One is in upper case and the other is in lower case. The encryption process is as follows:

CryptAcquireContextW (& hProv, NULL, L ("Microsoft Base Cryptographic Provider v1.0"), 1, 0xf0000000 );

CryptCreateHash (hProv, 0x8004, NULL, NULL, & hhash );

CryptCreateHash (hProv, 0x8004, NULL, NULL, & hHash );

005F9DFE:

CryptHashData (hhash, passwdbuf, 0x12, NULL); passwdbuf is a lower-case passwd buffer and then attaches a KEY.

HASH encryption for a string such as {, 0, 0, 85, 0x7F}

CryptHashData (hHash, PASSWDBUF, 0x12, NULL); PASSWDBUF is an upper-case passwd buffer, and then attaches a KEY

005F9E3E:

CryptGetHashParam (hhash, 2, & passwdout, & outlen, 0); Retrieve the encrypted value of passwdbuf in lower case.

CryptGetHashParam (hHash, 2, & PASSWDOUT, & OUTLEN, 0); obtain the encrypted value of passwdbuf in upper case.

These two values are the real PASSWORD encryption fields in the database.

Why is the above method fragile? In fact, the actual encryption length is only 20 bytes.

The security of the 40-bit HASH Value Combined by HASH1 of the lower-case password and HASH1 of the upper-case password is not as safe as a 20-bit HASH value. Because we all know the causal relationship between these two values,

More information is provided to the decrypted.

Like its algorithm, if HASH1 = HASH2, you can determine that the password is definitely not a letter, and only a password with digits and symbols is used, as shown in the HASH of the 123456 password obtained above, the two hashes are completely equal.

That is, when a letter is used, it knows the supplemented KEY, algorithm, and the relationship between two encrypted strings. The solution should be greatly simplified.

Of course, I have not studied encryption algorithms, but I feel that this encryption method is really insecure.