|
|
|
|
| |
| The vulnerability is caused by an incompatibility issue with the old Win16/DOS file naming convention, known as the 8.3 naming system. (Files using the 8.3 naming system consist of 8 characters followed by a period (.) and a 3 character extension, thus giving a name of "8.3") |
| |
Credit:
This vulnerability has been reported by: x-empt [ lvhc / lou ].
|
| |
Many products in use today are still affected by this compatibility issue, causing them to function incorrectly and creating the mentioned vulnerability.
IIS
Even though IIS is suppose to be immune to this problem, this problem occurs even after SP5 is applied.
Microsoft Internet Information Server 4.0 allows privileges to be inherited from parent directories instead of requested directory if the requested directory is a long file name.
EXAMPLE:
C:\inetpub\wwwroot\ (directory listing enabled)
C:\inetpub\wwwroot\subdirectory\ (listing disabled)
REQUEST http://server/subdirectory/ (denied error message)
REQUEST http://server/subdir~1/ (listing of directory)
SERV-U FTP (www.cat-soft.com / www.ftpserv-u.com)
Certain commands in Serv-U are not properly validated with the access control list.
VQSERVER (www.vqsoft.com)
This issue is very similar to the IIS issue.
XITAMI web server (www.imatix.com)
Again, similar to the IIS issue.
Detailed explanation:
IIS / Personal Web Server (PWS) -- Although this is not a major security problem for most, remote systems security is compromised as scripts can be executed, file listings displayed, and so on. Virtual Directories are not affected as they are virtual, and no short name exists for them.
How to reproduce:
1) Mkdir C:\inetpub\wwwroot\subdirectory\
2) Mkdir C:\inetpub\wwwroot\subdirectory\subdirectory2\
3) Set "C:\inetpub\wwwroot\subdirectory\" privileges to listing
4) Set "C:\inetpub\wwwroot\" privileges to no listing
5) Request "http://localhost/subdir~1/" (you will should see a listing for "subdirectory2")
Serv-U -- Serv-U 2.5a has two known improperly checked commands. "cwd" and "site exec" both do not check the specified path against the access lists properly.
How to reproduce:
1) Mkdir C:\tmphome
2) Mkdir C:\tmphome\longsubdir\
3) Set permissions for "C:\tmphome\" for "execute"
4) Set permissions for "C:\tmphome\longsubdir\" "NO execute"
5) Place an exe in "C:\tmphome\longsubdir\"
6) Login to serv-u
7) Run command "site exec C:\tmphome\longsu~1\exename.exe"
8) By using the Task Manager, you should be able to see "exename.exe" running.
vqServer -- This "exploit" is similar to the IIS problem.
Xitami -- This "exploit" is also similar to the IIS problem.
One well-known workaround for this issue that will take care of this problem, regardless of the server software, is to disable 8.3 filenames. If you open the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem
And create a value named NtfsDisable8dot3NameCreation, type REG_DWORD, and set it to 1, then the operating system will not create 8.3 filenames. Note that this isn't retroactive, so you'd need to move any trees you want updated, and then move them back. This is something that should be on anyone's checklist when setting up a web or FTP server prior to putting content on that server.
|
|
|
|
|
