Core Security Technologies Advisory 2010.0121

2010-02-06T00:00:00
ID PACKETSTORM:86008
Type packetstorm
Reporter Core Security Technologies
Modified 2010-02-06T00:00:00

Description

                                        
                                            `-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
Core Security Technologies - CoreLabs Advisory  
http://www.coresecurity.com/corelabs/  
  
Multiple Vulnerabilities with 8.3 Filename Pseudonyms in Web Servers  
  
  
  
1. *Advisory Information*  
  
Title: Multiple Vulnerabilities with 8.3 Filename Pseudonyms in Web Servers  
Advisory Id: CORE-2010-0121  
Advisory URL:  
http://www.coresecurity.com/content/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 multiple 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) [6].  
  
. 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.  
[6] Nginx mail list.  
http://nginx-maillist.blogspot.com/2010/02/nginx-0833.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:  
http://www.coresecurity.com/corelabs.  
  
  
12. *About Core Security Technologies*  
  
Core Security Technologies 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. Based in Boston, MA and Buenos Aires, Argentina, Core  
Security Technologies can be reached at 617-399-6980 or on the Web at  
http://www.coresecurity.com.  
  
  
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  
Technologies advisories team, which is available for download at  
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.4.8 (MingW32)  
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/  
  
iEYEARECAAYFAktsincACgkQyNibggitWa3Z5ACfYMSjRozwndnvWAldcCRo5W5C  
kUEAnjY2dmFWup/6s1GV9vALr3u1Wbfy  
=MTyQ  
-----END PGP SIGNATURE-----  
  
`