Solved

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

Posted on 2014-11-07
4
233 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 61

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

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Article by: btan
Provide an easy one stop to quickly get the relevant information on common asked question on Ransomware in Expert Exchange.
Nothing in an HTTP request can be trusted, including HTTP headers and form data.  A form token is a tool that can be used to guard against request forgeries (CSRF).  This article shows an improved approach to form tokens, making it more difficult to…
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

743 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now