记一次Zip Slip任意文件写漏洞

漏洞复现

第一次在测试中见到这个安全问题，故记录一下。(由于涉及到公司信息，故打码严重，只做简单复现)

首先发现到这里存在一个zip文件上传点:

于是我们构造特殊的zip压缩文件。

import zipfile
# the name of the zip file to generate
zf = zipfile.ZipFile('out.zip', 'w')
# the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'sec_test.txt'
#destination path of the file
zf.write(fname, '../../../../../../../../../../../../../../../../../../../../../../../../tmp/sec_test.tmp')

然后上传此压缩文件：

然后登陆服务器，发现tmp目录下出现我们上传的文件sec_test.tmp：

利用此漏洞，我们可以做到任意文件上传与覆盖。

漏洞原理分析

第一次看到这个漏洞，我想会不会所有的zip解压都会存在这个任意文件写的问题。

于是我将构造的zip放在kali下，想验证这个问题:

可以看到直接用unzip命令是无法实现目录穿越的，unzip会默认跳过…/。

也许是java解压文件的问题。于是我用默认的java.util.zip.*构造了一段解压文件的代码，尝试是否可以目录穿越。

import java.io. *;
import java.util.zip.*;
import java.util.Scanner;
public class Unzip {/*** @param srcPath zip源文件地址* @param outPath 解压到的目的地址* @throws IOException*/public static void decompressionFile(String srcPath, String outPath) throws IOException {//简单判断解压路径是否合法if (!new File(srcPath).isDirectory()) {//判断输出路径是否合法if (new File(outPath).isDirectory()) {if (!outPath.endsWith(File.separator)) {outPath += File.separator;}//zip读取压缩文件FileInputStream fileInputStream = new FileInputStream(srcPath);ZipInputStream zipInputStream = new ZipInputStream(fileInputStream);//解压文件decompressionFile(outPath, zipInputStream);//关闭流zipInputStream.close();fileInputStream.close();} else {throw new RuntimeException("输出路径不合法!");}} else {throw new RuntimeException("需要解压的文件不合法!");}}/*** ZipInputStream是逐个目录进行读取，所以只需要循环* @param outPath* @param inputStream* @throws IOException*/private static void decompressionFile(String outPath, ZipInputStream inputStream) throws IOException {//读取一个目录ZipEntry nextEntry = inputStream.getNextEntry();//不为空进入循环while (nextEntry != null) {String name = nextEntry.getName();File file = new File(outPath+name);//如果是目录，创建目录if (name.endsWith("/")) {file.mkdir();} else {//文件则写入具体的路径中FileOutputStream fileOutputStream = new FileOutputStream(file);BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(fileOutputStream);int n;byte[] bytes = new byte[1024];while ((n = inputStream.read(bytes)) != -1) {bufferedOutputStream.write(bytes, 0, n);}//关闭流bufferedOutputStream.close();fileOutputStream.close();}//关闭当前目录inputStream.closeEntry();//读取下一个目录，作为循环条件nextEntry = inputStream.getNextEntry();}}public static void main(String[] args) throws IOException {Scanner scan = new Scanner(System.in);System.out.println("请输入zip源文件路径：");String srcPath = scan.nextLine();System.out.println("请输入解压目的地址：");String outPath = scan.nextLine();decompressionFile(srcPath, outPath);}
}

然后运行：

发现成功实现解压目录穿越。

目录穿越的原因是：代码的第45行nextEntry.getName()函数是为了得到文件的路径。如果将其打印出来则是…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/tmp/sec_test.tmp。这里没有对获取到的路径进行校验，从而直接与outPath目录进行拼接，所以最终解压路径为/root/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/tmp/sec_test.tmp，也就是/tmp

扩展延申

Zip Slip是一个广泛存在的漏洞，除了Java语言，JavaScript，Ruby，.NET和Go都有此问题。

利用此漏洞有两个前提：

有恶意的压缩文件（这一点我们可以自己构造）
提取代码不会执行目录检查。
恶意的压缩文件一般包含…/目录，从而解压时会跳出当前目录。

提取代码一般会得到压缩文件中的文件目录，如果不对这些目录进行校验则会出现slip越问题。

目前snyk正在维护一个GitHub项目，用于列出所有已发现受Zip Slip影响的项目，及其修复情况、补丁版本。如果有需要，可以在上面检验是否正在使用包含Zip Slip漏洞的库。

参考文章一：Java之解压流（ZipInputStream）

一、ZipInputStream相对于ZipOutputStream而言，使用上面简单的多了，相对的，既然存在压缩流，就会存在，解压的方式。

二、解压文件，流的使用过程中也是很常用的，在读取文件，根据文件类型进行处理，这样，就可以做到，最低成本的数据传输了

三、解压例子

/*** 提供给用户使用的解压工具* @param srcPath* @param outPath* @throws IOException*/public static void decompressionFile(String srcPath, String outPath) throws IOException {//简单判断解压路径是否合法if (!new File(srcPath).isDirectory()) {//判断输出路径是否合法if (new File(outPath).isDirectory()) {if (!outPath.endsWith(File.separator)) {outPath += File.separator;}//zip读取压缩文件FileInputStream fileInputStream = new FileInputStream(srcPath);ZipInputStream zipInputStream = new ZipInputStream(fileInputStream);//解压文件decompressionFile(outPath, zipInputStream);//关闭流zipInputStream.close();fileInputStream.close();} else {throw new RuntimeException("输出路径不合法!");}} else {throw new RuntimeException("需要解压的文件不合法!");}}/*** ZipInputStream是逐个目录进行读取，所以只需要循环* @param outPath* @param inputStream* @throws IOException*/private static void decompressionFile(String outPath, ZipInputStream inputStream) throws IOException {//读取一个目录ZipEntry nextEntry = inputStream.getNextEntry();//不为空进入循环while (nextEntry != null) {String name = nextEntry.getName();File file = new File(outPath+name);//如果是目录，创建目录if (name.endsWith("/")) {file.mkdir();} else {//文件则写入具体的路径中FileOutputStream fileOutputStream = new FileOutputStream(file);BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(fileOutputStream);int n;byte[] bytes = new byte[1024];while ((n = inputStream.read(bytes)) != -1) {bufferedOutputStream.write(bytes, 0, n);}//关闭流bufferedOutputStream.close();fileOutputStream.close();}//关闭当前布姆inputStream.closeEntry();//读取下一个目录，作为循环条件nextEntry = inputStream.getNextEntry();}}

四、测试：

public static void main(String[] args) throws IOException {decompressionFile("D:\\srv.zip", "D:\\test");
}

参考文章二：Zip Slip Vulnerability

Zip Slip is a widespread arbitrary file overwrite critical vulnerability, which typically results in remote command execution. It was discovered and responsibly disclosed by the Snyk Security team ahead of a public disclosure on 5th June 2018, and affects thousands of projects, including ones from HP, Amazon, Apache, Pivotal and many more (CVEs and full list here). Of course, this type of vulnerability has existed before, but recently it has manifested itself in a much larger number of projects and libraries.

The vulnerability has been found in multiple ecosystems, including JavaScript, Ruby, .NET and Go, but is especially prevalent in Java, where there is no central library offering high level processing of archive (e.g. zip) files. The lack of such a library led to vulnerable code snippets being hand crafted and shared among developer communities such as StackOverflow.

The vulnerability is exploited using a specially crafted archive that holds directory traversal filenames (e.g. …/…/evil.sh). The Zip Slip vulnerability can affect numerous archive formats, including tar, jar, war, cpio, apk, rar and 7z. If you’d like the information on this page in a downloadable technical white paper, click the button below.

详情见：https://download.csdn.net/download/weixin_54626591/88279293
或者 Download Technical White Paper

Zip Slip is a form of directory traversal that can be exploited by extracting files from an archive. The premise of the directory traversal vulnerability is that an attacker can gain access to parts of the file system outside of the target folder in which they should reside. The attacker can then overwrite executable files and either invoke them remotely or wait for the system or user to call them, thus achieving remote command execution on the victim’s machine. The vulnerability can also cause damage by overwriting configuration files or other sensitive resources, and can be exploited on both client (user) machines and servers.

Exploitable Application Flow

The two parts required to exploit this vulnerability is a malicious archive and extraction code that does not perform validation checking. Let’s look through each of these in turn. First of all, the contents of the zip file needs to have one or more files that break out of the target directory when extracted. In the example below, we can see the contents of a zip file. It has two files, a good.sh file which would be extracted into the target directory and an evil.sh file which is trying to traverse up the directory tree to hit the root and then add a file into the tmp directory. When you attempt to cd … in the root directory, you still find yourself in the root directory, so a malicious path could contain many levels of …/ to stand a better chance of reaching the root directory, before trying to traverse to sensitive files.

  5 Tue Jun 5 11:04:29 BST 2018 good.sh 20 Tue Jun 5 11:04:42 BST 2018 ../../../../../../../../tmp/evil.sh

The contents of this zip file have to be hand crafted. Archive creation tools don’t typically allow users to add files with these paths, despite the zip specification allowing it. However, with the right tools, it’s easy to create files with these paths.

The second thing you’ll need to exploit this vulnerability is to extract the archive, either using your own code or a library. The vulnerability exists when the extraction code omits validation on the file paths in the archive. An example of a vulnerable code snippet (example shown in Java) can be seen below.

 1   Enumeration<ZipEntry>entries = zip.getEntries(); 2   while (entries.hasMoreElements()) { 3       ZipEntry e = entries.nextElement(); 4       File f = new File(destinationDir, e.getName()); 5       InputStream input = zip.getInputStream(e); 6       IOUtils.copy(input, write(f)); 7   }

You can see on line 4, e.getName() is concatenated with the target directory, dir, without being validated. At this point, when our zip archive gets to our evil.sh, it will append the full path (including every …/) of the zip entry to the target directory resulting in evil.sh being written outside of the target directory.

To see Zip Slip in action, watch us exploit the vulnerable java-goof application , a sample application used to show many known vulnerabilities.

Are you Vulnerable?

You are vulnerable if you are either using a library which contains the Zip Slip vulnerability or your project directly contains vulnerable code, which extracts files from an archive without the necessary directory traversal validation. Snyk is maintaining a GitHub repository listing all projects that have been found vulnerable to Zip Slip and have been responsibly disclosed to, including fix dates and versions. The repository is open to contributions from the wider community to ensure it holds the most up to date status.s.

What action should you take?

Here are some steps you can take to check if your project’s dependencies of code contain the Zip Slip vulnerability:

1. Search through your projects for vulnerable code.

1. java

   As previously mentioned, the Java ecosystem doesn’t offer a central library containing high level processing of archive files. The popular Oracle and Apache commons-compress APIs that are heavily used do offer some archiving support but do not publicly provide the full extract capability. This has contributed to there being more instances of users hand crafting the archive processing code themselves. We observed that the Java ecosystem had many more archive libraries than other ecosystems, many of which were found to be vulnerable .

   Example Vulnerable Code:

   1   Enumeration<ZipEntry> entries = zip.getEntries();
   2   while (entries.hasMoreElements()) { 
   3     ZipEntry e = entries.nextElement(); 
   4     File f = new File(destinationDir, e.getName()); 
   5     InputStream input =zip.getInputStream(e); 6 IOUtils.copy(input, write(f)); 
   7   }
   

   Example Validation Code:

   1   String canonicalDestinationDirPath = destinationDir.getCanonicalPath(); 
   2   File destinationfile = new File(destinationDir, e.getName()); 
   3   String canonicalDestinationFile =  destinationfile.getCanonicalPath();
   4   if (!canonicalDestinationFile.startsWith(canonicalDestinationDirPath + File.separator)) { 
   5       throw new  ArchiverException("Entry is outside of the target dir: " + e.getName()); 
   6   }
   

2. groovy

   Like Java, Groovy also has vulnerable snippets in various project codebases, as well as making use of all the vulnerable Java archive processing libraries .

   Example Vulnerable Code:

   1   final zipInput = new ZipInputStream(newFileInputStream(self)) 
   2   zipInput.withStream { 
   3     def entry 
   4     while(entry = zipInput.nextEntry) { 
   5       final file = new File(dest, entry.name) 
   6       file.parentFile?.mkdirs()
   7       def output = new FileOutputStream(file) 
   8       output.withStream { 
   9         output << zipInput 
   10      } 
   11      unzippedFiles >> file 
   12  } 
   13 }
   

   Example Validation Code:

   1   final canonicalDestinationDirPath = destinationDir.getCanonicalPath() 
   2   final destinationfile = new File(destinationDir, e.name) 
   3   final canonicalDestinationFile = destinationfile.getCanonicalPath() 
   4   if (!canonicalDestinationFile.startsWith(canonicalDestinationDirPath + File.separator)) { 
   5       throw new ArchiverException("Entry is outside of the target dir: ${e.name}") 
   6   }
   

3. JavaScript

   JavaScript has benefitted from having more central libraries that provide the functionality to extract from archives and the vulnerable libraries we found before public disclosure were fixed. Note that the join command concatenates the two path parameters and returns the shortest path possible after being resolved.

   Example Vulnerable Code:

   1   self.on('entry', function(entry) { 
   2     entry.pipe(Writer({ 
   3       path: path.join(opts.path,entry.path) 
   4   }))
   

   Example Validation Code:

   1  var filePath = path.join(targetFolder, entry.path); 
   2   if (filePath.indexOf(path.join(targetFolder, path.sep)) != 0) { 
   3      return; 
   4   }
   

4. .net

   The .Net ecosystem also has central libraries that perform the extraction functionality. In fact the code in the core .Net library that checks for the Zip Slip vulnerability was so neat, we used the implementation as the example reference solution to other libraries and ecosystems.

   Example Vulnerable Code:

   1   public static void WriteToDirectory(IArchiveEntry entry, 
   2                                       string destDirectory, 
   3                                       ExtractionOptions options){ 
   4     string file = Path.GetFileName(entry.Key); 
   5     string destFileName = Path.Combine(destDirectory, file); 
   6     entry.WriteToFile(destFileName, options); 
   7   }

   Example Validation Code:

   1   destFileName = Path.GetFullPath(Path.Combine(destDirectory, entry.Key)); 
   2   string fullDestDirPath = Path.GetFullPath(destDirectory + 
   3   Path.DirectorySeparatorChar); 
   4   if (!destFileName.StartsWith(fullDestDirPath)) { 
   5      throw new ExtractionException("Entry is outside of the target dir: " 
   6      + destFileName); 
   7   }
   

5. go

   The Go ecosystem only has one vulnerable library that we found which was fixed within two days of us disclosing the issue. Note that the Join command concatenates the two path parameters and returns the shortest path possible after being resolved.

   Example Vulnerable Code:

   1   func (rarFormat) Read(input io.Reader, dest string) { 
   2     rr := rardecode.NewReader(input, "") 
   3     for {
   4       header := rr.Next() 
   5       writeNewFile(filepath.Join(dest, header.Name), rr, header.Mode()) 
   6     } 
   7   }

   Example Validation Code:

   1   func sanitizeExtractPath(filePath string, destination string) error { 
   2   destpath := filepath.Join(destination, filePath) 
   3   if !strings.HasPrefix(destpath, filepath.Clean(destination) 
   4   + string(os.PathSeparator)) { 
   5      return fmt.Errorf("%s: illegal file path", filePath) 
   6    } 
   7    return nil 
   8   }
   

6. Ruby & Python

   We also vetted the Ruby and Python ecosystems and couldn’t find any vulnerable code snippets or libraries. In fact, Python libraries were vulnerable until fixed in 2014. Ruby has a number of existing vulnerabilities that have been fixed in previous versions here , here and here .

2. Add Zip Slip Security Testing to your application build pipeline

If you’d prefer not to search through your direct and transitive dependencies (of which you likely have hundreds) to determine if you’re using a vulnerable library, you can choose a dependency vulnerability scanning tool, like Snyk. It’s a good practice to add security testing into your development lifecycle stages, such as during development, CI, deployment and production. You can test your own projects (all the ecosystems mentioned above are supported) to determine if they are vulnerable to Zip Slip.

• Other vulnerable projects

  Vulnerable projects include projects in various ecosystems that either use the libraries mentioned above or directly include vulnerable code. Of the many thousands of projects that have contained similar vulnerable code samples or accessed vulnerable libraries, the most significant include: Oracle, Amazon, Spring/Pivotal, Linkedin, Twitter, Alibaba, Jenkinsci, Eclipse, OWASP, SonarQube, OpenTable, Arduino, ElasticSearch, Selenium, JetBrains and Google.

• Thank you!

  The Snyk security team would like for thank all the vendors, project owners and the community members that helped raise awareness, find and fix vulnerabilities in projects across many ecosystems.

参考文章三：snyk/zip-slip-vulnerability

详情见：https://github.com/snyk/zip-slip-vulnerability

---

傲节

常见漏洞汇总

SAUCERMAN

记一次Zip Slip任意文件写漏洞

小不点丶

Java之解压流（ZipInputStream）

Homepage

Zip Slip Vulnerability