Cracking MS SQL Server passwords

Made simple, that is


The inner workings of the undocumented pwdencrypt() hash function in Microsoft SQL Server have been revealed in a paper by security researcher David Litchfield of Next Generation Security Software (NGSS).

pwdencrypt() creates the user's password hash, which is stored in the main database. Litchfield begins by observing that when it's applied to the same input (foo), it will produce different hashes at different times, from which he reckons, assuming the worst, that the salt must be time sensitive in some way. Salting is normally done to prevent collisions and to strengthen hashes against dictionary attacks.

In other words, if a hash weren't salted, it would be easy to encrypt dictionary words using numerous hash functions and run the hashes against ones found in someone else's pass file. Obviously, the less we can determine about how the salt is generated, the stronger the hash becomes.

Unfortunately, we now know from Litchfield's simple experiment that SQL Server is using some manner of time-dependent scheme for salt generation. That's more than we ought to know, as we'll see.

His next observation is that the time function does not result in a truly random number, which is further bad news.

"The time () C function is called and used as a seed passed to the srand() function. srand() sets a start point to be used for producing a series of (pseudo) random numbers. Once srand is seeded the rand() function is called to produce a pseudo random number. This number is an integer; however SQL Server converts this to a short and sets it aside. Let's call this number SN1. The rand() function is called again producing another pseudo random integer which, again, is converted into a short. Let's call this number SN2. SN1 and SN2 are joined to produce an integer SN1:SN2 to produce a salt. This salt is then used to obscure the password."

The user's password is converted to unicode with the salt tacked on the end, and this is used to produce a hash with SHA. The same salt is added to the password when a user attempts to log in, and the resulting hash is compared to the one on record. If they match, access is granted.

Unfortunately, Litchfield says, "the password is then converted to its upper case form, the [same] salt tacked onto the end and another SHA hash is produced."

The hash is produced twice, against the case-sensitive password and again against the uppercase form. The uppercase 'version' is obviously a good deal easier to crack; and once we know it, finding the case-sensitive version is child's play. Indeed, there's little point in using case-sensitive passwords on your system if the crypto scheme is going to create hashes from the uppercase version, using the same salt, and then store them. Case-sensitive passwords are an improvement only so long as we're kept in the dark about their uppercase companions.

So with that in mind Litchfield ends his paper with a little command-line app which will run a dictionary attack to find the uppercase password for you. The rest of it, any fool can handle.

Thus security through obscurity fails again. ®

Related Link

NGSS paper


Other stories you might like

  • While the iPhone's repairability is in the toilet, at least the Apple Watch 7 is as fixable as the previous model

    Component swaps still a thing – for now

    Apple's seventh-gen Watch has managed to maintain its iFixit repairability rating on a par with the last model – unlike its smartphone sibling.

    The iFixit team found the slightly larger display of the latest Apple Watch a boon for removal via heat and a suction handle. Where the previous generation required a pair of flex folds in its display, the new version turned out to be simpler, with just the one flex.

    Things are also slightly different within the watch itself. Apple's diagnostic port has gone and the battery is larger. That equates to a slight increase in power (1.094Wh from 1.024Wh between 40mm S6 and 41mm S7) which, when paired with the slightly hungrier display, means battery life is pretty much unchanged.

    Continue reading
  • Better late than never: Microsoft rolls out a public preview of E2EE in Teams calls

    Only for one-to-one voice and video, mind

    Microsoft has finally kicked off the rollout of end-to-end-encryption (E2EE) in its Teams collaboration platform with a public preview of E2EE for one-to-one calls.

    It has been a while coming. The company made the promise of E2EE for some one-to-one Teams calls at its virtual Ignite shindig in March this year (https://www.theregister.com/2021/03/03/microsoft_ups_security/) and as 2021 nears its end appears to have delivered, in preview form at least.

    The company's rival in the conference calling space, Zoom, added E2EE for all a year ago, making Microsoft rather late to the privacy party. COO at Matrix-based communications and collaboration app Element, Amandine Le Pape, told The Register that the preview, although welcome, was "long overdue."

    Continue reading
  • Recycled Cobalt Strike key pairs show many crooks are using same cloned installation

    Researcher spots RSA tell-tale lurking in plain sight on VirusTotal

    Around 1,500 Cobalt Strike beacons uploaded to VirusTotal were reusing the same RSA keys from a cracked version of the software, according to a security researcher who pored through the malware repository.

    The discovery could make blue teams' lives easier by giving them a clue about whether or not Cobalt Strike traffic across their networks is a real threat or an action by an authorised red team carrying out a penetration test.

    Didier Stevens, the researcher with Belgian infosec firm NVISO who discovered that private Cobalt Strike keys are being widely reused by criminals, told The Register: "While fingerprinting Cobalt Strike servers on the internet, we noticed that some public keys appeared often. The fact that there is a reuse of public keys means that there is a reuse of private keys too: a public key and a private key are linked to each other."

    Continue reading

Biting the hand that feeds IT © 1998–2021