Vulnerability: Weak Password Encryption Scheme in MS SQL Server
Results 1 to 2 of 2

Thread: Vulnerability: Weak Password Encryption Scheme in MS SQL Server

  1. #1
    Fastest Thing Alive s0nIc's Avatar
    Join Date
    Sep 2001
    Location
    Sydney
    Posts
    1,584

    Exclamation Vulnerability: Weak Password Encryption Scheme in MS SQL Server

    MS SQL Server has two means of authenticating users. One uses Windows Authentication, and the other is the built-in SQL Authentication (which includes the 'sa' account). The passwords for the SQL Authentication are sent over the network using a very weak password encryption method. This was first mentioned in David Litchfield's paper "Threat Profiling Microsoft SQL Server".

    Details:


    ======
    In his paper, Mr. Litchfield states that the password is encrypted by first converting it into UNICODE and then performing a simple XOR operation. I quote directly from there:

    "Network Sniffing When a user connects to an SQL Server and authenticates as an SQL login, as opposed to a Windows NT/2000 user, their login name and password are sent across the network wire in what is tantamount to clear text. The 'encryption' scheme used to hide the password is a simple bitwise XOR operation. The password is converted to a wide character format, or UNICODE, and each byte XOR'd with a constant fixed value of 0xA5. Of course, this is easy to work out because every second byte of the 'encrypted' password on the wire 0xA5 and we know that the password is in UNICODE with every second byte being a NULL and when any number is XOR'd with 0 (or NULL) the result is the same: 0x41 xor 0x00 = 0x41, 0xA5 xor 0x00 = 0xA5."

    However, there is a slight inaccuracy in this description which we detail below. We have determined that the actual XORing method involves an additional step.
    Step 1: Password is converted into UNICODE Additional
    Step 2: For each byte of the password, the four Most Significant Bits (MSB) are swapped with the four Least Significant Bits (LSB)
    Step 3. This modified byte is then XORed with 0xA5.

    In the case of the alternating UNICODE 0x00, swapping the 4 MSB with the 4 LSB does not make a difference. But for the rest of the bytes, it does.


    Vendor Response:
    =============
    We did not contact the vendor, Microsoft as this is not exactly something new. However, we did contact Mr. Litchfield informing him about the slight modification to his original statement in his whitepaper. We did not receive any response from him.


    Suggested Workarounds:
    ==================
    There is nothing new to be done here, other than that which ought to be done when hardening an MS SQL Server. Do NOT use the SQL Server Authentication. This is strongly recommended by Microsoft.


    Note:
    ====
    This is more of an FYI Advisory. Just to keep things a bit more accurate.


    Other Information:
    ==============
    This advisory is available online at http://www.nii.co.in/vuln/sqlpass.html
    We have used this method in our free tool 'forceSQL' which guess SQL Server
    Passwords using both Dictionary and Brute Force attacks. This is available
    for free download at http://www.nii.co.in/tools.html
    You may read our Vulnerability Disclosure Policy at
    http://www.nii.co.in/vdp.html
    Other advisories are at http://www.nii.co.in/research.html


    K. K. Mookhey
    CTO,
    Network Intelligence India Pvt. Ltd.
    Tel: 91-22-2001530, 2006019
    Email: cto@nii.co.in
    Web: www.nii.co.in

  2. #2
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    Ain't this one like 6 months old? Not that it's not relevent since I don't think MS has "fixed" this yet...

    Ammo
    Credit travels up, blame travels down -- The Boss

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides