Multiple Vulnerabilities with 8.3 Filename Pseudonyms in Web Servers

Advisory ID Internal

CORE-2010-0121

1. Advisory Information

Advisory Id: CORE-2010-0121
Advisory URL: https://www.coresecurity.com/core-labs/advisories/filename-pseudonyms-vulnerabilities
Date published: 2010-02-05
Date of last update: 2010-02-05
Vendors contacted: Cherokee team, Nginx team, Mongoose team
Release mode: User release

2. Vulnerability Information

Class: Improper Handling of Exceptional Conditions [CWE-755], Path traversal [CWE-22]
Impact: Security bypass
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: N/A
CVE Name: N/A

3. Vulnerability Description

When a file is created on a Windows system, a DOS-compatible 8.3 short file name (hereafter referred to as '8.3 alias') is generated for backwards compatibility reasons. Both names can be used to refer to the same file. Applications which allow users to specify file names on Windows systems should be aware of these aliases and handle them appropriately.

Often, by using 8.3 aliases for files, one can bypass IDS/IPS detection, and evade filters and file restrictions. This can be a result of the fact that only the long versions of file and folder names will be restricted and the alias will not match the long filename.

Referencing files using their 8.3 aliases can even change how the files are handled, due to truncation of the file extension in the event that the file extension is longer than three characters. This problem is exacerbated by the fact that intermediary systems used for things like load balancing and caching do not have access to the actual file system being accessed and need to convert any filenames and pathnames with restrictions to their 8.3 alias before comparing to user data, which, given the presence of other files or folders on the system with similar names, may not be possible.

This advisory describes multiples vulnerabilities based on quirks in how Windows handles file names. The affected software is the Windows version of the following web servers:

Nginx Web Server [1]. The way Nginx handles files may differ when they are requested using their 8.3 alias, and short file or path names are not correctly handled when applying file handling rules or access restrictions. By abusing of these flaws an attacker can bypass security options implemented in the web server. For instance, file.shtml will become FILE~1.SHT. This will cause the file to be handled as a .sht file, not a .shtml file. The result of this is that instead of processing SSI directives as would normally be the case with a .shtml file, the file would be served unprocessed. Additionally, Nginx does not correctly handle extraneous spaces after file extensions when applying preprocessing rules or access restrictions.
Cherokee Web Server [2]. On Cherokee Web Server for Windows, short file and folder names are not correctly handled when applying file handling rules, IP access restrictions or authentication rules. Extraneous trailing spaces in file names are not correctly handled when applying file handling rules or access restrictions. By abusing of these flaws, Cherokee configuration folders can be accessed from any IP, without authentication bypassing the web server security protection mechanisms.
Mongoose Web Server [3]. Mongoose does not correctly handle Windows short file names (and folder names) when applying preprocessing rules or access restrictions. As a result, an attacker can bypass the web server security protection mechanisms, and protected files can be accessed unprocessed without authentication.
LightTPD Web Server. The WLMP build of LightTPD for Windows [4] does not correctly handle Windows short file or path names when applying preprocessing rules, file extension restrictions or access restrictions. It also does not correctly handle extraneous trailing periods when applying file extension restrictions, but does properly apply preprocessing rules.

4. Vulnerable Packages

Nginx Web Server v0.7.63
Nginx Web Server v0.8.29
Cherokee Web Server v0.99.28
Mongoose Web Server v2.8
WLMP web server package for Windows v1.1.6.1171
Older versions are probably affected too, but they were not checked.

5. Non-Vulnerable Packages

Nginx Web Server v0.8.33
Contact Cherokee, Mongoose and WLMP Web Server projects for additional information.

6. Vendor Information, Solutions and Workarounds

Attacks using 8.3 aliases can be mitigated by turning off 8.3 alias generation, by setting the value of NtfsDisable8dot3NameCreation to 1 in HKLM\System\CurrentControlSet\Control\FileSystem.

7. Credits

These vulnerabilities were discovered and researched by Dan Crowley from Core Security Technologies.

8. Technical Description / Proof of Concept Code

8.1. Nginx Web Server

The following configuration snippet for Nginx Web Server will process any file with an extension of .phtml or .php by passing it to another service running locally on port 8080 for processing. It will deny requests for files beginning with .ht and the directory longfoldername.

location ~ \.php$ { proxy_pass http://127.0.0.1:8080; } location ~ \.phtml$ { proxy_pass http://127.0.0.1:8080; } location ~ /\.ht { deny all; } #deny longfoldername directory explicitly location ~ /longfoldername/ { deny all; }

The longfoldername folder can be accessed when using the following URI:

http://www.example.com/LONGFO~1/

Files denied by matching the extension or the file name can be accessed using a similar technique. A file named .htpasswd could be retrieved as demonstrated below:

http://www.example.com/HTPASS~1

Nginx Web Server will serve the unprocessed source code for files normally intended to be preprocessed when using URIs similar to the following (these examples assume the presence of the files file.phtml and file.php:

http://www.example.com/FILE~1.PHT http://www.example.com/file.php%20

Similarly, if a file can be uploaded whose extension, when truncated to three characters, matches an extension which Nginx is set to process as code, it can be run as code by referring to it with an 8.3 alias. For instance, if a file named file.phpx is uploaded to the webroot, it can be executed as PHP code with the following URI:

http://www.example.com/FILE~1.PHP

8.2. Cherokee Web Server

The following configuration snippet for Cherokee Web Server will allow only requests from 1.2.3.4 to reach the directory longfoldername and additionally, requires a password defined in /Program Files/Octality/Cherokee/etc/passwd in order to gain access.

vserver!1!rule!1!match = directory vserver!1!rule!1!match!directory = /longfoldername vserver!1!rule!1!match!allow_from = 1.2.3.4 vserver!1!rule!1!auth = plain vserver!1!rule!1!auth!methods = basic vserver!1!rule!1!auth!passwdfile = /Program Files/Octality/Cherokee/etc/passwd vserver!1!rule!1!auth!realm = secret

The folder can be accessed from any IP, without authentication, when accessing the file using either of the following URIs:

http://www.example.com/longfoldername./ http://www.example.com/LONGFO~1/

Files denied by matching the extension or the file name can be accessed using similar techniques, as demonstrated below:

http://www.example.com/longfilename.inc. http://www.example.com/longfilename.inc%20 http://www.example.com/LONGFI~1.INC

In the following rule, the extensions .php and .phtml are both configured to be handled by FastCGI and preprocessed before being served.

vserver!1!rule!99999!match = extensions vserver!1!rule!99999!match!extensions = php,phtml vserver!1!rule!99999!encoder!gzip = 1 vserver!1!rule!99999!handler = fcgi vserver!1!rule!99999!handler!balancer = round_robin vserver!1!rule!99999!handler!balancer!source!1 = 1

Cherokee Web Server will serve the unprocessed source code for these file extensions when using URIs similar to the following:

http://www.example.com/EXAMPL~1.PHT http://www.example.com/example.phtml%2e http://www.example.com/example.php%20

Similarly, if a file can be uploaded whose extension, when truncated to three characters, matches an extension which Cherokee is set to process as code, it can be run as code by referring to it with an 8.3 alias. For instance, if a file named file.phpx is uploaded to the webroot, it can be executed as PHP code with the following URI:

http://www.example.com/FILE~1.PHP

8.3. Mongoose Web Server

The following configuration snippet will cause Mongoose to process files with extensions of .php or .phtml as PHP code, and files with extensions of .shtml will be processed for SSI directives. It will also require a password (stored in C:\passwords.txt) when attempting to access the folder /longfoldername.

cgi_ext php,phtml ssi_ext shtml protect /longfoldername/=C:\passwords.txt

Given that the files file.phtml and file.shtml exist and the folder /longfoldername exists, these items can be accessed unprocessed, without authentication, using the following URIs:

http://www.example.com/LONGFO~1/ http://www.example.com/FILE~1.PHT http://www.example.com/FILE~1.SHT

Similarly, if a file can be uploaded whose extension, when truncated to three characters, matches an extension which Mongoose is set to process as code, it can be run as code by referring to it with an 8.3 alias. For instance, if a file named file.phpx is uploaded to the webroot, it can be executed as PHP code with the following URI:

http://www.example.com/FILE~1.PHP

8.4. LightTPD Web Server (WLMP package)

The following configuration snippet for WLMP will forbid any file with the extensions .inc or .exte, attempt to process files with a .phtml or .php extension for PHP code, and authenticate users attempting to access the directory /longfoldername.

## deny access the file-extensions # # ~ is for backupfiles from vi, emacs, joe, ... # .inc is often used for code includes which should in general not be part # of the document-root url.access-deny = ( ".inc", ".exte" ) # which extensions should not be handle via static-file transfer # # .php, .pl, .fcgi are most often handled by mod_fastcgi or mod_cgi static-file.exclude-extensions = ( ".phtml" ) #### CGI module cgi.assign = ( ".phtml"=> "C:/WLMP/PHP/php-cgi.exe", ".php"=> "C:/WLMP/PHP/php-cgi.exe" ) auth.backend = "plain" auth.backend.plain.userfile = "C:/WLMP/LightTPD/conf/lighttpd-auth.conf" auth.require = ( "/longfoldername/" => ( "method" => "basic", "realm" => "Restricted folder", "require" => "user=admin" ) )

The folder /longfoldername can be accessed without authentication, when accessing the file using the following URI:

http://www.example.com/LONGFO~1/

The unprocessed contents of a .inc, .phtml, or .exte file under this configuration could be accessed using URIs like the following (these URIs assume files named file.inc, longfilename.exte and file.phtml exist:

http://www.example.com/file.inc. http://www.example.com/longfilename.exte%20 http://www.example.com/FILE~1.PHT

Similarly, if a file can be uploaded whose extension, when truncated to three characters, matches an extension which LightTPD is set to process as code, it can be run as code by referring to it with an 8.3 alias. For instance, if a file named file.phpx is uploaded to the webroot, it can be executed as PHP code with the following URI:

http://www.example.com/FILE~1.PHP

9. Report Timeline

2010-01-12: Core Security Technologies notifies the Cherokee, Nginx and Mongoose teams of the vulnerability. Core also informs that Dan Crowley will be giving a presentation explaining these flaws at the security conference Shmoocon 2010 [5].
2010-01-12: The Cherokee and Mongoose teams ask Core for a technical description of the vulnerability.
2010-01-12: Technical details sent to Cherokee and Mongoose teams by Core.
2010-01-12: Cherokee team notifies Core that the issues have been evaluated and considered security vulnerabilities. Cherokee team also informs us that they are not currently shipping Windows binaries because they are aware of all this sort of issues. The Windows port has not received much attention for the last few years and it is far from being ready for production. Cherokee team also states that they will link Core advisory from their bug-tracker as soon as it is published. Currently the Windows port is still low-priority for Cherokee project.
2010-01-13: The Nginx team asks Core for a technical description of the vulnerability.
2010-01-13: Technical details sent to Nginx team by Core.
2010-01-15: Nginx team informs us that the investigation about the reported issues has finished, the issues have been evaluated and Nginx team agrees that they are security vulnerabilities. The Nginx team also notifies us that they will fix it in next versions that will be released on Jan 18 or 25.
2010-02-01: Nginx team releases a new version of the web server (nginx-0.8.33).
2010-02-05: The flaws are disclosed by Dan Crowley at the security conference Shmoocon 2010 [5].
2010-02-05: The advisory CORE-2010-0121 is published.

10. References

[1] Nginx Web Server. http://wiki.nginx.org/.
[2] Cherokee Project. http://www.cherokee-project.com/.
[3] Mongoose project. http://code.google.com/p/mongoose/.
[4] WMLP project. http://en.wlmp-project.net/.
[5] Shmoocon 2010. http://www.shmoocon.org/presentations-all.html.

11. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: https://www.coresecurity.com/core-labs.

12. About Core Security

Core Security develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, Core Impact, is the most comprehensive product for performing enterprise security assurance testing. Core Impact evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing.

13. Disclaimer

The contents of this advisory are copyright (c) 2010 Core Security Technologies and (c) 2010 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

14. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team.