131

Following my answer. If I can list contents of a password-protected ZIP file, check the file types of each stored file and even replace it with another one, without actually knowing the password, then should ZIP files be still treated as secure?

This is completely insecure in terms of social engineering / influence etc.

I can hijack (intercept) someone else's file (password-protected ZIP file) and I can replace one of the files it contains, with my one (fake, virus) without knowing the password. Replaced file will remain unencrypted, not password-protected inside the ZIP, but other files won't be modified.

If a victim unpacks a password-protected archive, extracting program will ask for the password only once, not every time per each file. So end user will not see the difference -- whether the program does not ask for a password, because it already knows it (original file) or because the file being extracted doesn't need a password (file modified by me). This way, I can inject something really bad into a password-protected ZIP file, without knowing its password and count on the receiver assuming the file is unmodified.

Am I missing something or is this really wrong? What can we say about the security terms of a solution, if password is not required to introduce any modification in a password-protected file?

trejder
  • 3,619
  • 5
  • 24
  • 35
  • 9
    It is in the design of the ZIP archives that they're only _containers_. Encryption is done on the files not the container itself, so confidentiality & integrity are still granted for the _files_ inside. The ZIP archive itself isn't password-protected, but the files inside are. Actually, RAR files behave almost the same way, except that they give you the option encrypt the file list. You _can_ add fake files to a RAR file (not through WinRAR), but if the list of files is encrypted, then you cannot modify it, therefor the application opening it won't be able to list the fake file. – Adi May 13 '13 at 09:10
  • 7
    Upon further reading, I've learned that ZIP uses AES in CBC mode, which [doesn't really grant integrity](http://security.stackexchange.com/a/9446/). Although it's not that easy to modify the contents of your files, a persistent threat will eventually be able do that. **Please note**: The integrity problem is not, of course, that the files can be replaced. IMHO, getting your files replace and tampered with is alright, but not being able to detect such tampering _is_ the integrity problem. – Adi May 13 '13 at 10:17
  • 16
    Could you zip your files (without password) and then zip that archive again (with password)? That way you would only have a single file that's password protected, and as you cannot access that one, you cannot modify the inner zip. – poke May 14 '13 at 01:30
  • 2
    @poke: Quite interesting idea! :] – trejder May 14 '13 at 08:43
  • 1
    Yes you can, WinZip calls this "double zipping": http://kb.winzip.com/kb/entry/147/ – marcovtwout Jun 16 '15 at 07:59
  • 3
    Be careful of archive programs that unzip files to a temporary folder and then leave it there. 7zip does this and refuses to fix it. If you use 7zip, your encrypted files are NOT secure because they will inevitably be left unencrypted in a temporary folder somewhere. – B T Oct 06 '15 at 23:03
  • Why not just check the integrity with a checksum e.g. sha, md5? – logical x 2 Feb 08 '18 at 07:48

11 Answers11

72

To answer this, there needs to be a better definition of "secure" and/or "safe". It's always got to be defined in light of the purpose of the protection and the risk to the system. There's no one size fits all here, what's "safe enough" for one system, may be abysmally weak on another. And what's "safe enough" on another may be cost prohibitive or down right impractical in a different case.

So, taking the typical concerns one by one:

  • Confidentiality - marginal at best. Confidentiality is usually rated in terms of how long it will take to gain access to the protected material. I may be able to change the zip file, but as a hacker it'll take me some amount of time either crack the password or brute force it. Not a lot of time, passwords are one of the weaker protections, and given the way zip files are often shared, social engineering one's way to the password is usually not hard.

  • Integrity - nope - as the asker points out - it's easy to change the package and make it look legitimate.

  • Availability - generally not applicable to this sort of security control - this usually refers to the risk of making a service unavailable - the data storing/packaging usually doesn't affect availability one way or the other.

  • Non repudiation - nope, no protection - anyone can modify the package, so anyone contributing to it has probable deniability.

The trick is - how much better do you want to get? Encrypted email is an option - as a better protection. Although it poses it's own connectivity concerns. And there's many better ways to encrypt data - but the better options also involve key distribution challenges that can add time and cost concerns.

As a quick way to package and share some data that you don't want to make completely public - it's better than nothing, and it's sometimes the only common denominator you can work out. For anything high-risk, I'd find a better option.

bethlakshmi
  • 11,656
  • 1
  • 28
  • 59
  • 1
    What is weak about a strong password (such as 14 random characters) combined with a strong encryption method (such as AES-256)? – marcovtwout Jun 15 '15 at 15:03
  • I'm not clear what perspective your question is coming from? This person is specifically asking about the method of password protection as it relates to zip files and the problems were outlined pretty well in the question - in this instance, no matter how big or random your password, the zip file password lock doesn't lock much of anything. In *general* passwords are pretty weak - they are readily shared, and require that both sides know them (they are a shared secret) - so there's always the risk that someone else knows the password. So non-repudiation is a no-go with any password. – bethlakshmi Jun 15 '15 at 21:07
  • 4
    I am talking purely about Confidentiality, and not about Integrity or any of the other values you correctly pointed out in the light of this question. You note "passwords are one of the weaker protections", and I simply want to point out that this statement is very relative. It all depends on the strength of the password and the encryption method, but also the way this shared secret is shared. – marcovtwout Jun 16 '15 at 08:16
  • 2
    @bethlakshmi "probable deniability" -- did you mean plausible deniability? – ScottJ Oct 05 '16 at 19:51
  • 1
    FYI for those not familiar with the confidentiality/integrity/availability/non-repudiation terms wikipedia has a laymans description here: https://en.wikipedia.org/wiki/Information_security#Confidentiality (personally i found the bullets in this answer to sound like a foreign language) – Trevor Boyd Smith Sep 17 '19 at 15:20
  • to add "integrity"... couldn't you just provide a checksum file to the encrypted archive generated via `sha256sum`, yes/no? – Trevor Boyd Smith Sep 17 '19 at 15:21
47

The password is meant to ensure confidentiality, not integrity or authenticity.

This is one of those cases where security is limited by usability and human intent. The archive manager has no way of telling whether or not the file you modified was meant to be encrypted in the first place. Essentially this is a social engineering attack, in that you tricked the user into believing that the original file was in place. However, the real security vulnerability would be that you had read/write access to a sensitive archive in the first place.

As far as mitigation goes, there are a few ways to increase security:

  • Use an archive format that supports filename encryption (e.g. 7Zip, RAR)
  • Sign the archive with a private key, e.g. via GPG.
hakre
  • 189
  • 1
  • 5
Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • 2
    or use tar.gz :) – Danubian Sailor May 13 '13 at 13:13
  • 2
    On Windows? :] If I'd were on Linux I wouldn't use ZIPs at all! Beside, the question is, whether password-protected ZIP files can be considered safe, not whether there are more secure archives. Because there are and I'm pretty sure about that... – trejder May 13 '13 at 13:22
  • 5
    Yes, tar.gz cannot be used on Windows, especially if you do not understand what 7zip, WinRar or gazillions of other softwares are! :P I guess you are browsing on an IE? :D – Sunny R Gupta May 13 '13 at 16:04
  • 2
    Dear God, no! :] I was talking about _native_ support, at system level. And rather to say that `.tar.gz` format is for Linux (Unix) what `.zip` is for Windows. But then again, it is only a side note, as the question is not, what archive format should I use, only is `.zip` secure enough? – trejder May 13 '13 at 18:27
  • 1
    What exactly does native mean to you? On Unix, tar is just a program; zip and unzip are just programs too. There is no real difference. – poke May 14 '13 at 01:28
  • 3
    I don't know about Unix and Linux (don't use them), but AFAIK you can work with archives directly from command-line, as these are either system components or external programs that ships with nearly every distro (not mentioning minimal ones). You install pure system and you have them, right? Try to achieve the same on Windows? Without manually installing 3rd-party programs you won't be able to use archives at all. Shell support for `.zip` was added in Windows XP. There is no shell and no command-line support at all for `tar`, `rar`, `gzip` on others on Windows. That's what I call _native_. – trejder May 14 '13 at 08:48
  • 1
    If both receiving and ending parties have PGP and have their keys ready, I'd rather **encrypt** the zip file with PGP than just **sign** the zip (in the first case, impossible to know the whole content (file list, etc). In the 2nd, you just can check whether the zip file was altered or not... zip password protection is too weak to ensure the content wasn't accessed) – Olivier Dulac May 15 '13 at 08:42
  • 1
    I'd like to put a big question mark behind this supposed `usability and human intent`. As a naive user I would really expect that if I encrypt a ZIP file full of stuff that *all* of this stuff is encrypted. Including file names and extensions. And why on earth would someone *who doesn't know the password* ever need to add files to such an archive? I honestly can't think of any use case where this might be needed... – fgysin Mar 31 '16 at 09:06
  • @fgysin Well yeah, that's why nobody relies on encrypted zip files. – Navin Oct 06 '16 at 01:30
  • @fgysin The same naive user would expect that *all* of an encrypted mail is encrypted. Including subject and sender name. - Maybe we should make our users much more aware of such limits of various encryptions ... – Hagen von Eitzen May 28 '17 at 04:43
29

No. To create an encrypted file (insecurely since the password is echoed):

$ cd -- "$(mktemp --directory)"
$ echo secret > 1.txt
$ echo super secret > 2.txt
$ zip -e -P dIg4BuOTFh secret.zip 1.txt 2.txt
  adding: 1.txt (stored 0%)
  adding: 2.txt (stored 0%)

To find out which files are included:

$ unzip -l secret.zip
Archive:  secret.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        7  2013-05-14 10:15   1.txt
       13  2013-05-14 10:14   2.txt
---------                     -------
       20                     2 files

To overwrite a file with fake data without knowing the password:

$ echo lie > 2.txt
$ zip -u secret.zip 2.txt
updating: 2.txt (stored 0%)

Verify:

$ unzip -o -P dIg4BuOTFh secret.zip
Archive:  secret.zip
 extracting: 1.txt                   
 extracting: 2.txt     
$ cat 2.txt
lie

man zip doesn't mention this caveat in the description of the -e option, but the following is from the documentation of -P:

(And where security is truly important, use strong encryption such as Pretty Good Privacy instead of the relatively weak standard encryption provided by zipfile utilities.)

Known weak encryption should be removed from the utility to avoid a false sense of security, but that's another story.

l0b0
  • 3,011
  • 21
  • 29
  • Why 2.txt is more secured than 1.txt ? – 0x90 May 17 '13 at 06:40
  • 3
    It's not. I just wanted to use different contents for the two files :) – l0b0 May 17 '13 at 10:12
  • Known weak security is unfortunately necessary for interoperability because there are plenty of zip archives out there using the known-weak scheme, and other systems that support only the known-weak scheme. – user Mar 31 '16 at 09:52
  • The fake data stuff could be a concern, however this can be mitigated by simply including an MD5 along with the file (which _could_ have collisions but is unlikely enough to cover most bases) – Matt Fletcher Jul 30 '18 at 08:47
13

It's not secure in the sense that you can't depend on the integrity of the zip file. Confidentiality is still in order since you can't access the file contents (only the file-names).

This drawback in zip has been discussed before, personally I always use rar just because of this problem. Another workaround would be signing the zip file with PGP .

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • 3
    If both receiving and ending parties have PGP and have their keys ready, I'd rather **encrypt** the zip file with PGP than just **sign** the zip (in the first case, impossible to know the whole content (file list, etc). In the 2nd, you just can check whether the zip file was altered or not... zip password protection is too weak to ensure the content wasn't accessed) – Olivier Dulac May 15 '13 at 08:41
  • @Lucas, do you mean that if I zipped an exe file and password protect it, a virus could *still* modify the contained exe file by adding it's payload to it without possessing the password? – Pacerier Apr 27 '14 at 20:30
  • No I mean you can't validate if confidentiality was broken or not. – Lucas Kauffman Apr 27 '14 at 20:35
  • Sry do you mind explaining elaborating on *"can't validate if confidentiality was broken or not"*? – Pacerier Apr 27 '14 at 20:54
  • chaning something is integrity, being able to view something is confidentiality. – Lucas Kauffman Apr 27 '14 at 21:01
  • In some use cases, even file names are considered confidential and being able to read them is concerning. – Mr.Hunt Aug 07 '22 at 03:12
10

In addition to the risks you have already pointed, IMHO one of the biggest problems with compression tools is related to the use of temporary folders to store the uncompressed files. As the input files can be of arbitrary size, the uncompressed output files might not fit in RAM. A temporary output folder (often the OS's default) is used.

So it does not matter how strong the encryption algorithm is if you forget to properly shred the temporary folders each time you unzip a psw-protected file. Most tools do not automatically clean the output directory nor warn the user about it. Same thing when compressing: you should make sure to shred the original file.

Mister Smith
  • 433
  • 4
  • 10
4

If I were to use the a general definition fo Secure to mean that it enforces Privacy, Authentication, Integrity and Non-Repudiation, I would say its is not secure on a number of counts. But as the password protection on an Encrypted ZIP file intends to only provide Privacy (disallowing the viewing of the content of a file except by intended parties) I would say that it does do its job.

Gene M.
  • 184
  • 8
2

The official .ZIP format specification does allow for hiding the list of file names (but not number of files), as well as hiding metadata such as the original file size and CRC of the original file. But you can't use WinZip or Info-Zip to do that. Additionally, integrity in the official .ZIP specification is provided through the use of one or more digital signatures in addition to the encryption. My personal recommendation, though, is to avoid passwords, and instead use public keys. Key derivation functions are constantly getting faster, and I don't believe any vendor has even tried to keep up.

TOM
  • 21
  • 1
1

If you have an unencrypted version of one of the files in a password protected zip you can use a known-plaintext attack to gain the password for all of the other files.

Rod MacPherson
  • 1,067
  • 7
  • 11
  • How is a known plaintext attack supposed to help? Zip doesn't use a brain-dead algorithm, so it's resistant to known plaintext attacks. – Gilles 'SO- stop being evil' May 13 '13 at 22:03
  • 2
    http://www.elcomsoft.com/help/archpr/index.html?known_plaintext_attack_(zip).html Sorry, I probably should have included a link, but this was mentioned here on this discussion board just a few days ago. Google also is very efficient at bringing up this answer. – Rod MacPherson May 15 '13 at 20:55
  • 2
    Ah, thank you. This contradicts [Adnan's assertion](http://security.stackexchange.com/questions/35818/are-password-protected-zip-files-secure/35854?noredirect=1#comment55783_35818) that zip uses AES-CBC. Has the format changed since that vulnerability was discovered? Which algorithms do the various zip implementations out there support? – Gilles 'SO- stop being evil' May 15 '13 at 21:42
  • 2
    Seems like Elcomsoft refers to a very old zip implementation. Looking a Winzip documentation, they now use AES and PBKDF2. http://kb.winzip.com/help/winzip/help_encryption.htm – northox May 28 '13 at 15:59
1

So the bottom line is, unless there is a vulnerability or back door in the encrypting code, it is as secure as your pass phrase is resistant to brute force attacks. There are various sites on the Internet where you can prototype the scheme you intend to use, to check roughly how long it would take to crack. (Do not use WHAT you intend to use)

Anything anyone can gain physical access to, is crackable, given enough time. However, you can have practical security if the cost and or time required to gain access to the information exceeds its likely value. Unless it is something like financial information, there is often a big difference between what is valuable to a hacker, and what is valuable to you. If the name of your file inside the zip is Attachment_1, and the e-mail's unencrypted contents does not describe the attachment's contents, it doesn't give an hacker much to go on. A hacker is not likely to be willing to spend much time, and certainly not money, to gain access to something that doesn't have a convincingly high probability of containing something of value to him.

1

Not everything that is password protected can be hacked by brute force attacks. However, zip files can be cracked by brute force. Other systems have checks in place, like for example, lock out after three attempts, passkey verifications etc.

  • 1
    a lock out from a compressed file? how should that work in an offline-attack scenario? dont you need a server-like online-attack scenario for that? and why do you say that zip files can be cracked by brute force? that is only true when the password is strong enough. in your logic, even the strongest encryption method like the ones you mention can be "brute force" cracked. You just need a lot of time either way. – phil294 Aug 01 '18 at 07:19
-2

I have heard about ways bywhich password protected zipped files can be cracked. Usually by brute-force attacks. So in short they are not much secure for secret & confidential data.

Faizan
  • 13
  • 1