This is an advisory for TWiki administrators: Attaching a specially named file allows remote upload of an Apache configuration file. This applies to native TWiki installations on Windows, the TWiki-VM (virtual machine) running in a Windows server environment is not affected.

TWiki ( http://twiki.org ) is an Open Source Enterprise Wiki and Web Application Platform used by millions of people.

   * Vulnerable Software Version
   * Attack Vectors
   * Impact
   * Severity Level
   * MITRE Name for this Vulnerability
   * Details
   * Countermeasures
   * Hotfix for TWiki Production Release 6.0.0
   * Hotfix for Older Affected TWiki Releases
   * Verify Hotfix
   * Authors and Credits
   * Action Plan with Timeline
   * External Links
   * Feedback

---++ Vulnerable Software Version

   * TWiki-6.0.0 (TWikiRelease06x00x00)
   * TWiki-5.1.x (TWikiRelease05x01x00 to TWikiRelease05x01x04)
   * TWiki-5.0.x (TWikiRelease05x00x00 to TWikiRelease05x00x02)
   * TWiki-4.3.x (TWikiRelease04x03x00 to TWikiRelease04x03x02)
   * TWiki-4.2.x (TWikiRelease04x02x00 to TWikiRelease04x02x04)
   * TWiki-4.1.x (TWikiRelease04x01x00 to TWikiRelease04x01x02)
   * TWiki-4.0.x (TWikiRelease04x00x00 to TWikiRelease04x00x05)

---++ Attack Vectors

Use an HTTP POST request towards a TWiki on Windows server to upload a specially named file (typically port 80/TCP). Prior authentication is typically required.

---++ Impact

A remote attacker can upload a '.htaccess' file that may make uploaded files executable on the server.

---++ Severity Level

The TWiki SecurityTeam triaged this issue as documented in TWikiSecurityAlertProcess and assigned the following severity level:

   * Severity 1 issue: The web server can be compromised 

---++ MITRE Name for this Vulnerability

The Common Vulnerabilities and Exposures project has assigned the name CVE-2014-7237 [3] to this vulnerability. 

---++ Details

If you attach a file named '%00.htaccess.' (e.g. a '.htaccess' configuration file with a leading null character and a trailing dot) to a TWiki server on Windows, the attached file will be saved with name '.htaccess'. Under the assumption that the Apache is configured to allow directory lever configuration files, it is therefore possible to upload a configuration file that controls the attachment directory. This can be exploited to remotely upload and execute files on the TWiki server.

__Background:__

In order to provide its users with dynamic content functionality, TWiki allows any sort of file to be uploaded and attached into articles and pages. This may seem like a dangerous thing to do, but TWiki protects itself in a pretty good way - It makes sure the file does not contain any dangerous extension (such as .php or .cgi) by using the following regex:

^(\.htaccess|.*\.(?i)(?:php[0-9s]?(\..*)?|[sp]htm[l]?(\..*)?|pl|py|cgi))$

And if it does, it adds a '.txt' extension at the end of it.

On top of that, TWiki also uses an .htaccess file with the 'Options None' directive, which prohibits any use of CGI execution, and with the PHP engine flag set to 'Off', which as one can understand - disables PHP execution.

Apart from all these defenses, TWiki makes sure it uses only the base name of the uploaded file (The file name without any directory path), it removes any trailing dots, and removes any dangerous characters (Such as the famous Null Byte). These security measurements leave us with almost nothing to do. Even without the Perl based defenses, the .htaccess file does a pretty good job in securing the upload directory against any kind of code execution. So, the only logical thing to do is try to upload an .htaccess file directly into the upload folder in order to bypass the original .htaccess file that's located at the root of the TWiki 'pub' directory.

In order to do that we first must upload a file that starts with a dot. In order to do that let's look at the steps TWiki takes in order to secure the file name - first it takes the file name without any directory path, then it removes any leading dots, then it removes any dangerous characters, and finally it checks the file name using the mentioned regex.

So, uploading a file named '.htaccess' just won't work because of the trailing dots removal. But, what if we'll use a file name like '%00.htaccess'? TWiki will first try to remove any leading dots, but because the name doesn't have any (Because of the leading null byte) none will be removed. Then it will remove any dangerous characters - our null byte - and that will leave us with a nice clean '.htaccess' name.

But, what about the regex? We can see the regex only checks for a file named specifically '.htaccess'. For example, a file named '.htaccesstest' will be uploaded successfully.

But what can we do with that? Well, in Windows, file names ending with a dot will be changed - the dot will be removed. That means uploading a file named '.htaccess.' will pass the regex check, and the dot will be removed when storing the file, resulting in a file named '.htaccess'.

So, if we upload a file named '%00.htaccess.' and it contains the 'Options' directive as 'All' and the 'SetHandler' directive to allow CGI-scripts to be executed under a different extension, we will be able to execute code on the server.

__Example attack post:__

=======( 8>< CUT )===============================================
POST /Research/TWiki-6.0.0/bin/upload.cgi/Main/WebHome HTTP/1.1
Host: 127.0.0.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7AqcZ2eUSlxvoRFj
Cookie: TWIKISID=e7df45fd5e783fd6a44391dadd782c43
Content-Length: 391

------WebKitFormBoundary7AqcZ2eUSlxvoRFj
Content-Disposition: form-data; name="crypttoken"

22b989482d3418971a50f4914dca0dcf
------WebKitFormBoundary7AqcZ2eUSlxvoRFj
Content-Disposition: form-data; name="filepath2"; filename="%00.htaccess."
Content-Type: text/plain

Options All
<FilesMatch \.lolz$>
 SetHandler cgi-script
</FilesMatch>
=======( 8>< CUT )===============================================

---++ Countermeasures

   * Apply hotfix (see patch below), or
   * Upgrade to the latest patched production release TWiki-6.0.1 (TWikiRelease06x00x01) [2]

---++ Hotfix for TWiki Production Release 6.0.0

Apply the patch listed in the TWiki bug item at TWikibug:Item7560 [8]. The patch is also listed here, but due to whitespace changes in e-mail it is not recommended to use below patch.

NOTE: In case you use a Perl accelerator make sure to clear the script cache. For example, in case of SpeedyCGI remove the speedy cache (tmp/speedy.*) before restarting Apache.

Affected file: twiki/lib/TWiki/Sandbox.pm

Patch to sanitize uploaded file names:

=======( 8>< CUT )===============================================
--- TWiki/Sandbox.pm.save1   2014-10-01 19:50:45.000000000 -0400
+++ TWiki/Sandbox.pm   2014-10-01 20:13:31.000000000 -0400
@@ -194,8 +194,11 @@
     # remember to test with IE.  
     $fileName =~ s{[\\/]+$}{};  # Get rid of trailing slash/backslash (unlikely)
     $fileName =~ s!^.*[\\/]!!;  # Get rid of directory part
+    $fileName =~ s/[\x00-\x19]//go;  # Item7560: Remove non-printable characters
 
     my $origName = $fileName;
+    # Item7560: Strip trailing dots
+    $fileName =~ s/\.*$//o;
     # Change spaces to underscore
     $fileName =~ s/ /_/go;
     # Strip dots and slashes at start
@@ -214,6 +217,11 @@
     # Append .txt to some files
     $fileName =~ s/$TWiki::cfg{UploadFilter}/$1\.txt/goi;
 
+    # Item7483, prevent a null file name
+    if ( $fileName eq '' || $fileName =~ /^\./ ) {
+        $fileName = '_' . $fileName;
+    }
+    
     # Untaint
     $fileName = untaintUnchecked($fileName);

=======( 8>< CUT )===============================================

---++ Hotfix for Older Affected TWiki Releases

Apply above patch (line numbers may vary).

---++ Verify Hotfix

To verify the patch, upload a file with a POST as described in the details. Use any other non-printable character if you can't create a file with a null character, such as '%01.htaccess.'

---++ Authors and Credits

   * Credit to Netanel Rubin (netanelr[at]checkpoint.com) for disclosing the issue with detailed description to the twiki-security@lists.sourceforge.net mailing list
   * PeterThoeny for creating the fix, patch and advisory
   * HideyoImazu for creating the TWiki-6.0.1 production release [2]

---++ Action Plan with Timeline

   * 2014-10-01 - Netanel Rubin of Check Point Software discloses issue to TWikiSecurityMailingList [4]
   * 2014-10-01 - developer verifies issue - PeterThoeny
   * 2014-10-01 - developer fixes code - PeterThoeny
   * 2014-10-05 - developer creates new TWiki-6.0.1 patch release [2] with fix - HideyoImazu
   * 2014-10-06 - security team creates advisory with hotfix - PeterThoeny
   * 2014-10-07 - send alert to TWikiAnnounceMailingList [5] and TWikiDevMailingList [6] - PeterThoeny
   * 2014-10-09 - publish advisory in Codev web and update all related topics - PeterThoeny
   * 2014-10-09 - issue a public security advisory to fulldisclosure[at]seclists.org, cert[at]cert.org, vuln[at]secunia.com, bugs[at]securitytracker.com, submissions[at]packetstormsecurity.org - PeterThoeny

---++ External Links

[1]: http://twiki.org/cgi-bin/view/Codev/TWikiSecurityAlertProcess
[2]: http://twiki.org/cgi-bin/view/Codev/TWikiRelease06x00x01
[3]: http://twiki.org/cgi-bin/view/Codev/SecurityAlert-CVE-2014-7237 (will be created on 2014-10-09)
[4]: http://twiki.org/cgi-bin/view/Codev/TWikiSecurityMailingList
[5]: http://twiki.org/cgi-bin/view/Codev/TWikiAnnounceMailingList
[6]: http://twiki.org/cgi-bin/view/Codev/TWikiDevMailingList
[7]: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7237 - CVE on MITRE.org
[8]: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item7560

---++ Feedback

Please provide feedback at the security alert topic, http://twiki.org/cgi-bin/view/Codev/SecurityAlert-CVE-2014-7237 once it exists (this topic will be created on Mon, 2014-10-09).

Please send an e-mail to twiki-security@lists.sourceforge.net if you have any questions before Monday.

-- Peter Thoeny - 2014-10-09


--
> Peter Thoeny     - Peter09[at]Thoeny.org
> http://bit.ly/MrTWiki - consulting on enterprise collaboration
> http://TWiki.org - is your team already TWiki enabled?
> Knowledge cannot be managed, it can be discovered and shared
> This e-mail is:   (_) private    (_) ask first    (x) public