Introduction
With the recent disclosure of a chain of vulnerabilities in Microsoft’s Exchange Server resulting in unauthenticated remote code execution, this blog details how an external adversary or local sysadmin can determine if a Windows server has been patched by a specific Microsoft cumulative update, such as those released earlier today.
As part of their commitment to security, Microsoft regularly releases cumulative updates for their software to address security vulnerabilities. However, external actors can only detect the software build number, not the cumulative update number specific to each update. In order to detect if a service has received a security patch or not, an external actor first needs to look up the build number in the patch itself.
Understanding Microsoft build numbers.
Microsoft typically uses 4 digits to determine the software’s patch level. Here are some examples:
Exchange 2019 cumulative update 8:
15.2.792.10
Exchange 2019 cumulative update 7:
15.2.721.13
Exchange 2016 cumulative update 19:
15.1.2176.9
Notice that the first two digits (15.1 vs. 15.2) determine the primary software we are versioning, or the product year in this case (2016 vs. 2019). The last two digits (792.10 or 721.13 or 2176.9) determine the build number. Combining all of these together, makes the version number.
How to get the version or build information?
Knowing how to identify what the version number is updated for the cumulative update patches is hugely important for everyone (Admins, Researchers, Defenders and Attackers, etc..) . Here is how you find out a version number from Microsoft releases:
- Open the cumulative update description & download page from Microsoft (Example)
- Scroll down on the release page to the “File information” section, and you will see a list of the file hashes and the cumulative update patches below the file hashes.
- Expand the tab for the patch you would like to review and you see a list of file information: name, size, date, and version.
- The “File version” is the version for the cumulative update. This is generally safe to use as the cumulative update’s version number, or product + build number.
How can you remotely detect the version?
Outlook Web Access:
This version information is either pulled from the HTTP Response Header value of “X-OWA-Version” or it is taken from the HTTP Content itself from common paths of resources like javascript and images found in the HTML (these paths look like: “…/owa/{version}/theme/…” and include the patch version in them)
Caveats of remote detection:
Remote detections of Microsoft service may only identify three out of the four digits of the server software’s version. (e.g.. detecting 15.2.792.10 as 15.2.792) and cumulative updates do not always update the build version’s third value. This means version based detection will be to some degree, a best guess.
How can a sysadmin detect the build number locally?
If you have local access, you can easily detect the full version number in the file system two ways:
Via PowerShell
Powershell makes it very easy to get the version information from a file. You only need to know the path to the file and use (Get-Info -path ‘C:\path\to\file’).VersionInfo
Via the UI
If you prefer the UI, you can easily search based on the file’s name itself. Open File Explorer and search for a file name you want to check, when the file is found (and on the right path) you just need to right click the file and select “Properties…” to get the version information from the “Details” tab.
How can I check my exposure?
Customers running Randori Recon can check their current exposure instantly by viewing the Services page to see if any Microsoft Exchange targets have been detected on their perimeter. If you’re not a customer, but are concerned about your exposure – request a free recon report of your attack surface.
This blog is part of our TTP series (Tools, Techniques & POCs) focused on sharing tips & tricks learned from inside the Randori Hacker Operations Center.
