Update May 22, 2019
This is an enterprise only search, but querying Censys raw data, we find Sharepoint running on non-standard ports. We analyzed the raw server headers that we collect on our 1000 ports data and searched for the vulnerable version strings, and also the service name Microsoftsharepointteamservices. By including our 1000 port banner data in our search in this update, we found 35% more vulnerable SharePoint hosts! Here is an example of the query:
SELECT ip, SAFE_CAST(s.banner AS String), s.port_number FROM censys-io.ipv4_banners_public.current, UNNEST(services) as s WHERE REGEXP_CONTAINS(SAFE_CAST(s.banner AS String), r".[Mm]icrosoftsharepointteamservices:.(16.0.0.4351|15.0.0.4571|14.0.0.7015|16.0.0.10337).*")
Recently we came across a blog post from AlienVault describing in-the-wild exploitation of a known Sharepoint vulnerability, CVE-2019-0604. We wanted to estimate how widespread this vulnerability is, how much of an attack surface it presents, and how we might figure out who is at risk.
Sharepoint is Microsoft’s flagship collaboration suite and is used for all sorts of things in enterprises, especially sensitive corporate files. As such, Sharepoint is typically used by large organizations who are often targeted because of the high-value of their data.
In this post, we explore how to map a vulnerability to software found on the Internet “in the wild.” Sharepoint, in particular, uses product names like “Sharepoint 2019,” making it quite easy to track in our scans.
Step 1 – Search by Keyword
One of the best places to start your search for a software vulnerability is to start with a simple keyword search — in this case: Sharepoint. This keyword search shows the results for every field we scan for anything that matches — web pages, DNS names, etc. About 20,500 servers show on the results page for the “Sharepoint” keyword search. This gives us a good starting place, but isn’t showing us the list of the Sharepoint software versions affected by this vulnerability.
After exploring the data on about a dozen or so hosts from these results, I was able to discover that Sharepoint has a couple of Sharepoint-specific HTTP headers visible in Censys: x-sharepointhealthscore and microsoftsharepointteamservices. These headers appear to be seen only on legitimate Sharepoint hosts. This data point, then, can serve as our pivot to step 2.
Step 2 – Search by Field
Now that we have our product-specific HTTP header field, let’s search by index over HTTPS and HTTP:
443.https.get.headers.unknown.key: microsoftsharepointteamservices OR 80.http.get.headers.unknown.key: microsoftsharepointteamservices
This search results in about 35,000 hosts — this is actually an increase in results from step 1, but that’s okay since we have more confidence in this approach than simple keyword searching. Now we want to see if there’s a version number or two we can search for. Microsoft’s site reports the following versions are vulnerable to this attack: Microsoft SharePoint Enterprise Server 2016, Microsoft SharePoint Foundation 2010 Service Pack 2, Microsoft SharePoint Foundation 2013 Service Pack 1, Microsoft SharePoint Server 2010 Service Pack 2, Microsoft SharePoint Server 2013 Service Pack 1, and Microsoft SharePoint Server 2019.
Armed with this information, we go inspecting some hosts and seeing what the server tells us — remember, we’re using its advertised version string to inform us if it’s vulnerable. Now we see values for this key like ‘14.0.0.7123’ and ‘15.0.0.4599’ – these certainly don’t look like the product versions Microsoft tells me are vulnerable, how can I map these back to vulnerable populations?
Step 3 – Searching by Joined Fields
After some search engine queries I found this blog post from a Sharepoint enthusiast or professional that maps Sharepoint product friendly names to release versions. Using this information to map the reported versions from MSRC to build numbers, I construct a query like this:
443.https.get.headers.unknown.key: microsoftsharepointteamservices AND (443.https.get.headers.unknown.value: "16.0.4351.1000" OR 443.https.get.headers.unknown.value: "15.0.4571.1502" OR 443.https.get.headers.unknown.value: "14.0.7015.1000" OR 443.https.get.headers.unknown.value: "16.0.10337.12109")
And I get no hits. What gives, I think, so I go digging some more. It turns out the build number is similar to but not quite identical to the header versions from that blog post. I have to tailor them a bit — drop the last value (maybe a build number appended to the product number?) and insert another 0 in the middle. I end up with a query like this:
443.https.get.headers.unknown.key: microsoftsharepointteamservices AND (443.https.get.headers.unknown.value: "16.0.0.4351" OR 443.https.get.headers.unknown.value: "15.0.0.4571" OR 443.https.get.headers.unknown.value: "14.0.0.7015" OR 443.https.get.headers.unknown.value: "16.0.0.10337")
That looks great! About 800 or so servers worldwide externally visible that are vulnerable to this attack. After some fine tuning to include 80/HTTP I get this query:
(443.https.get.headers.unknown.key: microsoftsharepointteamservices AND (443.https.get.headers.unknown.value: "16.0.0.4351" OR 443.https.get.headers.unknown.value: "15.0.0.4571" OR 443.https.get.headers.unknown.value: "14.0.0.7015" OR 443.https.get.headers.unknown.value: "16.0.0.10337")) OR (80.http.get.headers.unknown.key: microsoftsharepointteamservices AND (80.http.get.headers.unknown.value: "16.0.0.4351" OR 80.http.get.headers.unknown.value: "15.0.0.4571" OR 80.http.get.headers.unknown.value: "14.0.0.7015" OR 80.http.get.headers.unknown.value: "16.0.0.10337"))
Which results in a final count of about 1600 Sharepoint servers worldwide vulnerable to this attack.
Key Takeaway
While this latest Sharepoint vulnerability does pose a threat to some organizations, it isn’t a global Internet meltdown. If you find that any of your servers are included in the list of vulnerable hosts, make sure that you patch them using the instructions Microsoft included in their security update.
For similar articles on how to find vulnerabilities, particularly in your own organization, check out our post on Apache security issues. For those interested in hunting for new and emerging threats, take a look at our post on how to track the Mirai Botnet.
