Cracking the code?

[Ben Laurie]

Allen wrote:
> Hi gang,
> 
> On recent consulting gig, I came across what I think is a potential
> vulnerability and wanted to see how crazy my thinking is.
> 
> Without mentioning the exact place or piece of software because of NDAs,
> here is the basic scenario.
> 
> The tool stores the hex version of the remote access password in a field
> that is visible to the end user. The default setting of the software is
> that if you enter ASCII into the field, it will calculate the hex
> version and display it. At this site the sys admins have decided that
> this is not a user settable field so once set the user can not change it
> except with the help of an admin. There is also no policy in place to
> require periodic password changes.
> 
> Also every user in the entire enterprise has this field visible in their
> LDAP address information that anyone in the company can access at any
> time. The address info also contains the user name for logging onto the
> network. The password for remote access appears to be the same as the
> password for logging onto the machine even when it it not connected to
> the domain.
> 
> Next, trial versions of the software are available that still have the
> default setting where the user can enter any password and the hex value
> will be shown. As to the password algorithm itself, I don't know what it
> is. I don't know if it uses an IV that changes for every password that
> is entered, but that would be easy to check with the trial version. What
> research I've done says that it is derived from AES128 and it is a fixed
> field length. There is more than a bit of security by obscurity at play
> here.
> 
> So it seems to me this is vulnerable to a know text attack: i.e., enter
> "known password 1" get back "hex value 1", etc. By hand it would take a
> while to build a list of equivalences, but I assume that a clever perl
> hacker, which I'm not, could code a widget that would automate this,
> taking a common dictionary such as from Cain & Abel, John the Ripper or
> some such, and fairly quickly build a list of password/hex pairs. With
> this list in hand an insider bent on industrial espionage could find the
> weak passwords of sys admins and logon as them and do whatever nefarious
> deeds they wish.

That's a very dubious analysis. If the obfuscated password (I hesitate
to say encrypted in the face of an unknown algorithm) contains salt
(i.e. what you called an IV), then this technique will not work.

Of course, all good password obfuscators should include sufficient salt
that this attack doesn't work.

> 
> My questions are: A) is this as vulnerable as it seems at first blush?
> B) how many password/hex pairs would be needed to deduce the underlying
> algorithm?, C) If one could deduce the algorithm, could the attack be
> generalized so that it could be used against other enterprises that use
> the same software? (It is very(!) widely deployed), and D) am I missing
> something in my thinking?
> 
> Thanks,
> 
> Allen
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com