Fix net rpc vampire, based on an *amazing* piece of debugging work by "Cooper S....
commitd104f6b53f36cd8e534714f1a3d02bfe32e25965
authorJeremy Allison <jra@samba.org>
Wed, 22 Oct 2008 20:21:13 +0000 (22 13:21 -0700)
committerKarolin Seeger <kseeger@samba.org>
Thu, 23 Oct 2008 07:15:00 +0000 (23 09:15 +0200)
tree3fee89ca2e1c2644bbe8c1bcd7ae3adbaa7c78cc
parentcdf23296ce7fe2bc060a4ef92517f8d7b30652aa
Fix net rpc vampire, based on an *amazing* piece of debugging work by "Cooper S. Blake" <the_analogkid@yahoo.com>.

"I believe I have found two bugs in the 3.2 code and one bug that
carried on to the 3.3 branch.  In the 3.2 code, everything is
located in the utils/net_rpc_samsync.c file.  What I believe is the
first problem is that fetch_database() is calling
samsync_fix_delta_array() with rid_crypt set to true, which means
the password hashes are unencrypted from the RID encryption.
However, I believe this call is redundant, and the corresponding
call for samdump has rid_crypt set to false.  So I think the
rid_crypt param should be false in fetch_database().

If you follow the code, it makes its way to sam_account_from_delta()
where the password hashes are decrypted a second time by calling
sam_pwd_hash().  I believe this is what is scrambling my passwords.

These methods were refactored somewhere in the 3.3 branch.  Now the
net_rpc_samsync.c class calls rpc_vampire_internals, which calls
libnet/libnet_samsync.c, which calls samsync_fix_delta_array() with
rid_crypt always set to false.  I think that's correct.  But the
second bug has carried through in the sam_account_from_delta()
function:

 208         if (memcmp(r->ntpassword.hash, zero_buf, 16) != 0) {
 209                 sam_pwd_hash(r->rid, r->ntpassword.hash, lm_passwd, 0);
 210                 pdb_set_lanman_passwd(account, lm_passwd, PDB_CHANGED);
 211         }
 212
 213         if (memcmp(r->lmpassword.hash, zero_buf, 16) != 0) {
 214                 sam_pwd_hash(r->rid, r->lmpassword.hash, nt_passwd, 0);
 215                 pdb_set_nt_passwd(account, nt_passwd, PDB_CHANGED);

If you look closely you'll see that the nt hash is going into the
lm_passwd variable and the decrypted value is being set in the lanman
hash, and the lanman hash is being decrypted and put into the nt hash
field.  So the LanMan and NT hashes look like they're being put in
the opposite fields."

Fix this by removing the rid_crypt parameter.
Jeremy.
(cherry picked from commit 3690f2d87549840b5408771d2596069ff1732fc5)
source/libnet/libnet_samsync.c
source/libnet/libnet_samsync_display.c
source/libnet/libnet_samsync_keytab.c
source/libnet/libnet_samsync_ldif.c
source/libnet/libnet_samsync_passdb.c