Use of Activer Server Explorer for read and write access to files

active|server| Access

Vulnerability Description:

Chinaasp's Activer Server Explorer makes it easy to view the directory on your local files online to view the file name, size, type, modify time, online edit plain text files, such as. txt,. htm,. asp,. PL,. CGI, and so on, Executes files directly on the server.

Activer Server Explorer requires a relative path or absolute path to be filled in, but if: An attacker uploads Activer Server Explorer to a directory on the target server, and the directory supports ASP, Then he can modify and execute files on the target server through Activer Server Explorer. This can happen when an attacker owns a writable directory account on the target NT Server, and the directory supports ASP. For example, some personal free homepage server that supports ASP, send Activer Server Explorer to the free homepage space of your request first, and then get the path of the target server through various methods, such as through loophole: "Request nonexistent extension is IDQ or Ida file, Exposes the physical address of the file on the server. "). Or simply fill in the "." On the relative path, which is generally the default. This allows an attacker to arbitrarily modify and execute files on the target server, regardless of whether or not he has read or write access to the file.

Therefore, those who provide a personal homepage of ASP services or other services of the server, you should be doubly careful of this attack.

Vulnerability resolution

In fact, Activer Server Explorer uses the vulnerability 4 FileSystemObject component to tamper with the vulnerability to download any file on a FAT partition.

So how can we restrict users from using FileSystemObject objects? An extreme approach is to completely reverse the registration of the component that provides the FileSystemObject object, namely the Scrrun.dll. The specific methods are as follows:
  
   Type in the MS-DOS state:
  
  regsvr32/u c:\windows\　　System\scrrun.dll
  
   (Note: Change to be your local actual path in actual operation)
  
   But in this case, you can not use the FileSystemObject object, and sometimes use the FileSystemObject object to manage the file is very convenient, what way can the both worlds?
  
   We can prevent others from illegally using FileSystemObject objects, but we can still use this object ourselves. The
   method is as follows:

Find in the registry

Hkey_classes_root\scripting.filesystemobject Key value

Change it to the string you want (right---> "rename"), such as changing to

Hkey_classes_root\scripting.filesystemobject2

In this way, the ASP must refer to this object as follows:

Set fso = CreateObject ("Scripting.filesystemobject2")

and cannot be used:

Set fso = CreateObject ("Scripting.FileSystemObject")

If you use the usual method to invoke the FileSystemObject object, you will not be able to use it.

As long as you don't tell anyone about this changed object name, other people are unable to use the FileSystemObject object. In this way, as a site manager we have to eliminate the illegal use of other people FileSystemObject objects, and we can still use this object to facilitate the implementation of Web site online management and so on functions!