{"id":56389,"date":"2024-06-24T12:56:31","date_gmt":"2024-06-24T12:56:31","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/36026\/Zip-Slips-Meets-Artifactory-A-Bug-Bounty-Story.html"},"modified":"2024-06-24T12:56:31","modified_gmt":"2024-06-24T12:56:31","slug":"zip-slips-meets-artifactory-a-bug-bounty-story","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/zip-slips-meets-artifactory-a-bug-bounty-story\/","title":{"rendered":"Zip Slips Meets Artifactory: A Bug Bounty Story"},"content":{"rendered":"

Artifactory<\/a>, developed by JFrog, is an industry-leading software repository manager, a single solution for storing and managing all the artifacts, binaries, packages, files, containers, and components for use throughout the software supply chain. JFrog Artifactory serves as a central hub for DevOps<\/a>, integrating with software development tools and processes.<\/p>\n

In this blog post I\u2019m going to tell a story about a Zip Slip vulnerability in Artifactory I reported to the JFrog private Bug Bounty Program in early 2021, a security bug for which I got a bounty of USD 5000$<\/strong> and some cool swags!<\/p>\n

Last week I also had the chance to publicly talk about this story at hackmeeting 0x1B<\/a>, with a presentation titled Attacchi Zip Slip: storia di un exploit in \u201carchivio\u201d (Zip Slip Attacks: story of an exploit in \u201carchive\u201d)<\/strong><\/em>\u2026 Here<\/a> you can find the slides used in my talk.<\/p>\n

<\/p>\n

Before moving forward to this story, let\u2019s have some context, and try to find out what is a Path Traversal vulnerability. Since a Zip Slip, in a nutshell, is an arbitrary file write vulnerability which can be exploited through Path Traversal attacks that might occur in the context of processing\/extraction of an archive file, such as a Zip or Tar archive. If you\u2019re already familiar with Path Traversal attacks you can also skip the next section.<\/p>\n

\u2022 Path Traversal Vulnerabilities<\/h4>\n

A Path Traversal<\/a> (or Directory Traversal) attack exploits an insufficient input validation of user-supplied file names, such that characters representing \u201ctraverse to parent directory\u201d – so called dot-dot-slash (..\/) sequences – are passed through to the operating system\u2019s file system API. A vulnerable application might be exploited by attackers to gain unauthorized access to the file system, allowing them to read or write arbitrary files on the system.<\/p>\n

Indeed, an application can be vulnerable to Path Traversal attacks both in reading and writing mode, leading to arbitrary file read primitives in the first case, which might introduce Information Disclosure<\/a> attack vectors, and arbitrary file write primitives in the second case, which in turn might lead to Remote Code Execution (RCE<\/a>) attacks. That\u2019s the reason why the second case is the most interesting one, and Zip Slip attacks work in writing mode, which means they can often lead to Remote Code Execution (RCE)!<\/p>\n

Following is an example of PHP application vulnerable to Path Traversal, in reading mode:<\/p>\n

\n
 1<\/span><?<\/span>php<\/span>\n 2<\/span>\n 3<\/span>\/\/ some PHP code\n<\/span> 4<\/span><\/span>\n 5<\/span>if<\/span> (isset<\/span>($_GET['filename'<\/span>]))\n 6<\/span> $image =<\/span> $_GET['filename'<\/span>];\n<\/span> 7<\/span>else<\/span>\n 8<\/span> $image =<\/span> 'default.png'<\/span>;\n 9<\/span>\n10<\/span>readfile<\/span>('\/var\/www\/images\/'<\/span> .<\/span> $image);\n<\/span>11<\/span>\n12<\/span>\/\/ some more PHP code\n<\/span>13<\/span><\/span>\n14<\/span>?><\/span>\n<\/span><\/code><\/pre>\n<\/div>\n
In this example, due to a missing input validation of the \u201cfilename\u201d<\/strong> GET parameter (which is assigned to the $image<\/code> variable at line 6), an attacker might be able to read arbitrary files on the vulnerable web server by using dot-dot-slash (..\/) sequences to e.g. reach to the root path (\/<\/code>) and retrieve the content of the password file (\/etc\/passwd<\/code>), something like this:<\/p>\n
<\/p>\n
Here is another example of vulnerable Java web application, this time in writing mode:<\/p>\n
\n
 1<\/span>@PostMapping<\/span>(<\/span>\"\/uploadimage\"<\/span>)<\/span>\n 2<\/span>public<\/span> String uploadImage<\/span>(<\/span>Model model,<\/span> @RequestParam<\/span>(<\/span>\"image\"<\/span>)<\/span> MultipartFile file)<\/span> throws<\/span> IOException\n 3<\/span>{<\/span>\n 4<\/span> var name =<\/span> file.<\/span>getOriginalFilename<\/span>().<\/span>replace<\/span>(<\/span>\" \"<\/span>,<\/span> \"_\"<\/span>);<\/span>\n 5<\/span> var fileNameAndPath =<\/span> Paths.<\/span>get<\/span>(<\/span>UPLOAD_DIRECTORY,<\/span> name);<\/span>\n 6<\/span> Files.<\/span>write<\/span>(<\/span>fileNameAndPath,<\/span> file.<\/span>getBytes<\/span>());<\/span>\n<\/span> 7<\/span>\n 8<\/span> \/\/ some more Java code\n<\/span> 9<\/span><\/span>\n10<\/span> return<\/span> \"\/user\/upload\"<\/span>;<\/span>\n11<\/span>}<\/span><\/code><\/pre>\n<\/div>\n
In this case, due to an improper input validation of the submitted \u201cfilename\u201d (which is assigned to the name<\/code> variable at line 4, and this is later used at line 6 to write the uploaded file), an attacker might be able to upload\/write arbitrary files anywhere on the web server, even outside of the destination directory (the UPLOAD_DIRECTORY<\/code> constant in this example), using dot-dot-slash (..\/) sequences within the uploaded filename by e.g. tampering the upload HTTP request with a proxy tool. Something like this:<\/p>\n
<\/p>\n
\u2022 Zip Slip Vulnerabilities<\/h4>\n
Zip Slip is a class of vulnerabilities more than thirty years old, probably \u201cborn\u201d in 1991 with an article published on Phrack<\/a>:<\/p>\n
\n
*** Technique #3: The -D Archive Hack<\/p>\n
This technique also plays on the openness of WWIV\u2019s archive system. This
\nis another method of getting a file into the root BBS directory, or anywhere on
\nthe hard drive, for that matter.<\/p>\n
First, create a temporary directory on your hard drive. It doesn\u2019t matter
\nwhat it\u2019s called. We\u2019ll call it TEMP. Then, make a sub-directory of TEMP
\ncalled AA. It can actually be called any two-character combination, but we\u2019ll
\nkeep it nice and simple. Then make a subdirectory of AA called WWIV.<\/p>\n
Place NETWORK.COM or REMOTE.COM or whatever in the directory
\n\\TEMP\\AA\\WWIV. Then from the TEMP directory execute the command:<\/p>\n
 PKZIP -r -P STUFF.ZIP <--- The case of \"r\" and \"P\" are important.\n<\/code><\/pre>\n
This will create a zip file of all the contents of the directories, but
\nwith all of the directory names recursed and stored. So if you do a PKZIP -V
\nto list the files you should see AA\\WWIV\\REMOTE.COM, etc.<\/p>\n
Next, load STUFF.ZIP into a hex editor, like Norton Utilities, and search
\nfor \u201cAA\u201d. When you find it (it should occur twice), change it to \u201cC:\u201d. It is
\nprobably a good idea to do this twice, once with the subdirectory called WWIV,
\nand another with it called BBS, since those are the two most common main BBS
\ndirectory names for WWIV. You may even want to try D: or E: in addition to C:.
\nYou could even work backwards, by forgetting the WWIV subdirectory, and just
\nmaking it AA\\REMOTE.COM, and changing the \u201cAA\u201d to \u201c..\u201d. This would be
\nfoolproof. You could work from there, doing \u201c..\\..\\DOS\\PKZIP.COM\u201d or whatever.<\/p>\n
Then upload STUFF.ZIP (or whatever you want to call it) to the BBS, and
\ntype \u201cE\u201d to extract it to a temporary directory. It\u2019ll ask you what file.
\nType \u201cSTUFF.ZIP\u201d. It\u2019ll ask what you want to extract. Type \u201c””-D\u201d. It\u2019ll
\nthen execute:<\/p>\n
 PKUNZIP STUFF.ZIP \"\"-D\n<\/code><\/pre>\n
It will unzip everything into the proper directory. Voila.<\/p>\n<\/blockquote>\n
So, basically the concept of putting dot-dot-slash (..\/) sequences inside an archive file, and therefore exploit applications vulnerable to Path Traversal attacks in this way, has been firstly introduced in September 1991 with regards to BBS<\/a> hacking, when the Web was just born a month before\u2026 However, it looks like it took some years before applying this technique to the Web context, and this likely happened in 2006, with CVE-2006-0931<\/a> and CVE-2006-0932<\/a> – which are the oldest Web related Zip Slip vulnerabilities I can see on these<\/a> lists<\/a>. Three years later, in April 2009, there was also a study published by Neohapsis<\/a>. After some more years of \u201calmost silence\u201d about it, in 2018 Snyk published a research<\/a> which \u201crenamed\u201d this class of vulnerabilities with the actual known name, and made Snyk collecting dozens of CVEs by discovering and reporting Zip Slip vulnerabilities in several software products.<\/p>\n
Let\u2019s see an example of vulnerable Java code:<\/p>\n
\n
 1<\/span>public<\/span> void<\/span> extractZipFile<\/span>(<\/span>ZipFile zip,<\/span> String destinationDir)<\/span>\n 2<\/span>{<\/span>\n 3<\/span> Enumeration<<\/span>ZipEntry><\/span> entries =<\/span> zip.<\/span>getEntries<\/span>();<\/span>  4<\/span> while<\/span> (<\/span>entries.<\/span>hasMoreElements<\/span>())<\/span>\n 5<\/span> {<\/span>  6<\/span> ZipEntry e =<\/span> entries.<\/span>nextElement<\/span>();<\/span>  7<\/span> File f =<\/span> new<\/span> File(<\/span>destinationDir,<\/span> e.<\/span>getName<\/span>());<\/span> <\/span> 8<\/span> InputStream input =<\/span> zip.<\/span>getInputStream<\/span>(<\/span>e);<\/span>  9<\/span> IOUtils.<\/span>copy<\/span>(<\/span>input,<\/span> write(<\/span>f));<\/span> 10<\/span> }<\/span>\n11<\/span>}<\/span><\/code><\/pre>\n<\/div>\n
As you can see, at line 7 the entry name (filename) within the Zip archive – or rather, the value returned by the call to e.getName()<\/code> – is concatenated with the destination directory, without being validated, and this is later used at line 9 to actually write\/extract the file from the archive. As such, this might be exploited by providing a specially crafted Zip archive which contains dot-dot-slash (..\/) sequences within its entry filenames, leading to an arbitrary file write primitive via Path Traversal attacks.<\/p>\n
\u2022 Zip Slip Vulnerability in JFrog Artifactory <= 7.12.10<\/h4>\n
It all began on December 28, 2020, when I received an invitation for a HackerOne<\/a> private program by JFrog. I was very glad for that, and immediately got intrigued by Artifactory\u2026 So, I downloaded it, installed it, and started testing and doing reverse engineering of its Java source code. As a result, I discovered a few nice security bugs affecting Artifactory, but here I\u2019m going to detail only one of them, probably the most interesting one (seeing it took me some days of hard work to actually exploit it). It\u2019s about a Zip Slip vulnerability located in the org.artifactory.addon.bower.helpers.BowerExternalDependenciesHandler<\/code> class:<\/p>\n
\n
110<\/span> private<\/span> List<<\/span>File><\/span> extractBowerPackage<\/span>()<\/span> throws<\/span> IOException,<\/span> ArchiveException {<\/span>\n111<\/span> log.<\/span>debug<\/span>(<\/span>\"Extracting archive contents of bower package {} for dependency rewrite on repo {}\"<\/span>,<\/span> this<\/span>.<\/span>resource<\/span>\n112<\/span> .<\/span>getRepoPath<\/span>(),<\/span> this<\/span>.<\/span>repo<\/span>.<\/span>getKey<\/span>());<\/span>\n113<\/span> ResourceStreamHandle handle =<\/span> this<\/span>.<\/span>repoService<\/span>.<\/span>getResourceStreamHandle<\/span>(<\/span>this<\/span>.<\/span>resource<\/span>.<\/span>getRepoPath<\/span>());<\/span>\n114<\/span> List<<\/span>File><\/span> archiveContents =<\/span> new<\/span> ArrayList<>();<\/span>\n115<\/span> ArchiveInputStream stream =<\/span> (<\/span>new<\/span> ArchiveStreamFactory()).<\/span>createArchiveInputStream<\/span>(<\/span>new<\/span> BufferedInputStream(<\/span>new<\/span> GZIPInputStream(<\/span>handle.<\/span>getInputStream<\/span>())));<\/span>\n116<\/span> try<\/span> {<\/span>\n117<\/span> ArchiveEntry entry;<\/span>\n118<\/span> while<\/span> ((<\/span>entry =<\/span> stream.<\/span>getNextEntry<\/span>())<\/span> !=<\/span> null<\/span>)<\/span> {<\/span>\n119<\/span> if<\/span> (!<\/span>entry.<\/span>isDirectory<\/span>()<\/span> &&<\/span> !<\/span>entry.<\/span>getName<\/span>().<\/span>contains<\/span>(<\/span>\"pax_global_header\"<\/span>))<\/span> {<\/span>\n120<\/span> File outputFile =<\/span> copyEntryToFile(<\/span>stream,<\/span> entry);<\/span>\n<\/span>121<\/span> archiveContents.<\/span>add<\/span>(<\/span>outputFile);<\/span>\n122<\/span> }<\/span> 123<\/span> }<\/span> 124<\/span> if<\/span> (<\/span>stream !=<\/span> null<\/span>)<\/span>\n125<\/span> stream.<\/span>close<\/span>();<\/span> 126<\/span> }<\/span> catch<\/span> (<\/span>Throwable throwable)<\/span> {<\/span>\n127<\/span> if<\/span> (<\/span>stream !=<\/span> null<\/span>)<\/span>\n128<\/span> try<\/span> {<\/span>\n129<\/span> stream.<\/span>close<\/span>();<\/span>\n130<\/span> }<\/span> catch<\/span> (<\/span>Throwable throwable1)<\/span> {<\/span>\n131<\/span> throwable.<\/span>addSuppressed<\/span>(<\/span>throwable1);<\/span>\n132<\/span> }<\/span> 133<\/span> throw<\/span> throwable;<\/span>\n134<\/span> }<\/span> 135<\/span> if<\/span> (<\/span>log.<\/span>isTraceEnabled<\/span>())<\/span>\n136<\/span> log.<\/span>trace<\/span>(<\/span>\"Archive contents for bower package at {} are: {}\"<\/span>,<\/span> this<\/span>.<\/span>resource<\/span>.<\/span>getRepoPath<\/span>(),<\/span> 137<\/span> Arrays.<\/span>toString<\/span>(<\/span>archiveContents.<\/span>toArray<\/span>()));<\/span> 138<\/span> return<\/span> archiveContents;<\/span>\n139<\/span> }<\/span>\n140<\/span> 141<\/span> private<\/span> File copyEntryToFile<\/span>(<\/span>ArchiveInputStream stream,<\/span> ArchiveEntry entry)<\/span> throws<\/span> IOException {<\/span>\n142<\/span> File outputFile =<\/span> new<\/span> File(<\/span>this<\/span>.<\/span>tempBowerDirectory<\/span>,<\/span> entry.<\/span>getName<\/span>());<\/span>\n<\/span>143<\/span> Files.<\/span>createDirectories<\/span>(<\/span>outputFile.<\/span>toPath<\/span>().<\/span>getParent<\/span>(),<\/span> (<\/span>FileAttribute<?>[])<\/span>new<\/span> FileAttribute[<\/span>0]);<\/span>\n144<\/span> OutputStream os =<\/span> new<\/span> FileOutputStream(<\/span>outputFile);<\/span>\n145<\/span> IOUtils.<\/span>copy<\/span>((<\/span>InputStream)<\/span>stream,<\/span> os);<\/span>\n146<\/span> os.<\/span>close<\/span>();<\/span>\n147<\/span> return<\/span> outputFile;<\/span>\n148<\/span> }<\/span><\/code><\/pre>\n<\/div>\n
\n
WAR files have to be placed in Tomcat webapps path \/opt\/jfrog\/artifactory\/tomcat\/webapps\/. By default, deployment of WAR files is automatic and will start another web application next to the Artifactory instance, e.g. at http:\/\/localhost:8081\/sample\/.<\/p>\n<\/blockquote>\n
Following are the steps to create a specially crafted Bower package to exploit this Zip Slip vulnerability:<\/p>\n
The extractBowerPackage()<\/code> method is called when handling \u201cexternal dependencies rewrite<\/a>\u201d of Bower<\/a> packages, and this in turn will call the vulnerable copyEntryToFile()<\/code> method at line 120 for each entry within the Bower package (which is expected to be a .tar.gz file). At line 142, this method uses the entry name (filename) provided within the user-tainted Bower archive – or rather, the value returned by the call to entry.getName()<\/code> – for concatenation with a temporary directory to create a new File<\/code> object, without proper validation. Such a File<\/code> object is later used at lines 144-145 to actually extract the file from the package and write it on the file system. This can be exploited to write (or overwrite) arbitrary files on the remote web server by providing a malicious Bower package containing dot-dot-slash (..\/) sequences within its entry filenames, resulting in Remote Code Execution (RCE) attacks by e.g. creating a new WAR<\/a> file inside the Tomcat webapps<\/code> directory, which will be automatically deployed<\/a> as a new Tomcat web application after a few seconds:<\/p>\n
This, in turn, might lead to Remote Code Execution (RCE) attacks by e.g. creating new malicious JSP<\/a> files inside the server\u2019s webroot folder, and remotely executing them by invoking the same through HTTP requests. Another possible attack vector would be to write\/overwrite the user\u2019s SSH private key (i.e. \/home\/user\/.ssh\/id_rsa<\/code>), and gain unauthorized access to the web server through SSH, if exposed. In other words, there could be a number of ways to get Remote Code Execution (RCE) from an arbitrary file write primitive, and they all depend on the context, as we will see shortly.<\/p>\n