Re: Cracking the code?
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 [EMAIL PROTECTED] > > -- 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 [EMAIL PROTECTED]
Re: Cracking the code?
-- >> 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? > A) yes it is vulnerable. B) none - it would take no > time to reverse engineer the entire algorithm out of > the executable. C) yes of course. D) just how bad this > is. Concerning B: If the implementors of the system had half a brain, they probably did something reasonable to generate the hex, such as hashing the password with a large secret, in which case no number of password hex pairs will reveal the algorithm. By and large, security systems that are covered by an NDA are covered by an NDA because they are not very good, and the seller of the system intends to send anyone to jail who widely publicizes the fact that they are not very good. Approach with care. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG MGjeTFQKB0Wa89CvalWg8qz/BAWRAwDEUL0m4Kkn 4VpuVXjmJfOnK1OLnn3wsm24Y9ES8GObzFkOVY4XV - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Cracking the code?
the hex value stored is perhaps a hash, or even better, a salted hash, or even better, a keyed salted hash which is then hex-encoded. any discussion of unix password cracking will describe the first two. (i think even the original doug mcilroy paper) all are vulnerable to dictionary and brute force attacks. an unsalted hash also reveals what two users have the same password as their hashes are the same. yes, you could also precompute hash values instead of using attacks which enumerate the values and their hashes. if the hash is sent to a counterparty to authenticate the user (to make unnecessary their typing a password) it has the same protective power as a plaintext password. if you have the hash, you can pretend to be the user in any situation which accepts the hash as an authenticator. the only value of such a hash is to obscure the password and to make less likely that someone with the hash can take advantage of the user using the same plaintext password in other circumstances. this is the main reason why static authenticators such as passwords should generally not be reused, or, for that matter, used at all for high value asset protection. On Sat, Mar 03, 2007 at 04:09:36AM -0800, 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. > > 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 [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Cracking the code?
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? A) yes it is vulnerable. B) none - it would take no time to reverse engineer the entire algorithm out of the executable. C) yes of course. D) just how bad this is. Ruptor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Cracking the code?
On Sat, Mar 03, 2007 at 04:09:36AM -0800, Allen wrote: > On recent consulting gig, I came across what I think is a > potential vulnerability and wanted to see how crazy my thinking is. > If you are not a security consultant hired to find and close this type of vulnerability, and don't want to follow in the footsteps of Randal L. Schwartz, it is sadly best to stay ignorant of such matters... -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Cracking the code?
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. 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 [EMAIL PROTECTED]
