Citrix XenDesktop XML Broker Port verschlüsseln
Was soll da schon passieren?
Das denken sich wohl viele Admins, wenn es an die Frage geht, ob der XML Port des Delivery Controllers (oder ggf. Cloud Connectors) TLS verschlüsselt werden sollte. Immerhin hat man doch schon den Zugriff auf NetScaler und StoreFront durchgängig mit Zertifikaten gesichert...
Ein Restrisiko bleibt, denn immerhin gehen zwar per default keine Benutzernamen und Passwörter im Klartext über diesen Port, doch die Kommunikation zwischen StoreFront und den Delivery Controllers bzw. Cloud Connectors beinhaltet den Sessionkey für jede ausgehandelte Sitzung.
Und wenn es einem Angreifer gelingt die Obfuskation der Daten (Richtig gelesen, Citrix verschlüsselt hier nicht, sondern lässt die Daten lediglich in anderen Daten "verstecken". Etwa so, wie seine Pin als Telefonnummer getarnt auf die Kreditkarte zu schreiben...mag reichen, oder eben nicht) zu verstehen (fertige Plugins sind im Netz erhältlich), dann könnte dieser Angreifer mit dem Sessionkey eine bestehende Sitzung per Workspace Control oder Reconnect übernehmen.
Problematisch daran könnte sein, dass der Angreifer zwar nun kein Kennwort für das Userkonto hat, aber der User ja bereits angemeldet ist. Sein EMailprogramm läuft, das Datenbank-Frontend mit den Patientendaten ist entsperrt und listet gerade interessante Details eines prominenten Staatsmannes auf. Immerhin denkbar.
Zwei Wege führen prinzipiell nach Rom, also den XML Port zu verschlüsseln.
Weg eins ist simpel, aber nicht immer praktikabel: IIS und XML Port sind auf der gleichen Maschine installiert, über die Absicherung der Standardwebseite gelingt auch die Absicherung des XML Ports - fertig. Wer hier übrigens nicht weiß, wie das geht, darf mich gerne mal in einem Training besuchen... sollte aber zum Standardrepertoire eines Admins gehören.
Weg zwei ist schwieriger - theoretisch. Denn wenn kein IIS anwesend ist (meist besser so), dann muss man das Zertifikat über seinen Thumbprint ("Fingerabdruck" - eine Art Seriennummer) an die AppID der zu verschlüsselnden Anwendung binden. Thumbprint und AppID müssen aus dem Zertifikat bzw. der Registry ausgelesen werden, um danach via NetSH.exe als Parameter benutzt werden zu können - aber auch hierfür müssen sie erst in ein taugliches Format gebracht werden.
So kann man zwar unter HKCR\Software\Installer\Products nach "Citrix Broker Service" suchen, findet dort die benötigte AppID aber nur als lange Hex-Kolonne. Der Befehl NetSH.exe erwartet diese aber später im GUID-Format, also 8-4-4-4-12 Zeichen...
Um dem ganzen den Schrecken zu nehmen, habe ich ein kleines PowerShell Skript geschrieben (warum kommt sowas eigentlich nicht direkt von Citrix, am besten mit einer GUI?), welches ich hier gerne bereitstelle.
Das Skript ermittelt zunächst die passende AppID aus der Registry und bringt sie in das GUID-Format. Dann bestimmt es den Thumbprint des zu verwendenden Zertifikats (hoffentlich vorab installiert), fragt im Fall mehrerer Zertifikate nach, welches verwendet werden soll und führt dann den NetShell-Befehl zum Binden des Zertifikats an die AppID aus.
Abschließend weist es per Registrykey den XML Broker an, Anfragen nicht mehr auf Port 80 entgegenzunehmen.
Achtung, das Skript ist noch sehr roh, es sind keine Fehlerbehandlungen darin und nur wenig Logging. Ich rate daher zu den üblichen Vorsichtsmaßnahmen.
Wohl bekomms!
Das denken sich wohl viele Admins, wenn es an die Frage geht, ob der XML Port des Delivery Controllers (oder ggf. Cloud Connectors) TLS verschlüsselt werden sollte. Immerhin hat man doch schon den Zugriff auf NetScaler und StoreFront durchgängig mit Zertifikaten gesichert...
Ein Restrisiko bleibt, denn immerhin gehen zwar per default keine Benutzernamen und Passwörter im Klartext über diesen Port, doch die Kommunikation zwischen StoreFront und den Delivery Controllers bzw. Cloud Connectors beinhaltet den Sessionkey für jede ausgehandelte Sitzung.
Und wenn es einem Angreifer gelingt die Obfuskation der Daten (Richtig gelesen, Citrix verschlüsselt hier nicht, sondern lässt die Daten lediglich in anderen Daten "verstecken". Etwa so, wie seine Pin als Telefonnummer getarnt auf die Kreditkarte zu schreiben...mag reichen, oder eben nicht) zu verstehen (fertige Plugins sind im Netz erhältlich), dann könnte dieser Angreifer mit dem Sessionkey eine bestehende Sitzung per Workspace Control oder Reconnect übernehmen.
Problematisch daran könnte sein, dass der Angreifer zwar nun kein Kennwort für das Userkonto hat, aber der User ja bereits angemeldet ist. Sein EMailprogramm läuft, das Datenbank-Frontend mit den Patientendaten ist entsperrt und listet gerade interessante Details eines prominenten Staatsmannes auf. Immerhin denkbar.
Zwei Wege führen prinzipiell nach Rom, also den XML Port zu verschlüsseln.
Weg eins ist simpel, aber nicht immer praktikabel: IIS und XML Port sind auf der gleichen Maschine installiert, über die Absicherung der Standardwebseite gelingt auch die Absicherung des XML Ports - fertig. Wer hier übrigens nicht weiß, wie das geht, darf mich gerne mal in einem Training besuchen... sollte aber zum Standardrepertoire eines Admins gehören.
Weg zwei ist schwieriger - theoretisch. Denn wenn kein IIS anwesend ist (meist besser so), dann muss man das Zertifikat über seinen Thumbprint ("Fingerabdruck" - eine Art Seriennummer) an die AppID der zu verschlüsselnden Anwendung binden. Thumbprint und AppID müssen aus dem Zertifikat bzw. der Registry ausgelesen werden, um danach via NetSH.exe als Parameter benutzt werden zu können - aber auch hierfür müssen sie erst in ein taugliches Format gebracht werden.
So kann man zwar unter HKCR\Software\Installer\Products nach "Citrix Broker Service" suchen, findet dort die benötigte AppID aber nur als lange Hex-Kolonne. Der Befehl NetSH.exe erwartet diese aber später im GUID-Format, also 8-4-4-4-12 Zeichen...
Um dem ganzen den Schrecken zu nehmen, habe ich ein kleines PowerShell Skript geschrieben (warum kommt sowas eigentlich nicht direkt von Citrix, am besten mit einer GUI?), welches ich hier gerne bereitstelle.
Das Skript ermittelt zunächst die passende AppID aus der Registry und bringt sie in das GUID-Format. Dann bestimmt es den Thumbprint des zu verwendenden Zertifikats (hoffentlich vorab installiert), fragt im Fall mehrerer Zertifikate nach, welches verwendet werden soll und führt dann den NetShell-Befehl zum Binden des Zertifikats an die AppID aus.
Abschließend weist es per Registrykey den XML Broker an, Anfragen nicht mehr auf Port 80 entgegenzunehmen.
Achtung, das Skript ist noch sehr roh, es sind keine Fehlerbehandlungen darin und nur wenig Logging. Ich rate daher zu den üblichen Vorsichtsmaßnahmen.
Wohl bekomms!
# script to use existing ssl certificate to encrypt Citrix XML Broker Port # works with XD Controller and Cloud Connector # use at own risk, credits to Daniel.Wipperfuerth@arrow.com # more of this at seetricks.blogspot.com # V2 2018-02-20 Write-Output "Gathering registry info..." $myReg = get-childitem -Path Registry::HKEY_CLASSES_ROOT\Installer\Products | Get-ItemProperty | Where-Object {$_.productname -like "Citrix Broker Service"} [guid]$myAppID = $myReg.PSChildName Write-Output "Looking for a certificate..." $myCert = gci Cert:\LocalMachine\my $myCertChoice = 0 if ($myCert.Length -eq 1) {Write-Output "Found one single certificate. OK."} elseif ($myCert.Length -gt 1) { Write-Output "Found more than one certificate..." for($i=0;$i-le $myCert.length-1;$i++) {"Certificate [{0}] = {1} '=>' {2}" -f $i,$myCert[$i].FriendlyName,$myCert[$i].Subject} $myCertChoice = Read-Host "Which Certificate should be bound to the Citrix Broker Service?" } elseif ($myCert.Length -lt 1) {write-output "No Certificate found, operation aborted!";break} Write-Output "Executing NetShell to bind certificate to Citrix XML Broker" & netsh.exe http add sslcert ipport=0.0.0.0:443 certhash=$($myCert[$myCertChoice].thumbprint) appid="{$myAppID}" Write-Output "Setting registry to ignore unencrypted traffic for Citrix XML Broker" $silent = New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name XmlServicesEnableNonSsl -Value 0 -Propertytype dword -Force Write-Output "All done. Maybe."
Kommentare
Kommentar veröffentlichen