The vulnerability (CVE-2014-7237) allows an attacker to execute arbitrary system code on any TWiki installed on a Windows based server, with the only requirement of being able to upload files to the system (Enabled by default).
TWiki is an open-source web platform used to create and maintain wikis. It allows its users to upload files into the server in order to attach them into current articles. Most dangerous files are filtered out successfully, and with the combined .htaccess protection it is almost impossible to compromise the web server through this feature.
Note: This vulnerability was found back in 2014, as part of my work at Check Point’s Research group.
This is the first time the details are released publicly.
Vulnerable Versions
TWiki 6.0.0 and earlier.
Technical Description
In order to provide its users with dynamic content, 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 name does not end with any dangerous extension (such as .php or .cgi) by using the following regex:
^(\.htaccess|.*\.(?i)(?:php[0-9s]?(\..*)?|[sp]htm[l]?(\..*)?|pl|py|cgi))$
This seemingly complicated regex basically checks for the following extensions:
- htaccess
- php, php4, php5
- htm, html, shtml, phtml
- pl
- py
- cgi
If one of these extensions are present, it forces the file name to end with the “txt” extensions.
On top of that, TWiki also uses an “.htaccess” file located in the “pub” root directory 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 validations, TWiki makes sure it uses only the base name of the uploaded file (The file name alone, without any directory path), 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 extensions restriction, the “.htaccess” file does a pretty good job of securing the upload directory against any kind of dangerous file upload.
Our only option is to try and upload an “.htaccess” file directly into the upload folder, in order to bypass the original “.htaccess” file located at the root of the “pub” directory.
In order to do that we first must upload a file that starts with a dot. Let’s look at the algorithm TWiki uses in order to secure the file name:
- Parse the file’s base name (removing any directory path)
- Remove any trailing dots
- Strip dangerous characters
- Check the file name using the regex above
What happens if we will use a name similar to “%00.htaccess”?
Because the system first checks for a trailing dots and only then removes dangerous characters, our Null Byte will be removed but our trailing dot will not – a fine example of how one security mechanism makes another one useless.
But what about the regex? We can see the regex only checks for a file named “.htaccess” exactly. A file named “.htaccesstest” will be uploaded successfully, for example.
In Windows, file names ending with a dot will be stripped from their ending dot automatically. This means uploading a file named “.htaccess.” will pass the regex check successfully, and when saved Windows will automatically remove the extra dot for us – saving the file as “.htaccess”.
So, if we will upload a file named “%00.htaccess.”, containing the “Options” directive set to “All” and the “SetHandler” directive set to allow CGI scripts using any extension, we will be able to execute any file uploaded – images, archives or even regular text files.
This easy bypass allows us to exploit an arbitrary file upload vulnerability by uploading a regular “.txt” file and then simply executing it.