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 ...
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 ...
If you haven't already looked at it there's a couple of sources I'd recommend for this.
John the ripper with the community jumbo patch supports zip cracking. If you look at the supported modes there's some options (including the basic brute-force) for cracking zip passwords.
Elcomsoft have good zip crackers including guaranteed recovery under some ...
Do you remember "I love you" ?
Human curiosity often does the trick, unarchiving the zip and then executing the JS (via the windows scripting host that does not follow the same restrictions as a browsers JS engine)
There are more than enough people that do want to be sure they didn't miss a payment and will be cut off their mobile phone soon.
1 should not present any danger as long as the file is just saved somewhere and no attempts to open it with anything are made. If you view it even with a text editor, there's already a small danger of exploits.
In the case of 2 there are vulnerabilities and exploits, so there are dangers. Some examples of such possible scenarios:
Arbitrary file writes ...
No. There are two ways of zip encryption, a classic one, which is weaker, and a newer one based on AES.
In both cases the password is needed in order to decrypt the contents (i.e. it's not just UI, where you could be asked for a password without the program actually requiring it to read the file). So the process would involve breaking the password (which ...
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
Yes. The zip or rar file will be encrypted like all other files so that they are useless for you. The only protection is making backups to another physical storage.
This will help independantly of whether the files are in a password protected rar or zip format.
In direct meaning, you mentioned (extracting data), no. But keep in mind, however, that any program (or user), in any password-protected ZIP archive, can (without knowing the password):
browse list of files,
check file types1.
ZIP files can also be "broken" in the meaning, that you can overwrite exisiting, password-protected file, stored inside ZIP file, ...
A well known trick will be to disguise a PE or Executable program into an another file, a PDF or an archive for example.
Since most of people rely on the file's icon or extention, it works pretty well on common users.
For instance we (the sec folks) disguised a PE file as a pdf (which was actually a vbs file) named im_now_a_daddy_guyz!.pdf.vbs and send ...
ZIP files are encrypted with AES-256, and the key is derived using a slow key-derivation function (KDF), which makes bruteforce and dictionary attacks generally infeasible. There are no currently known ways to bypass the encryption.
First, there's no standard encoding for non-ASCII letters and several characters are not printable. At the very least you need a hex editor to view the information there. If you want to decipher the data format consult the APPNOTE.TXT.
E.g., if I simply make a zip file of a blank file named aaa.zip and encrypt with password abcd and print the file in ISO-...
The same user who clicks on the ZIP-file to extract the JS-file also clicks the JS-file.
This will launch the Windows Script Host to execute the script (it runs both JScript (JS and JSE) and VBScript (VBS and VBE)). The scripts run by WSH are not sandboxed in the way they would be in a browser.
Launching a JS in this manner is pretty much the same as ...
Symlinks are like shortcuts, so if you create a symlink pointing to /etc/passwd, when you open the symlink your O.S. will open /etc/passwd.
How the attack works?
1) Create a symlink in your computer to /etc/passwd
e.g.: ln -s /etc/passwd ./symlink.jpg
2) Create a zip with the symlink
e.g.: zip —symlinks -r photos.zip ./symlink.jpg
3) Upload the photos....
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 .
One area where ZIP files could present a risk to the application the zip bomb attack. this occurs where an archive is constructed in such a way that when it's opened it consumes a large quantity of space on the server potentially causing it to crash.
It might be possible to mitigate this issue by opening zip files on a dedicated filesystem and then ...
It depends on how the ZIP file is encrypted.
When you want to create a fully standard-compliant ZIP archive, then your only option for encryption is the ZipCrypto algorithm which is known to be seriously flawed.
However, many compression tools support a non-standard addition to the ZIP standard which allows to use different encryption algorithms, ...
You can also use this shell script.
echo "ZIP-JTR Decrypt Script";
if [ $# -ne 2 ]
echo "Usage $0 <zipfile> <wordlist>";
unzip -l $1
for i in $(john --wordlist=$2 --rules --stdout)
echo -ne "\rtrying \"$i\" "
unzip -o -P $i $1 ...
The ZIP format supports several variants of password-protection of a file.
The early password protection system in ZIP is known to be seriously flawed. However, later versions of the format provide far better protection, including support for stock encryption algorithms like AES to which no known attacks exist.
The author of the video appears to be using ...
It's using the original PKZIP 2.0 encryption (variously referred to as "traditional" or "legacy" encryption), described in section 6 of the .ZIP file format specification. It's based on using CRC32 to mix the password, a (hopefully) random seed, and the compressed file. It is not considered secure; at the very least, it has serious vulnerabilities to known-...
There are no security threat. At least not any that are specific to zip files.
The major concerns have already been outlined by other users. However, all of these are either not harmful to the application itself or not specific to zip files.
Zip Bomb attacks, as described by Rory McCune. These are only a concern if the files will be unpacked.
Inclusion of ...
Windows Script Host is an automation technology that provides scripting abilities. It is language-independent in that it can make use of different Active Scripting language engines.
By default, Windows interprets and runs JScript (.js and .jse files) and VBScript (.vbs and .vbe files).
Clicking a .js file will make wscript.exe interpret it and the script ...
No, nowadays zip files are protected by AES. This will hide all of the plaintext in a way that you can only recover it when you have the key. The only other thing you can see is the size of the plaintext as that is as good as identical to the size of the ciphertext.
Hexadecimals are just a readable representation of the bytes that make up the ciphertext. ...
At the OS level, a file whatever is its content or structure is nothing more than a sequence of bytes. That means that the sequence of bytes can be read, encrypted and written again (in a crypted version) regardless of whether it was originally a text file, a JPEG image, or a ZIP archive.
So yes, password protected files will be encrypted by the ransomware. ...
Unfortunately, not really.
What you must understand here is that we are not speaking of a file that "is there", access to the original contents is not actively being blocked by the zip software you are using. That would make password protection essentially useless, as another software could just show the file without asking for the password, right?
The Cyclic Redundancy Check (CRC) field is used to determine whether or not the file is decrypted correctly. Quoted from the original ZIP format specification:
After the header is decrypted, the last 1 or 2 bytes in Buffer SHOULD be the high-order word/byte of the CRC for the file being decrypted, stored in Intel low-byte/high-byte order. Versions of ...
In theory all of these places could be exploited. I am not going to go into specific exploits available as these change constantly with archive format and moving tech:
Initially downloading and saving the archived data (still packed)
It is unlikely but it is possible that your download manager / web browser does have some kind of exploit. You say the ...
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 ...
The problem with a zip is that you aren't really sure what's inside of them. You would need to unzip the contents, scan for virusses and then you know that there aren't any known virusses in them.
Second of all, when fileuploads are in use, you can only allow a certain amount of file extensions (white list rather than blacklist) and you need to verify that ...
There are different recovery suites available. Most of them implement these solutions:
Biham-Kocher attack (this attack is possible when you have part of the text)
Stay attack (also plaintext based)
Also this link (from which I got most of my information) suggests that if you used a recent winzip (which is suspected ...