by Chris Su | Dez 14, 2021 | ALARM
UPDATE 23.12.2021, 15:10 Uhr
Aufgrund eines weiteren CVE’s (CVE-2021-45105) bezüglich der Log4j Schwachstelle hat Citrix erneut Updates für XenMobile Server herausgebracht, s. https://support.citrix.com/article/CTX335705
Updates für diese Versionen stehen zum Download bereit:
XenMobile Server 10.14 RP3: https://support.citrix.com/article/CTX335897
XenMobile Server 10.13 RP6: https://support.citrix.com/article/CTX335875
XenMobile Server 10.12 RP11: https://support.citrix.com/article/CTX335861
Dieses Update sollte schnellstmöglich installiert werden.
UPDATE 16.12.2021, 10.50 Uhr
Für Citrix Endpoint Management (Citrix XenMobile Server) steht ein Update bereit, welches die Log4j Schwachstelle fixt. Bitte so schnell wie möglich das RP2 für XenMobile Server 10.14 installieren: https://support.citrix.com/article/CTX335763
RP5 für XenMobile Server 10.13 wird in Kürze ebenfalls zum Download bereitstehen, der KB Artikel ist bereits online: https://docs.citrix.com/en-us/xenmobile/server/release-notes/release-notes-10-13-rolling-patch-5.html
Der Download für XenMobile Server 10.13 RP5 ist online: https://support.citrix.com/article/CTX335753
In der Dokumentation zu den Rollup Patches findet sich aktuell noch kein Hinweis auf die Log4j Schwachstelle. Von Citrix kam aber folgende Info:
Fixes in This Public Release
- On XenMobile Server, you observe high CPU utilization on server nodes in peak hour.
[From xms_10.14.0.10206.bin] [CXM-102568]
- OnPrem 10.14 RP2 – Upgrade log4j (Remote Code Execution zero-day)
[From xms_10.14.0.10206.bin] [CXM-102844]
- 10.14 RP2 – Remove log4j1.x of Kafka (used in GoogleAnalytics) and upgrade log4j2.x to 2.16.0
[From xms_10.14.0.10206.bin] [CXM-102878]
Original Artikel
Am 09.12.2021 wurde der CVE-2021-44228 publiziert. In diesem geht es um eine Sicherheitslücke im log4j. Die Schwachstelle ist in jeder Version vom log4j enthalten und betrifft zum Grossteil Java Applikationen. In Version log4j 2.15.0 wurde diese Schwachstelle behoben.
Hierzu gibt es den folgenden Citrix Security Advisor Artikel:
https://support.citrix.com/article/CTX335705
Citrix Produkte wie
- Citrix ADC (NetSacler)
- Citrix ADM (Citrix MAS)
- Citrix Gateway
- Citrix Hypervisor (XenServer)
- Citrix ShareFile Storage Zones Controller
- Citrix Workspace App
- App Layering, Delivery Controller, Director, FAS, HDX, Profile Management, PVS, Session Recording, Storefront, Studio, Windows VDA, WEM
- Citrix License Server
- Citrix SD-WAN
sind nicht von der Schwachstelle betroffen.
Die folgenden Produkte sind bei Citrix noch in der Überprüfung:
- Citrix Endpoint Management (Citrix XenMobile Server)
- Citrix Virtual Apps and Desktops (XenApp & XenDesktop) alle anderen Komponenten
Bei Verwendung der Citrix Web Application Firewall auf dem Citrix ADC (NetScaler) können Applikationen mittels der Web Application Firewall Signaturen gegen diese Schwachstelle geschützt werden. Dazu müssen die Signaturen von Hand aktualisiert werden:


Aktivieren der Signaturen:



Als Alternative, wenn das AppFW Feature nicht lizensiert wurde, kann der Schutz auch mittels Responser Policies gewährleistet werden, hierzu gibt es den folgenden GitHub Eintrag, welcher von den Mitgliedern des Citrix PTEC zur Verfügung gestellt wurde:
https://github.com/mbp-netscaler/ADC
Die Application Firewall Signaturen und die Responder Policies bieten aber keine 100% Sicherheit, daher wird empfohlen, log4j zu aktualisieren oder mindestens den folgenden Eintrag zu setzen: “log4j2.formatMsgNoLookups
” auf “true
” zu setzen.
https://github.com/Puliczek/CVE-2021-44228-PoC-log4j-bypass-words
by Chris Su | Okt 13, 2020 | ALARM
Vulnerabilities have been identified in Citrix Gateway Plug-in for Windows that, if exploited, could result in a local user escalating their privilege level to SYSTEM.
The vulnerabilities have the following identifiers:
- CVE-2020-8257
- CVE-2020-8258
These vulnerabilities affect the following supported versions of Citrix Gateway Plug-in for Windows:
Customers with Citrix ADC or Citrix Gateway:
- Citrix Gateway Plug-in 13.0 for Windows before 64.35
- Citrix Gateway Plug-in 12.1 for Windows before 59.16
These vulnerabilities do not affect Citrix Gateway Plug-in on other platforms.
Citrix Gateway Plug-in for Windows 11.1 is not affected by these vulnerabilities. Other versions are now End-of-Life and no longer supported.
The following supported versions of Citrix ADC (formerly known as NetScaler ADC) and Citrix Gateway (formerly known as NetScaler Gateway) include an impacted version of Citrix Gateway Plug-in in order to distribute it to users when they connect to Citrix Gateway:
- Citrix ADC and Citrix Gateway 13.0 before 64.35
- NetScaler ADC and NetScaler Gateway 12.1 before 59.16
- Citrix ADC 12.1-FIPS before 55.190
The issues have been addressed in the following versions of Citrix Gateway Plug-in for Windows:
Customers with Citrix ADC or Citrix Gateway:
- Citrix Gateway Plug-in 13.0 for Windows 64.35 and later versions
- Citrix Gateway Plug-in 12.1 for Windows 59.16 and later versions
The latest versions of Citrix Gateway Plug-in for Windows are available from:
https://www.citrix.com/downloads/citrix-gateway/plug-ins/
The original Citrix article: https://support.citrix.com/article/CTX282684
by Chris Su | Okt 1, 2020 | INFO
Momentan gibt es mehrere Meldungen durch Security Scanner, dass über NetScaler publizierte Webseiten vom Ripple20 Vulnerability betroffen sind.
Citrix ADC Produkte (NetScaler, ADM, SDX) sind nicht betroffen von der Schwachstelle welche als «Ripple20» publiziert wurde.
Mehr Informationen sind im folgenden Citrix Artikel zu finden: https://support.citrix.com/article/CTX279769
by Chris Su | Feb 19, 2020 | INFO
Erstellt: Mittwoch 19. Februar 2020
Version: 1.0
Problembeschreibung
Die bevorstehende Chrome-Version, Chrome 80, wird das standardmäßige domänenübergreifende Verhalten von Cookies ändern. Diese Änderung wird die Sicherheit erhöhen, erfordert jedoch, dass Kunden und Partner Citrix ADC-Bereitstellungen, die auf Cookies basieren, testen.
Hinweis: Chrome 80 wird voraussichtlich am 4. Februar veröffentlicht, obwohl die Änderungen an den Cookies nur in einer begrenzten Phase ab dem 17. Februar erfolgen werden.
https://www.chromium.org/updates/same-site/
Auswirkungen auf den ADC
Mit dem Citrix ADC können 2 Arten von Cookies im Spiel sein:
- Fall 1: APP-Cookie: Cookie, das vom Backend-Anwendungsserver eingefügt wird.
- Fall 2: ADC-Cookie: Cookie eingefügt/im Besitz der Citrix ADC-Appliance
Wenn eine Anwendung nach dem Chrome-Update das Einfügen von Citrix ADC- (oder APP-) Cookies durch den Browser in einem standortübergreifenden Kontext erfordert (im Abschnitt «Hintergrund» weiter unten erläutert), wird der Chrome-Browser dies in wenigen Szenarien mit dem Chrome 80-Update nicht tun.
- Wenn APP-Cookies fehlen, kann dies zu einem Abbruch des Anwendungsflusses führen.
- Wenn ein ADC-Cookie in der nachfolgenden Anfrage fehlt, würde ADC es als eine neue Benutzeranfrage behandeln, und Persistenz wird nicht berücksichtigt, was zu einer Unterbrechung der Anwendung führt.
Impact auf Gateway und AAA
Für alle VPN- und AAA-Bereitstellungen nur innerhalb eines Iframe mit standortübergreifendem Kontext, die das Einfügen von Citrix Gateway- oder AAA-Cookies durch den Browser erfordern, gibt der Google-Chrome-Browser nach der Aktualisierung keine standortübergreifenden Cookies frei, was sich nur auf diese speziellen Bereitstellungen auswirkt und die Iframe-Komponente der Website nicht lädt.
Alle VPN– und AAA-Bereitstellungen mit demselben Website-Kontext oder ohne Iframes haben keine Auswirkungen und funktionieren nach dem Chrome-Update problemlos.
Hintergrund
Derzeit enthalten typische Browser das Cookie in HTTP-Anfragen in 2 Kontexten.
- Kontext der gleichen Website: Hier fordert der Benutzer den Browser auf, ihn zu einer bestimmten Domain zu bringen, für die der Browser das Cookie zuvor gespeichert hat.
- Website-übergreifender Kontext: Hier leitet eine Website eines Dritten den Benutzer zu einer Domäne um, für die der Browser das Cookie gespeichert hat, und der Browser schließt das Cookie bei der Anforderung der Webseite ein.
Im standortübergreifenden Kontext kann es zu CSRF-Angriffen (Cross Site Request Forgery) kommen, die dazu führen können, dass ein Angreifer die Sitzung des Benutzers stiehlt, um unerwünschte Aktionen im Namen des Benutzers durchzuführen. Um dies zu verhindern, empfiehlt RFC6265 bis, ein neues Attribut «SameSite» in das Cookie einzufügen, das dem Browser anzeigt, ob das Cookie für den Cross-Site-Kontext oder nur für den Kontext der gleichen Website verwendet werden kann. Auch wenn eine Anwendung beabsichtigt, im standortübergreifenden Kontext aufgerufen zu werden, kann sie dies nur über eine https-Verbindung tun.
Das SameSite-Attribut kann die folgenden Optionen annehmen.
- SameSite=Keine; Sicher
- Zeigt dem Browser an, dass der Cookie nur bei sicheren Verbindungen im standortübergreifenden Kontext verwendet wird.
- SameSite=Lax
- Zeigt dem Browser an, dass er das Cookie für Anfragen auf der gleichen Domäne verwenden soll, und dass nur sichere HTTP-Methoden wie die GET-Anfrage das Cookie verwenden können.
- SameSite=Streng
- Verwenden Sie das Cookie nur, wenn der Benutzer die Domäne explizit anfordert.
Hinweis: Wenn kein SameSite-Attribut im Cookie vorhanden ist, übernimmt der Chrome-Browser ab Februar 2020 die Funktionalität von SameSite=Lax. Der aktuelle Standardwert der SameSite-Einstellung ist None, was dem Browser die Verwendung von Cookies im Kontext von Drittanbietern ermöglicht.
Lösung
Optionen auf Konfigurationsebene zur Anpassung an diese Änderung werden in den Versionen 13.0, 12.1, 12.0 und 11.1 verfügbar sein, die bis zum 6. März 2020 veröffentlicht werden sollen.
Workaround
Workaround in Chrome
In Chrome 80 gibt es eine Option, die es Ihnen ermöglicht, zum alten Cookie-Verhalten zurückzukehren. Diese wird für mindestens 12 Monate nach der Veröffentlichung von Chrome 80 stabil verfügbar sein.
Weitere Informationen finden Sie unter SameSite Updates.
Workaround Steps for Case: 1 App cookie
Man kann eine antwortbasierte Neuschreibrichtlinie so konfigurieren, dass sie sich den «Set-Cookie»-Header in der vom Backend-Server gesendeten Antwort ansieht und das «SameSite»-Cookie-Attribut anhängt.
Ein Beispiel für eine Rewrite-Richtlinie sieht so aus:
add rewrite action rewrite_http_header replace_all http.RES.full_Header "\"SameSite=None; Secure; path=/\"" -search "regex(re!(path=/\\; SameSite)|(path=/)!)" add rewrite policy append_samesite_cookie "http.RES.HEADER(\"Set-Cookie\").EXISTS" rewrite_http_header
obige Umschreibungsrichtlinien müssen anwendungsspezifische virtuelle Server auf Citrix ADC gebunden werden.
Workaround Steps for Case: 2 ADC cookie (Persistence Use case)
Derzeit gibt es zwei Workarounds, um einen eventuellen Bruch (aufgrund des Chrom-Updates) von Anwendungen mit COOKIEINSERT-Persistenz, die auf LB vserver konfiguriert sind, zu verhindern.
1. Verwenden Sie eine RULE-basierte Persistenz der Antwort
Wenn die Backend-Anwendung ein eindeutiges Cookie für jede der Client-Sitzungen sendet, kann Citrix ADC diesen eindeutigen Cookie-Wert als Schlüssel verwenden und einen RULE-basierten Persistenzeintrag erstellen, der die Backend-Server-Informationen speichert, die dem empfangenen Cookie entsprechen. Wenn die Clientanforderung mit diesem Cookie zurückkommt, verwendet Citrix ADC den Cookie-Wert als Schlüssel und holt den entsprechenden Backend-Server, um die Anforderung weiterzuleiten, wodurch die durch die COOKIEINSERT-Persistenz erreichte Klebrigkeit beibehalten wird. Dieser Ansatz funktioniert nur dann, wenn der Backend-Server für jeden Client in der Antwort ein eindeutiges Cookie-Schlüssel/Wert-Paar sendet.
Unten finden Sie eine Beispielkonfiguration, bei der der Back-End-Server ein Cookie mit dem Schlüssel als SESSIONID sendet. Die SESSIONID in der folgenden Konfiguration muss durch den vom Backend gesendeten eindeutigen Cookie-Schlüssel ersetzt werden.
set lb vserver lbvs -persistenceType RULE -rule "HTTP.REQ.COOKIE.VALUE(\"SESSIONID\")" -resRule "HTTP.RES.SET_COOKIE.COOKIE(\"SESSIONID\").VALUE(0)"
2. Zweistufige Topologie mit einer neuen Citrix ADC-Front, die die bestehenden Citrix ADCs beendet
Der Kunde kann eine zweistufige Topologie mit einer neuen Citrix ADC-Front haben, die den Datenverkehr für den Tier-2-Citrix ADC (bestehender Citrix ADC) beendet. Der erste Citrix ADC der ersten Schicht schreibt die Antwort neu, um das SameSite-Attribut für alle Cookies, die vom Tier-2-Citrix ADC empfangen werden, zu berücksichtigen.
Für das Tier-2-Citrix-ADC sind keine Konfigurationsänderungen erforderlich.
Unten ist eine Beispielkonfiguration für das Tier-1-Citrix-ADC aufgeführt.
enable feature lb rewrite
add lb vserver tier-1-lb <protocol> <IP> <port>
add service tier-2-lb-svc <tier-2-vserver-IP> <tier-2-vserver-protocol> <tier-2-vserver-port>
bind lb vserver tier-1-lb tier-2-lb-svc
add rewrite action rewrite_http_header replace_all http.RES.full_Header "\"SameSite=None; Secure; path=/\"" -search "regex(re!(path=/\\; SameSite)|(path=/)!)"
add rewrite policy append_samesite_cookie "http.RES.HEADER(\"Set-Cookie\").EXISTS" rewrite_http_header
bind lb vserver tier-1-lb -policyname append_samesite_cookie -priority 10 -type RESPONSE
Hinweis: Dies sollte auch dann funktionieren, wenn der Back-End-Server kein eigenes Cookie enthält.