Full Disclosure mailing list archives
HOWTO: Crack Oracle Security like a peanut?
From: "Jeroen" <jeroen () isvet nl>
Date: Wed, 24 Aug 2005 21:59:01 +0200
Hi there, Recently, I found this posting: //--------------------------------------------------------------- Oracle's Password Transform Goals: - Authentication information ("encrypted password") shall be portable between machines with different character sets (ebcdic and ascii). - It should handle non-enlish languages including those that require 16 bits per character. - If a user has the same password on two databases, the authentication information will be the same on both machines. - It should be hard to tell if two users have the same password. - The password transform should be as hard to break as DES. The Algorithm: Convert user name and password to uppercase 'normal' form. Normal form uses 16 bits to represent each character, and it is independant of language and the computer's character set (acsii or ebcdic). Concatenate normalized user name and password. Pad result to multiple of 64 bits. Zero padding is better than some rolling xor algorithm, since the later produces redundant information that an attacker can use to check for the correctness of a guess. The result is called UPLONG. Compute cryptographic checksum of UPLONG using a known key and the cipher block chaining mode of DES. The known key is hex 0123456789ABCDEF. The idea is to extract 56 suitable bits from the password. The CBC64 (cipher block chain with 64 bit feedback path) checksum makes good use of the bits in a long password, and it speads out the redundant information that is present due to the fact that the 'normal' form uses 16 bits per character. The feedback path is 64 bits, not the standard 8 bits because it generates a more uniform distribution. See Alan T. Sherman's PhD thesis (MIT 1987) for justification. It isn't hard to invert the checksum we just found (the key is known), so now we hide this result by using it as the key to compute another checksum on the uplong array. That checksum will be used as the authentication parameter for the user. Note that DES has the property that given a matching block of plaintext and ciphertext is is still quite hard to find the key that mapped the plaintext into the ciphertext. We could use the first checksum as a key to encrypt a constant, but it seems safer to use non-constant data like the information in the UPLONG array. If nothing else this makes a dictionary attack harder. Note that an attacker must now solve two simultaneous equations for P: k1 = checksum( k0, U || P ) k2 = checksum( k1, U || P ) Where 'U || P' is the username concatenated with the password (U is known, P is not), k0 is the known key, k1 is the first checksum, and k2 is the value placed in the authentication table. Convert the second checksum value into a machine independent form. Since we are not short on characters, express it as a hex string. //--------------------------------------------------------------- I can reproduce the things mentioned for user/pass-combinations sized 64 bits. For larger combinations (> 64 bits ---> 2 or more 64 bits DES blocks) I can't figure out yet how things work. Have some of you guys 'n girls already played around with this description? And are you willing to share results? Thanks, Jeroen _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- HOWTO: Crack Oracle Security like a peanut? Jeroen (Aug 24)
- Re: HOWTO: Crack Oracle Security like a peanut? Simon Marechal (Aug 25)
- Re: HOWTO: Crack Oracle Security like a peanut? Fabien Kraemer (Aug 25)
- Re: HOWTO: Crack Oracle Security like a peanut? Simon Marechal (Aug 25)