Is FrontPage Server Extensions vulnerable in SharePoint 2013?
If you have never performed vulnerability assessment using any tools, you are going to be surprised what the FrontPage Server Extensions means to SharePoint at least from the tittle and why it’s part of the assessment vector. If you see it one day in an assessment report when you are responsible for SharePoint security, you wouldn’t manage to easily remediate the issue or justify your security team. You could call Microsoft for a question but it’s not that just easy to do so almost time. What I’m going to share in this this article might show you the light at the end of the tunnel if you are stuck in whether fixing FrontPage Server Extension (FPSE) related vulnerability or justifying your security team.
Disclaimer: this article doesn’t provide you actual fix for the FPSE related issue or an official justification. The best way anyway is to call Microsoft support if you can’t convince your security team.
If you don’t know Microsoft FrontPage and Microsoft FrontPage Server Extensions, read the following articles:
What is detected?
When SharePoint 2013 is installed by default, there are two folders in which each name gives the assessment tool the sign of the FrontPage structure: _vti_bin and _vti_pvt. The _vti_bin folder contains several folders and built-in SharePoint web services. For example, you can see many web services for administrative tasks in the _vti_adm folder. The _vti_pvt contains files that show you current SharePoint version and its build when browsed. With that sign, the tool likely thinks that SharePoint 2013 still uses legacy FrontPage that is notoriously vulnerable historically. There are numerous vulnerability reports related to FrontPage you can quickly find from Google. There are the following URLs virtually detected after you run the assessment tool:
- contoso.com/_vti_bin/_vti_adm/(*) (the list of many URLs starting with this prefix)
- contoso.com/_vti_bin/_vti_aut/(*) (the list of many URLs starting with this prefix)
However, if you browse http://contoso.com/_vti_inf.html, you will see the blank page but its HTML source code contains some FrontPage configuration information. You even couldn’t find this file in SharePoint directory source.
What is reported?
Basically the assessment tool performs a GET method to crawled URLs and waits for response. If it receives something it thinks critical or sign of vulnerability, it will definitively repot. There are potential reasons as to why the tool reports about FPSE
- By the structure detected, your system is using FPSE that is said to be insecure almost time so far
- Disclosure of SharePoint version (_vti_pvt/service.snf)
- Disclosure of FrontPage Configuration Information (_vti_inf.html)
If you use HP WebInspect, the report will look like as follows:
The service.cnf file was found in the _vti_pvt directory on a system running Microsoft FrontPage Server Extensions. This file contains meta-information about the web server. An attacker could submit a request for the vulnerable file and cause the server to reveal sensitive system information. The attacker could use this information to launch further attacks against the affected host. Recommendations include removing this file from the system if it is not needed, or tightening the default permission settings.
If the tool uses directory enumeration scan, it may indicate that FrontPage allows remote users to upload and modify web site content. Historically, attackers seek out FrontPage sites since FrontPage is often misconfigured to not require authentication.
Another tool (IBM AppScan) even recommends you to upgrade the latest FrontPage version available. Anyway almost tools state that your system is potentially vulnerable with the existing FPES. The disclosure of configuration information needs to be restricted to authorized people.
What to do then?
Ironically there is no official statement from Microsoft saying that FPES is the last version or significantly improved from the security perspective. You could explain that SharePoint requires FrontPage Remote Procedure Call (RPC) and to allow legacy software to connect. FrontPage RPC is implemented by both FrontPage Server Extensions and by Windows SharePoint Services that is foundation of the SharePoint platform. This reference (FrontPage Server Extensions RPC Protocol) provides you a list of methods that requires FPSE RPC protocol (e.g. check-in document). Although it’s written for SharePoint 2010, it’s still true for SharePoint 2013.
Paul Stork – an internationally renowned SharePoint expert commented in the MSDN thread that you could use as an explanation:
That’s because SharePoint and SharePoint Designer are built on the foundation of the original FrontPage Server Extension. Note however that the version number is 14, which is in keeping with SharePoint 2010. They just didn’t change the internal naming as they enhanced the product.
If your SharePoint is anonymously accessible, you need to consider implementing authorization rule to restrict access to web services under _vti_bin, or at least prevent attacker from accessing to gain SharePoint version or FrontPage configuration information (_vti_inf.html). I’m not sure how the attacker utilizes the configuration information to exploit your SharePoint but it’s much better if you restrict access to all of them. See the sample code snippet to restrict _vti_inf.html
<location path="_vti_inf.html"> <system.web> <authorization> <deny users= "?" /> <allow users = ”*” /> </authorization> </system.web> </location>
The asterisk mark (*) represents authenticated user and the question mark (?) represents anonymous user. This post (Restricting access to SharePoint 2013 web services) does give you more details.
Since FPES is still a nightmare, the best way I’d highly recommend you is to call Microsoft in case you can’t justify the harmlessness of FPES in SharePoint 2013 reported by vulnerability assessment tool. Even when you call, it’s still pretty hard for Microsoft to fully protect you. They may say that information found is sent in the header of all HTTP requests to the server so having access to this file does not warrant a Configuration Disclosure. As a result, there would be an everlasting debate between you (or Microsoft) with your security team. C’est la vie!
Additional helpful references: