I created this zip file for a word guessing contest at ForumWarz, using a strong password, "5be890c219b0a837600e5fbb7ae8a2505be890c219b0a837600e5fbb7ae8a250" (not insanely strong but I guess that's strong enough for an average user). But it got cracked easily using AZPR with a brute-force attack.
It turned out that you can unzip the file with a much shorter password "tdc4Dl" too.
Surprised? I knew that zip protection was insecure but never thought it was that terrible.
This paper has some more information about zip encryption weaknesses, but I'm too lazy to read something that long. Maybe rhican can enlighten me :)
Monday, October 6, 2008
Winzip password collision
Subscribe to:
Post Comments (Atom)
5 comments:
lazy ass,
not really the best resource that .pdf, it doesn't explain anything for a passphrase collision infact it states it's near impossible. Are you sure the .zip file decrypts correctly? because the password verification field is only 16bits it's very possible that you think you have found a password where yes, winzip will accept it, the result is garbage. using AE2 it does not use a CRC on the decrypted file afaict.
Do not use .zip for "security"
summery of the .pdf:
-two encryption methods AE1 en AE2 vanaf 9.0
-meta data not encrypted
- attack: modify encryption method and intercept incorrectly decrypted
- interpreting filename/size
- changing filename (extension) and DoS stupid user,(whaa dubble click does not work)
- protocol roleback to AE1
- guess a CRC
- you can mix encrypted and unencrypted files in a .zip
-> you can replace all but 1 encrypted file by unencrypted
forgeries, and the user will still be prompted for a passphrase
and probably believes everything was encrypted and hence authentic
- files are encrypted independently. so instead of 1 encrypted file
you have X samples of encrypted files(and salts)
- CTR-mode counter always initialzed on zero
- keys for AES128 are (derived(passprhase)+random), random is weak,
when using 1 passphrase, decryption keys(for different files in the archive) will collide 2^32 (guess)
rhc
ah seems to be encrypted with AE1, and there is a 32bit CRC for a 4 byte value..
hence only 2^32 combinations are possible ...
basically you are bruteforcing a 32bit crc here ... in a seriously limited search space...
try the same two keys on a larger encrypted file.
i could investigate further but meh, out of time.
rhc
Heh you should investigate more :D
The most surprising thing was that unzipping the file using the "wrong" password still gave the right original file, which lead me to doubt the use of the password in the encryption. Was it not used at all, or could there be a hash collision somewhere during encryption?
there is no hash collision,
it's just a 32bit or 48 bit if you count the verification. AE1 with the crc, is just not suited to encrypt 4 byte files.
even des had 56 bits ...
it's not surprising that you have a good chance to find a collision.
try the same trick with a larger .zip file.
Personal messages at all today send?
Post a Comment