lytithwyn/owper

Properly detect blank passwords

Opened this issue · 3 comments

It looks like we aren't properly detecting blank passwords. We are looking to see if the hash length is 0, which works if we set it that way. Some passwords are blank, yet have a proper length of 16. My guess is that these are passwords that have been cleared in Windows. We need to look to see if there is/are a certain hash(es) that denote(s) a blank password.

Dunno if this'll help or not but I found this in the code for chntpw.c:

if (stat) {
  printf("RID: %04x, Username: <%s>%s\n",
      rid, username,  ( !rid ? ", account locked?" : (ntpw_len < 16) ? ", *BLANK password*" : "")  );
    return(username);
}

// ....

if (ntpw_len < 16) {
  printf("** This user _probably_ has a BLANK password! (Unable to change it, let NT do it instead :)\n\n");
  return(0);
}

See line 273-288 at http://read.pudn.com/downloads/sourcecode/hack/895/chntpw.c__.htm

That's what we're doing at samUser.cpp:49. It may have something to do with the fact that I'm only calling it blank if BOTH lengths are 0, but this is a minor issue. We'll worry about this later.

Turns out chntpw has this same problem. I can confirm it happens when a password is set in windows, then cleared in windows. There is still an encrypted hash stored in the registry for these users.

The encrypted versions of "blank" password hashes are not all the same, but we're working on getting a simple syskey implementation going (based on bkhive and samdump2) that will allow us to decrypt the hashes. Once unencrypted, the blank password hashes are indeed the same. We're working on all this in the emptypass branch, which will eventually be merged into master and go away once we git it stable.

Of course, for this to work we'll have to start loading the system hive as well as the sam. It would be a reasonable thing to allow the user to proceed with only the sam hive, since this will still work. We'll just show a warning that some passwords that show being set may actually be blank.