A Web site based on SharePoint Team Services from Microsoft is built on top of both the Microsoft FrontPage Server Extensions — this introduction from Microsoft article on SharePoint sounds quite scary in the beginning, if you know security history of FrontPage extensions. FrontPage Server Extensions was written in the very beginning of Microsoft’s adventures on Internet and was known to be notoriously insecure. Article by sozni titled FrontPage webfolders from 1999 presented a detailed description of FPSE insecure configurations at that time. As result, FPSE tends to be still reported as insecure by Metasploit and other, commercial scanners. Why would we expect FPSE to still appear on production servers in 2013? Well, it’s still there, as part of SharePoint installations, as the article cited above explains.
Remains of FPSE in SharePoint are still present these URLs, to which SharePoint still responds with if queried with FrontPage API:
/_vti_bin/shtml.dll/_vti_rpc
/_vti_bin/_vti_aut/author.dll
/_vti_bin/_vti_adm/admin.dll
There’s one significant difference between old FPSE and SharePoint:
/_vti_inf.html
It is no longer present on SharePoint servers. This is why Metasploit’s frontpage_login will not detect FPSE on target SharePoint server. The information is not completely gone though, as you can discover FPSE version by GET request to:
/_vti_pvt/service.cnf
The main problem with the old FPSE is that the default setting was to allow everyone to edit files. Another scanner I’ve tried (AppScan) checks the vulnerability by trying to access the files mentioned above and implying that if the HTTP code is 200 OK, then the vulnerability is present. But this seems to be not enough with SharePoint.
Even if you can access them but try to repeat the FPSE conversation with correct version number, it will fail — at least this was what happened on a standard SharePoint server that I tested. The server would require NTLM authentication prior to any call to FPSE methods — which is exactly how it should work (you can use attached Python script to check that – it requires requests library).
This seems to be consistent with what Paul Stork (MVP) has posted in one of the MSDN forums:
Your thinking of security flaws in the older versions. You don't need to set these files to any more restrictiver pemissions than the ones set by SharePoint when it installed them. Although the internal names are still the same these aren't the same as the old Front Page server extensions you are used to.
And this seems to be true. It’s however interesting how many questions are there on forums from SharePoint owners concerned about security scanners reporting FPSE on their servers — and there seems to be no clear response from Microsoft on that topic.