A history of serious security vulnerabilities has plagued Microsoft FrontPage Server Extensions. Thus, many security documents recommend simply removing FrontPage Server Extensions rather than attempting to secure them. And many Web administrators won't permit an installation of FrontPage Server Extensions on their Web servers. However, if you require FrontPage's built-in authoring support, the question remains: Can you properly secure FrontPage Server Extensions? The answer is yes. But doing so takes some planning and a little effort. Although FrontPage Server Extensions have taken a beating in the security community, Microsoft has made each version of the extensions progressively more secure. Securing FrontPage Server Extensions is possible, but you must first understand what they are and how they work.
What are FrontPage Server Extensions?
FrontPage Server Extensions enhance Web servers to permit Web authors to remotely manage and publish Web sites. The FrontPage designer works directly with the server extensions to upload files, connect to data sources, and change Web permissions. The extensions have a runtime component that enables advanced features, called WebBots, which handle tasks such as form posting, discussion pages, and content linking. Many Web-hosting providers use FrontPage Server Extensions so that their customers can easily publish a FrontPage Web (i.e., the collection of HTML pages, images, documents, and other files that make up a Web site).
When you install FrontPage Server Extensions on a Web site hosted on a Windows server, the software consists of three binary files—admin.dll, author.dll, and shtml.exe—that implement administration, authoring, and runtime components, respectively. Depending on the software version, the .dll files might have .exe extensions and the .exe file might have a .dll extension. In IIS, you can specify either extension because the fpexedll.dll Internet Server API (ISAPI) filter translates requests to point to the correct location. The three binary files reside in the _vti_bin virtual directory, which is physically mapped to C:\program files\common files\microsoft shared\web serverextensions\40\isapi (or C:\program files\common files\microsoft shared\web serverextensions\50\isapi, if you're running FrontPage Server Extensions 2002). All FrontPage Webs have a virtual directory mapped to this path. FrontPage communicates with a Web server by sending HTTP POST requests to these FrontPage Server Extensions binary files. The body of the POST request contains special commands (called vti_rpc commands) that instruct the server to take certain actions.
But FrontPage Server Extensions aren't only for FrontPage users. Many other Microsoft technologies—including Web Folders, Office Web publishing, and SharePoint Team Services—are also tightly integrated with FrontPage Server Extensions. The software even includes an ADO driver that queries FrontPage Webs. Clearly, FrontPage Server Extensions are an important component of Microsoft's Web strategy and will likely be around for a while.
Heed the Risks
Although Microsoft has greatly improved FrontPage Server Extensions security since the product's first release, FrontPage Server Extensions still increase a Web server's exposure to attack. For example, FrontPage Server Extensions provide a point of entry into a Web server. If you use FrontPage to connect to a Web server, the software prompts you for a password. Password protection is always beneficial, but it gives intruders an opportunity to guess that password. Attackers can easily script a brute-force attack to try hundreds or thousands of common passwords. If the intruders compromise the password, they can use FrontPage Server Extensions to modify Web content. And setting a lockout policy for accounts doesn't help much because then the brute-force attack potentially becomes a Denial of Service (DoS) attack, locking out legitimate user accounts.
Another problem with FrontPage Server Extensions is that someone might use them to gather information about a server. A properly configured HTTP POST request sent to shtml.exe can reveal the FrontPage Server Extensions version, the Web server software and version, the OS platform, the name of the anonymous Web user account, and the names of FrontPage Webs. Although this information itself isn't sensitive, an attacker might use it to facilitate other attacks.
Because all FrontPage Server Extensions commands are issued as POST data to the various FrontPage Server Extensions binary files, the IIS logs show only a series of POST requests for these binary files. The system doesn't record the actual submitted _vti_rpc commands. You can configure FrontPage Server Extensions to log authoring actions (not enabled by default), but these logs don't always show the commands' individual parameters. For example, if an administrator changes a FrontPage Web setting, the log shows an entry for set service meta-info, which specifies that something has changed but doesn't show exactly which setting has changed. Further, you have no control over the log file's location, which is in the _vti_log directory under the FrontPage Web or subweb.
Another significant risk is that FrontPage Server Extensions run in process with IIS (inetinfo.exe); both entities run in the security context of the SYSTEM account. Thus, any FrontPage Server Extensions vulnerabilities (e.g., buffer overruns) might permit an attacker to gain full system access.
A final FrontPage Server Extensions risk is that you don't get to decide where to install them. Typically, you should avoid placing your Web directories on the same partition as your system files; the separation helps prevent an attacker from traversing the file system and accessing sensitive system files. However, FrontPage Server Extensions' _vti_bin virtual directory resides on the system partition, ignoring the benefits of a separate Web partition. Furthermore, the _vti_bin virtual directory is marked Executable, so it's potentially vulnerable to attacks such as those that the Nimda worm uses.
Understanding FrontPage Server Extensions Security
The FrontPage Server Extensions security model integrates IIS and NTFS security. A FrontPage Web has three basic access permissions: Browse, Author, and Administer. Granting a user Browse access means that the person has access to view the FrontPage Web site. Granting a user Author access means that the person can upload and modify FrontPage Web files. If you grant a user Administer access, the person can change FrontPage Web settings. Note that FrontPage Server Extensions 2002 have two additional authoring roles—Advanced Author and Contributor—and let you create custom roles with selected rights.
The NTFS ACL setting on the FrontPage Web's root directory determines the privileges. If a user has NTFS Read permissions on the root directory, the user can browse the directory. Any user with NTFS Write permissions can author a FrontPage Web. To administer a FrontPage Web, a user must have Modify permissions on the FrontPage Web's root directory. Note that these are the NTFS permissions, not the Web permissions set in the Internet Services Manager (ISM) console.
The authentication process starts when a FrontPage client sends a POST request to either author.dll or admin.dll. Interestingly, these two files are the same file with different names. FrontPage Server Extensions use the wording of the file to partially determine which actions are permitted. After the client sends the POST request, IIS first checks the FrontPage Web's root directory to determine whether the anonymous user account has the proper permissions for the requested action. If not, IIS asks the user to authenticate with a username and password. After the user submits the username and password, the server extensions again check the root directory to determine whether the user has proper permissions. If FrontPage Server Extensions authenticate the user, they then impersonate that user for Web authoring or administration.
One common mistake is to either have the wrong permissions set on the FrontPage Web root directory or have the root directory located on a FAT partition. Versions of FrontPage Server Extensions earlier than FrontPage Server Extensions 2000 use a slightly weaker security model and have no password by default. FrontPage Server Extensions 2000 use a stronger model and don't use blank passwords by default, but you'll sometimes see the permissions changed on the root directory to grant everyone Write permissions. Such permission modification is particularly common on development systems in which security isn't always a high priority. If the IUSR_machinename (where machinename is the server's name) account has Write permission to the root directory, anyone connecting to FrontPage Server Extensions is automatically authenticated and has full access to author or administer the FrontPage Web. Also, because FrontPage is totally dependent on NTFS permissions, FrontPage Server Extensions installed on a FAT partition permit everyone full access to all FrontPage Server Extensions administrative functions because FAT partitions don't let you restrict access permissions on files.
When you use FrontPage Server Extensions, remember to check your configuration by attempting to connect to your FrontPage Web site from another location. If the system doesn't prompt you for a password, you need to double-check your permissions.
10 Steps to Secure FrontPage Server Extensions
When you secure server extensions, consider a strategy that involves multiple layers of protection. Your server configuration and security policy largely determine the number of layers and complexity of your strategy. Below is a list of 10 steps you can take to build a FrontPage Server Extensions security strategy. Implement as many steps as are feasible in your organization.
- Secure user accounts. Use clearly defined user roles. Carefully assign Web authoring and administration to specific user accounts or groups. Give each account strong passwords, and ensure that multiple users don't share an account. To prevent brute-force attacks, rename the Administrator account something less obvious. Carefully consider the effects of your account-lockout policy.
- Set proper permissions. Make sure the FrontPage Web's root directory doesn't inherit NTFS permissions from its parent directory, then ensure that the anonymous user account doesn't have NTFS Write permissions on any FrontPage Web content. Remove NTFS Execute permissions from the FrontPage Server Extensions _vti_bin directory's subdirectories, but mark each individual file as Executable. Doing so lets the FrontPage Server Extensions binary files execute but prevents new files placed in those directories from executing. You should also specifically deny the anonymous user account the ability to write to the FrontPage Server Extensions binary directories. In ISM, check the IIS permissions on any directory that begins with _vti or _private to ensure that none have the Read box selected. However, one exception is that the _vti_bin directory (and its subdirectories) should be the only FrontPage Server Extensions directory with IIS Execute permissions.
- Modify the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\All Ports registry subkey. See Table 1 for the recommended values.
- Keep your software sufficiently patched. Make sure that you always have the latest version of FrontPage Server Extensions and your OS is always updated with the latest service packs and hotfixes. Although FrontPage Server Extensions 2000 updates are included in Windows 2000 service packs, you need to download FrontPage Server Extensions 2002 hotfixes separately from http://msdn.microsoft.com/library/en-us/dnservext/html/fpse02win.asp.
- Use Secure Sockets Layer (SSL) for authoring. Whenever possible, require the use of SSL for FrontPage Server Extensions access.
- Enable logging. In the Web site's Properties dialog box, go to the Server Extensions tab and select the Log authoring actions check box, as Figure 1 shows. (The server properties are accessible by right-clicking the computer name in ISM and selecting Properties.) Regularly review and archive the log files that reside in the _vti_log directory of each FrontPage Web.
- Set IP restrictions on FrontPage Server Extensions directories. In ISM, right-click each directory that begins with _vti and set IP address restrictions to limit access to these files. If you're using FrontPage Server Extensions 2002, also set IP restrictions on the Microsoft
- Create a mirror site for FrontPage access if you want access to FrontPage Server Extensions from your internal network but don't want them visible to the world. To create a mirror site, add a new site in ISM. Point the new site to the same physical path as your primary Web site. Remove FrontPage Server Extensions (if already installed) from the primary Web site, and install them on the new site. Use any combination of IP restrictions, obscure ports, SSL, and host headers to secure the new site. Note that the old site will still contain some of the _vti directories. Follow Step 7 to restrict access to those directories.
- Disable authoring. In some cases, you might want to use FrontPage's WebBots but not permit remote authoring or administration. Open ISM and access the Web site's Properties dialog box. On the Server Extensions tab, clear the Enable authoring check box, as Figure 2 shows. (Note that if you're using FrontPage Server Extensions 2002, you disable authoring through the SharePoint Administration site.) Finally, clear all permissions and set Execute Permissions to None for both the _vti_aut and _vti_adm directories.
- Move the FrontPage Server Extensions binaries. As I mentioned earlier, placing the binaries on the system partition isn't the safest scenario. Consider moving them to a more secure location. To do so, create a directory on a separate partition and copy the entire contents of the C:\program files\common files\microsoft shared\web serverextensions\40 directory (or C:\program files\common files\microsoft shared\web serverextensions\50 if you're using FrontPage Server Extensions 2002) to the new location. Remember to copy the contents—don't move them. (I recommend keeping a copy of the files in the original location because several FrontPage DLLs have hard-coded references to the default location.)
Open regedit.exe, search the registry for all instances of the old path, and replace them with the new location. Next, download and install MetaEdit 2.2 from the Microsoft Download Center at http://www.microsoft.com/downloads. Use MetaEdit to again search for all instances of the old path and replace them with the new location. Reboot the computer.
To test your changes, create a new FrontPage Web. The server extensions create a _vti_bin directory that points to the new FrontPage Server Extensions location. Remember that after you apply service packs and hotfixes, you must again move these binary files to the new location.
Of course, sometimes you'll simply want to remove FrontPage Server Extensions from your Web sites. To do so, you must first open ISM, right-click each FrontPage Web site, select All Tasks, then select Remove Server Extensions. Next, remove any _vti and _private directories from all Web sites. Finally, edit the master WWW Service properties by right-clicking the computer name in ISM, selecting Properties from the resulting menu, and clicking Edit for the Master WWW Properties. Go to the ISAPI Filters tab, select fpexedll.dll, and click Remove. Close all windows, and FrontPage Server Extensions are now completely disabled for the sites. Note that this process doesn't completely remove FrontPage Server Extensions from your system, so an administrator can reinstall them later.
Remove the Risks
You don't have to remove FrontPage Server Extensions to be secure. Although FrontPage Server Extensions aren't perfect, they aren't inherently unsecure. Although any FrontPage Server Extensions functionality increases a Web server's attack surface, you can greatly reduce your exposure to attack by following the 10 steps to secure FrontPage Server Extensions.
