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.