Solved

How to determine MS Sharepoint server version / patch level over HTTP

Posted on 2014-11-07
4
310 Views
Last Modified: 2015-12-30
Hello,

I need to confirm a version of a remote Sharepoint server. I understand this can be done by looking at HTTP header as well as the content of /_vti_pvt/service.cnf file.

In the past the server was responding with the following HTTP header:

  GET /SitePages/***
  Host:***
  ...
  HTTP/1.1 200 OK
  MicrosoftSharePointTeamServices: 15.0.0.4420

And /_vti_pvt/service.cnf file contained

  vti_encoding:SR|utf8-nl
  vti_extenderversion:SR|15.0.0.4481

Based on this the owner of the server was advised to upgrade to the latest version to eliminate known security issues.

Now, on a supposedly upgraded server, HTTP header is exactly the same, but /_vti_pvt/service.cnf file contains:

  vti_encoding:SR|utf8-nl
  vti_extenderversion:SR|15.0.0.4641

I have the following questions:

Why different version are reported in these two locations?

Why the verion is reported as 15.0.0.NNNN, while in most documents they are referred to as 15.0.NNNN.MMMM and how to correlate the two?

Thank you.
0
Comment
Question by:gremwell
4 Comments
 
LVL 63

Accepted Solution

by:
btan earned 500 total points
ID: 40429931
Taking example, the version number is 14.0.0.6114, this corresponds to SharePoint 2010 (14) and December 2011 Cumulative Update (6114). In fact, the version is more accurately reads as 14 as the major, 0 as minor, 6114 as build and if there is another appending number, it is the revision.  So it can still be as accurate based on just (major).(minor).(build).(revision).
 
Check out the listing in example and note the various Sharepoint package version inclusion http://blog.fpweb.net/what-sharepoint-version-am-i-using/
http://toddcarter.net/sharepoint-versions/
 
As a whole, the one in http header follow the header not added by SharePoint but rather by IIS, even though it is SharePoint who adds it to IIS. The value is also in the registry so if it is given as  (major).(minor).(build), this will be returned and so far this is the norm default unless it is customised specifically.
 
If you check the Central Administration Web Site you’ll it also have the same exact version value. But it is not always as simple as we understand in a load balanced situation as version may not be readily updated. Check this post where the version is updated based on the login account to perform the upgrade.
 
http://www.wictorwilen.se/sharepoint-mythbusting-the-response-header-contains-the-current-sharepoint-version
Deep down between the zeroes and ones in the SharePoint code there is actually a code snippet that checks if the account running the upgrade is a member of the local Administrators group. If the account is member it will nice and quietly update the IIS metabase with the (file) build number, taken from the current assembly which is Microsoft.SharePoint.dll. But if the user is not a local Administrator (and cannot edit the metabase), the operation is passed on to the WSSAdmin component (running as Local System) which uses another assembly. This assembly is called Microsoft.SharePoint.AdministrationOperation.dll, and the metabase is updated with the (file) build number for that assembly.
So there you have it – you cannot trust this MicrosoftSharePointTeamServices response header as a single source of trust when you need to remotely find out your SharePoint build and version. Even if you keep track of all the specific builds of the administration assembly, since it might not be updated, and you cannot be sure that everyone runs psconfig with the –wait switch.

I shall not really bother with the .cnf as it is still the dll that determine and regardless the build vs revision it should really matters if the patch is done accurately and correctly, (and no foul play of course to manipulate the header).
 
Actually this version embedding into http header is double edge as the adversary will also know about its existing version, it can still be managed so as not to be over revealing. Nonetheless, I understand that if you remove the “MicrosoftSharePointTeamServices” totally SharePoint search will not work. Kind of "chicken and egg" situation.
0
 
LVL 3

Author Comment

by:gremwell
ID: 40440798
Thank you for your response, it clarifies the situation a bit.
Looking at /_vti_pvt/service.cnf seems to be a bit more reliable approach.
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

February 24, 2017 — On February 23, Travis Ormandy, a vulnerability researcher at Google, reported on Twitter (https://twitter.com/taviso/status/834900838837411840) that massive stores of data have been leaked by CloudFlare, a company that provide…
As cyber crime continues to grow in both numbers and sophistication, a troubling trend of optimization has emerged over the last year.
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

765 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question