Exchange Build Nummer ermitteln
Wer einen Exchange Server betreibt, muss natürlich auch Updates einspielen. Die Frage ist dabei aber, wie sie die "richtige" Versionsnummer finden. Es gibt wenige "offizielle" Versionen aber Angreifer interessieren sich natürlich auch für andere Optionen.
Mit dem Security Update Juli 2021 hat Microsoft endlich einen offiziellen Weg zur Ermittlung der aktuell installierten Version veröffentlicht. Siehe Verifikation Analyse per AutoD.
Übersicht
Auf der Seite Exchange und Outlook Build Nummern versuche ich die Versionsnummern aktuell zu halten. Aber auch Microsoft hat eine Liste, die Exchange Versionen mit ihrer Build-Nummer aufführt.
- Exchange Server – Buildnummern und
Veröffentlichungstermine
https://docs.microsoft.com/de-de/exchange/new-features/build-numbers-and-release-dates
Die folgenden Analysen habe ich mit einem Exchange 2016 Server am 17. Mai 2021 erstellt, der das zu der Zeit aktuelle CU20 und letzte Security Updates vom 11 Mai 2021 installiert hatte.
Die korrekte Build-Nummer wäre daher 15.1.2242.10
Folgende Wege habe ich betrachtets:
| Weg | Ergebnis | Beschreibung |
|---|---|---|
OK |
Diese URL ist bei meist allen Exchange extern erreichbar. |
|
Zwei Klicks |
Wenn der Admin in der Liste der Software und der Update-Liste die richtigen Einträge lesen kann, dann sieht er schon die aktuell installierte Version. |
|
Eingeschränkt |
Über diese Schnittstellen ist die aktuell installiert Version nicht einfach ermitteln |
|
Eingeschränkt |
Über diese Schnittstellen ist die aktuell installiert Version nicht einfach ermitteln |
|
Nur CU |
Über diese Schnittstellen ist nur die installierte CU-Version zu ermitteln aber das Security Update wird nicht angezeigt. |
|
| Registrierung | Je Komponente |
Das Exchange Setup protokolliert die Version der installierten Komponenten in der Registrierung. Allerdings gibt es keine "Major"-Version, auch wenn man das für "Setup/OwaVersion" vielleicht annehmen könnte. |
OK |
Solange jedes Security Update auch einen neuen Ordner anlegt, kann damit die höchste Version ausgelesen werden. Bislang gab es immer eine neue Datei. |
|
OK |
Seit dem Security Update vom Jul 2021 soll die Fileversioninfo der exsetup.exe den aktuellen Build-Level wiedergeben |
|
OK |
Diese URL ist bei vielen Exchange OWA-Zugängen extern erreichbar. |
|
OK |
Diese URL liefert die genaue Version in einer XML-Datei auf eine anonyme Anfrage. Um einem externen Angreifer den diese Information vorzuenthalten, sollten Sie /ECP nicht aus dem Internet erreichbar machen. |
|
Nur CU |
Über diese Schnittstellen ist nur die installierte CU-Version zu ermitteln aber das Security Update wird nicht angezeigt. |
Achtung: Die korrekte Anzeige an den verschiedenen Stellen gibt nur, wenn Sie die Installation korrekt als Administrator durchgeführt haben. Wer Updates
Analyse per AutoD (Ab Jul 21)
Der Zugriff auf Autodiscover ist eine der grundlegenden Funktionen von Exchange, damit Clients den Weg zu ihrem Server finden. Daher ist es fast immer möglich, diese URL von extern anzusprechen.
Mit dem Security Update Juli 2021 hat Microsoft endlich einen offiziellen Weg zur Ermittlung der aktuell installierten Version veröffentlicht. Siehe Verifikation auf Patchday Jul 2021
Interessant ist natürlich immer ein Weg, die Version über einen Netzwerkzugriff, idealerweise sogar anonym, zu ermitteln. So können Sie als Administrator sehr schnell prüfen, ob die Exchange Server aktuell sind. Das geht seit Juli 2021 sogar sehr zuverlässig. Vorher haben wir immer nur "Schätzungen" erhalten. Per PowerShell ist es sehr einfach, die Version eines Exchange Servers anonym zu ermitteln.
PS C:\> (Invoke-WebRequest https://autodiscover.msxfaq.de/autodiscover/autodiscover.xml -SkipCertificateCheck -SkipHttpErrorCheck).headers."X-OWA-Version" 15.1.2242.12
Die komplette URL funktioniert meist sehr gut aber es gibt auch Fälle, wo sie keine Antwort oder eine falsche Antwort bekommen:
- Firma nutzt kein Exchange
Es werden immer weniger aber ja, es gibt Firmen, die andere Messagingsysteme nutzen. - IP-Beschränkungen
Sie funktioniert nur dann nicht, wenn die Firma eine Auflösung per Autodiscover von extern auf bestimmte IP-Adressen, z.B. Exchange Online oder erst mit einem VPN erlaubt. - Inspection Firewall
Wie ein gültiger "Autodiscover"-Request aussieht, ist von Microsoft dokumentiert. WebApplication Firewalls könnten so einen einfachen Request blockieren. Ich habe mir hier nicht die Mühe gemacht, einen kompletten Autodiscover-Request zu formulieren. - Autodiscover nicht auflösbar
Das kann z.B. intern der Fall sein, wenn die Clients per LDAP den Autodiscover-SCP ermitteln. Wobei das in Zeiten von Skype for Business, Konferenzsystemen und 3rd Party Produkten eher ungewöhnlich wäre.
Auch wenn Sie daher von extern eine ihnen unbekannte Firma "beproben" können, funktioniert der Test vor allem intern gegen alle vorhandenen Server. Von Extern prüfen Sie eh nur die Frontend-Server.
Analyse per OWA
Anstelle von Autodiscover können Sie auch versuchen, den Outlook Web Access zu finden. Häufige Namen sind schon "owa.<maildomain>", "webmail.<maildomain>" oder "outlook.<maildomain>. Nur wenige Firmen trennen aber den Zugang komplett von Autodiscover ab, so dass Sie auch testweise einfach mal in die SAN-Einträge des Autodiscover-Zertifikats schauen können, welche weiteren URLs es noch bereitstellt.
Kritischer wird es, wenn so einen Anfrage auch von extern "anonym" möglich ist und damit auch Angreifer schnell ermitteln können, auf welchem Stand ihr Exchange Server ist.
Eine interessante Quelle sind hier durchaus Webserver-Logs. Selbst auf der statischen Seite der MSXFAQ finden sich solche "Treffer".
192.241.206.19 - - [12/May/2021:07:43:53 +0200] "GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1" 404 2857 "-"
"Mozilla/5.0 zgrab/0.x" "178.77.117.98"
192.53.161.117 - - [12/May/2021:16:07:08 +0200] "GET /owa/ HTTP/1.1" 404 2857 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
"178.77.117.98"
Der erste Abruf ist sicher zumindest ein "Probing" während der zweite Aufruf eher auf eine Firma zurück geht, die Sicherheitslücken sucht. Über die erste URL bekommt der externe anonyme Client an die Anmeldeseite und diese enthält eine Version. Hier die Powershell-Version
$owalogin=(Invoke-WebRequest https://outlook.msxfaq.de/owa/auth/logon.aspx -SkipHttpErrorCheck -SkipCertificateCheck)
$owalogin.Content.Substring($owalogin.Content.IndexOf('<link rel="shortcut icon" href="/owa/auth/')+42,16).split("/")[0]
15.1.2242
Ich bekomme über den Weg zumindest den CU-Level heraus. Allerdings sehe ich so noch nicht den Servicepack-Level.
Analyse per ECP
Interessanter ist da schon eher die URL, die jemand aus dem Internet gegen meine Webseite versucht hat. Er hat den folgenden Pfad angesprochen.
https://outlook.msxfaq.de/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application
Diese URL ist tatsächlich anonym erreichbar und liefert eine XML-Datei mit einer Versionsnummer zurück. Per PowerShell können Sie damit sehr einfach dann eine Version ermitteln.
# Get-ExchangeVersion über ECP $versionxml=Invoke-WebRequest https://outlook.msxfaq.de/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application ([xml][System.Text.Encoding]::ascii.GetString($versionxml.content[3..($versionxml.content.count)])).assembly.assemblyIdentity.version 15.1.2242.10
Hier sehe ich zumindest auf meinem Exchange 2016 CU20 Server mit 11.Mai SecUpdates die komplette Versionsnummer.
Da ist ein deutlicher Weckruf, dass Sie die "/ECP"-Url nicht aus dem URL erreichbar machen soll.
Interessanterweise ist die URL auch mit Exchange Online erreichbar.
$versionxml=Invoke-WebRequest https://outlook.office365.com/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application ([xml][System.Text.Encoding]::ascii.GetString($versionxml.content[3..($versionxml.content.count)])).assembly.assemblyIdentity.version 15.20.4150.17
Interessant, dass hier die Version schon viel weiter ist.
Systemsteuerung
Ein Blick in die Systemsteuerung zeigt zuerst einmal das installierte CU20.
Die hier angezeigte Version 15.1.2242.4 verweist auf das CU20 ohne Security update. Das Security Update finden Sie erst nach dem Klick auf "View installed updates".
Insofern ist das etwas unschön, dass Security Updates nicht schon in der ersten Ansicht die Build-Nummer aktualisieren.
WMI und CIM
Was per GUI erreichbar ist, kann ich auch per Skript, hier eben PowerShell, auslesen:
Get-WmiObject win32_product
# Auszug des Eintrags für Exchange. P
PS C:\> $a[15] | fl *
PSComputerName : EX2016
Name : Microsoft Exchange Server
Version : 15.1.2242.4
InstallState : 5
__GENUS : 2
__CLASS : Win32_Product
__SUPERCLASS : CIM_Product
__DYNASTY : CIM_Product
__RELPATH : Win32_Product.IdentifyingNumber="{CD981244-E9B8-405A-9026-6AEB9DCEF1F1}",Name="Microsoft Exchange
Server",Version="15.1.2242.4"
__PROPERTY_COUNT : 27
__DERIVATION : {CIM_Product}
__SERVER : EX2016
__NAMESPACE : root\cimv2
__PATH : \\EX2016\root\cimv2:Win32_Product.IdentifyingNumber="{CD981244-E9B8-405A-9026-6AEB9DCEF1F1}",Name=
"Microsoft Exchange Server",Version="15.1.2242.4"
AssignmentType : 1
Caption : Microsoft Exchange Server
Description : Microsoft Exchange Server
HelpLink :
HelpTelephone :
IdentifyingNumber : {CD981244-E9B8-405A-9026-6AEB9DCEF1F1}
InstallDate : 20210512
InstallDate2 :
InstallLocation :
InstallSource : F:\
Language : 1033
LocalPackage : C:\Windows\Installer\3697c12b.msi
PackageCache : C:\Windows\Installer\3697c12b.msi
PackageCode : {3294467A-71B2-4DB8-9C59-018ABE3A7FDA}
PackageName : EXCHANGESERVER.msi
ProductID :
RegCompany :
RegOwner :
SKUNumber :
Transforms :
URLInfoAbout :
URLUpdateInfo :
Vendor : Microsoft Corporation
WordCount : 0
Scope : System.Management.ManagementScope
Path : \\EX2016\root\cimv2:Win32_Product.IdentifyingNumber="{CD981244-E9B8-405A-9026-6AEB9DCEF1F1}",Name=
"Microsoft Exchange Server",Version="15.1.2242.4"
Options : System.Management.ObjectGetOptions
ClassPath : \\EX2016\root\cimv2:Win32_Product
Properties : {AssignmentType, Caption, Description, HelpLink...}
SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers : {dynamic, Locale, provider, UUID}
Site :
Container :
Das Security Update ist nicht zu finden. Auch die alternative Funktion über CIM liefert nur die gleiche Liste.
Get-CimInstance win32_product
Insgesamt habe ich auf dem Server 225 Produkte gefunden. Nicht alle waren mit Exchange verbunden.
Registry Software
Die auf einem System installierten Produkte finden sich natürlich auch in der Registrierung.
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* ` | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate ` | Format-Table –AutoSize DisplayName DisplayVersion Publisher ----------- -------------- --------- Microsoft Exchange Server 2016 Cumulative Update 20 15.1.2242.4 Microsoft Corpor... Security Update for Exchange Server 2016 Cumulative Update 20 (KB5003435) 1 Microsoft Corpor... Microsoft Unified Communications Managed API 4.0, Runtime 5.0.8308.0 Microsoft Corpor... Microsoft Exchange Server 15.1.2242.4 Microsoft Corpor... Microsoft Exchange Speech - (en-US) 15.1.2242.4 Microsoft Corpor... Microsoft Exchange 2007 Enterprise Block List Updates 3.3.4604.001 Microsoft Corpor... Microsoft Exchange Server Language Pack - Chinese (Traditional) 15.1.2242.4 Microsoft Corpor... Microsoft Exchange Server Language Pack - German 15.1.2242.4 Microsoft Corpor... Microsoft Exchange Server Language Pack - English 15.1.2242.4 Microsoft Corpor... ... Microsoft Exchange Client Language Pack - German 15.1.2242.4 Microsoft Corpor... Microsoft Exchange Client Language Pack - English 15.1.2242.4 Microsoft Corpor... ...
Interessanterweise habe ich über den Weg nur 199 Einträge statt 225 Einträge erhalten. Anscheinend gibt es hier ein Inkonsistenz zwischen WMI/CIM und Registrierung. Dafür habe ich hier neben der Exchange Server-Installation mit CU20 auch das Security Update sehe. Allerdings hilft mir die Versionsnummer des Updates nicht weiter.
- Use PowerShell to Find Installed
Software
https://devblogs.microsoft.com/scripting/use-powershell-to-find-installed-software/ - PowerShell: How to get a list of all
installed Software on Remote Computers
https://sid-500.com/2018/04/02/powershell-how-to-get-a-list-of-all-installed-software-on-remote-computers/
Exchange PowerShell
Die Exchange PowerShell hat eigens ein Commandlet um die Exchange Server samt Version auszugeben. Allerdings liefert das Produkt auch nur die CU-Version oder Servicepack aber keine Information über installierte Exchange Security Updates.
# Diese Abfrage liefert nicht ausführliche Informationen [PS] C:\>Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion Name : EX16 Edition : Standard AdminDisplayVersion : Version 15.1 (Build 2242.4)
Insofern ist der Befehl zur Versionsermittlung nicht ausreichend.
Registrierung
Exchange installiert nicht nur jede Menge "Dienste" sondern schreibt auch einige Einstellungen in die Registrierung. Hier ist insbesondere der folgende Schlüssel interessant:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15
Hierunter gibt es sehr viele eigene Schlüssel für unterschiedliche Komponenten und in einigen gibt es sogar eine Version. Ich habe mir hier den Schlüssel "Setup" herausgepickt der die passende Version enthält:
Das ist aber nicht für alle Einträge der Fall, wie die drei Beispiele zeigen
Ob nun der Key "OwaVersion" eine legitime Quelle ist, kann ich nicht sicher sagen.
Dateisystem
Jede neuere Exchange Version mit einer neuen Build-Version addiert auf dem Filesystem in der Regel neue Ordner. Das ist der Kompatibilität zu Backend-Servern geschuldet, da der Frontend-Server je nach Backend den passenden Code benötigt. Hier sehen Sie auf meinem Server die Historie der Installationen.
Dies ist ein Auszug aus dem "/ECP"-Verzeichnis. Ähnliche Verzeichnisse finden Sie auch unter /OWA und anderen Stellen. Wenn ich es aber richtig einschätze, dann greift ein Client nicht direkt auf diese Dateien zu, sondern über den Frontend-Proxy, der sich dieser Dateien bedient.
Ich gehe davon aus, dass "ältere" Versionen nicht mehr erforderlich sind, wenn Sie auf allen Servern in der Topologie entfernt werden und daher keine Rückwärtskompatibilität erforderlich ist.
Eine Software kann z.B. diese Verzeichnisse auflisten und damit die höchste Build-Nummer ermitteln.
- How do I get file version information
from the command line?
https://devblogs.microsoft.com/oldnewthing/20180529-00/?p=98855
Dateiversion
Seit dem Security Update vom Jul 2021 soll die Fileversioninfo der exsetup.exe immer den aktuellen Build-Level wiedergeben: Sie können daher folgendes machen:
PS C:\> (get-item $env:ExchangeInstallPath\bin\exsetup.exe).VersionInfo ProductVersion FileVersion FileName -------------- ----------- -------- 15.01.2242.012 15.01.2242.012 C:\Program Files\Microsoft\Exchange Server\V15\bin\exsetup.exe
Alternativ können Sie auch im Windows Explorer die Dateidetails anzeigen lassen
SMTP-Header
Eine letzte Möglichkeit aus meiner Sicht etwas über die verwendeten Exchange Versionen zu nutzen ist der SMTP-Header. Wenn eine Mail durch einen Exchange Server Transport geht, addiert er einen Header, der auch Rückschlüsse auf die Version zulässt. Eine Testmail zeigt mir, dass ich zumindest das CU sehe aber nicht das Security-Update.
Received: from hybrid.msxfaq.de (192.168.80.3) by hybrid.msxfaq.de (192.168.80.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4; Sun, 07 Mar 2021 22:29:42 +0100 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (104.47.17.110) by hybrid.msxfaq.de (192.168.80.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4 via Frontend Transport; Sun, 07 Mar 2021 22:29:42 +0100
Andererseits kann dieser Wert auch gelogen sein. Wenn ein Security Updates nur die Client Access-Komponenten aktualisiert aber die Transport-Komponenten nicht aktualisiert werden, würde die Version nicht stimmen.
Zusammenfassung
Es gibt ganz viele Optionen aber nur wenige Wege sind wirklich zuverlässig. Die Suche in "Programme" und "Updates" ist per Maus und GUI der sicher einfachste Weg für Administratoren, um den aktuellen Status zu prüfen. Per CIM/WMI lassen sich die Daten auch auslesen, wenngleich man schon nach den Strings suchen muss und keine "Versionsnummer" bekommt. Wenn Sie eine Datei finden, die immer mit aktualisiert werden, wäre das auch ein Weg.
Erst seit dem Juli 2021 hat Microsoft zumindest für Exchange 2013, 2016 und 2019 dokumentiert, dass die Version im HTTP-Header einer Antwort oder die Version der Datei EXSETUP.EXE ein legitimes Kriterium ist.
