Teil 2: VerSAMLung – SSO mit SAML oder KCD für interne Webservices

(von Stefan Kuscher und Benjamin Rodewald)

Im ersten Teil unserer Serie „verSAMLung“ haben wir den Citrix Application Delivery Controller (ADC) als SP an die MS Azure MFA Authentifizierung (als IdP) angebunden und so die bequeme und transparente Nutzung von Applikationen auf dem Citrix ADC möglich gemacht, welche mit einer Pre-Authentifizierung geschützt sind.

Bisher muss man sich nach der Anmeldung am Azure (welche der ADC nutzt) noch immer an der eigentlichen Applikation anmelden, aber auch dafür gibt es eine Lösung. Der ADC bietet die Möglichkeit Anmeldedaten zu extrahieren und die diese auch für den Single Sign On im Backend zu benutzen. Im einfachsten Fall, könnte die dem ADC bekannte Username/ Kennwort Kombination z.B. für eine 401 Header Based Authentication genutzt werden, hierfür wäre lediglich eine Traffic Policy, welche Web Single Sign On anschaltet, notwendig.

In Verbindung z.B. mit SAML oder Certificate based Authentication ist das Vorgehen ein klein wenig komplizierter, da auf dem ADC keine Anmeldedaten vorliegen (was dem Sicherheitsniveau natürlich sehr zuträglich ist). Hier muss ein Verfahren genutzt werden, welches alleine mit den im SAML Token vorhandenen oder im Zertifikat vorhandenen Informationen auskommt. Neben der Möglichkeit hier im Backend ebenfalls SAML für den SSO zu benutzen, gibt es die Möglichkeit Kerberos Constrained Delegation (KCD) zu nutzen. Da sämtliche Applikationen aus dem Windows Umfeld damit sehr einfach angebunden werden können, bietet sich diese Möglichkeit oft an um eine Applikationen zu verSAMLen (SAML fähig zu machen).

DNS und NTP auf dem ADC

Wie auch in den späteren Logs erkennbar sein wird, benötigt der Netscaler für die Nutzung von Kerberos eine funktionierende DNS Auflösung der Windows Active Direcory Domain und eine per NTP korrekt synchronisierte Uhrzeit. Für die Domain/ den DC kann theoretisch auf dem Netscaler auch manuell ein Ressource Record hinzugefügt werden. Zur Zeitsynchronisation sind idealerweise mindestens zwei NTP Server einzutragen und die Synchronisation einzuschalten.

Konfiguration AD Account / Delegation

Bei der Constrained Delegation wird ein Servcie Benutzer für den ADC angelegt, dem dann die Delegierung (Zugriff im Auftrag eines anderen Benutzers) erlaubt wird:

Nachdem der Benutzer angelegt wurde, muss der HOST SPN gesetzt werden, damit die Regsiterkarte „Delegation“ erscheint:

setspn -S HOST/[Name d. Deleg.-konto].[FQDN] [NetBIOS-Domainname]\[Name d. Deleg.-konto]

Setzen des Host SPN
Kerberos Delegierungskonto 1/2

Auf der Registerkarte „Delegation“ des Accounts wird dann die eigentliche Delegierung konfiguriert, der Service SPN „http/demoweb.mwdemo.local@MWDEMO.LOCAL“ für einen internen Microsoft IIS Webserver.

Kerberos Delegierungskonto 2/2

Konfiguration KCD auf dem ADC

Für den Account wird dann auf dem ADC ein KCD Objekt erstellt, welches in einer Traffic Policy eingebunden wird:

ADC / KCD-Account
add aaa kcdAccount wiakcd_appdelegation -realmStr MWDEMO.LOCAL -delegatedUser appdelegation -kcdPassword b616477dhgkjifdghuidf4757747593458930580f -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_yy_yy_yy8 -userRealm MWDEMO.LOCAL -serviceSPN "http/demoweb.mwdemo.local@MWDEMO.LOCAL"

Steuerung SSO mittels Traffic Policy und Profile

Mittels einer Traffic Policy und einem Traffic Profile, welches auf dem Load Balancing Vserver gebunden wird, wird gesteuert an welchen Stellen die KCD SSO Settings angewendet werden sollen:

Traffic Profile (unten ist der KCD Account ausgewählt)
add tm trafficAction prof_traf_wia_demoweb_kcd -SSO ON -persistentCookie OFF -InitiateLogout OFF -kcdAccount wiakcd_appdelegation

Traffic Policy über die das o.g. Profile angebunden wird
add tm trafficPolicy pol_traf_wia_demoweb_kcd true prof_traf_wia_demoweb_kcd

Debugging

Ein Debugging ist mittels cat /tmp/nkrb.debug möglich.

Bei unserem ersten Versuch in der Demo Umgebung gab es wegen den unterschiedlichen Realms in Verbindung mit dem Azure AD noch Probleme:

Log Fehler

Wir haben daraufhin in den KCD Settings das Feld „User Realm“ ergänzt, dies verhindert, dass wie oben eine Cross Realm Authentifizeirung zwischen Azure AD und AD Domäne versucht wird. Somit wird die Anfrage „Username@michaelwesseldemo.onmicrosoft.com“ zu der passenden Anfrage „Username@mwdemo.local“ umgewandelt. Dieser „Workaround“ betrifft unserer Testumgebung aufgrund der fehlenden routingfähigen Domäne.

Hier die Logs des Erfolgsfalls:

Log Erfolg – 1
Log Erfolg – 2
Log Erfolg – 3
Log Erfolg – 4
Log Erfolg – 5
Log Erfolg – 6
Log Erfolg – 7

Teil 1: VerSAMLung – Microsoft Azure SSO am Citrix ADC mit SAML

(von Stefan Kuscher und Benjamin Rodewald)

Im Nachfolgenden erläutern wir die Vorteile, wenn Citrix ADC und Azure Active Directory verSAMLt sind und wie wir dies umgesetzt haben.

Folgende Vorteile ergeben sich:

  • Benutzer muss lediglich beim Anmelden am Arbeitsgerät ein Passwort eingeben (SSO) und ist somit automatisch beim Citrix ADC bekannt und bestenfalls alles was mit diesem verknüpft ist. Von dort aus kann z.B. der Zugriff auf Applikationen wie Citrix Xenapp/XenDesktop oder auch Web-Applikationen erfolgen. (Ohne zusätzliche Anmeldung)
  • Azure AD als der Zugangspunkt für Benutzer.
  • Benutzersteuerung/Berechtigungsverwaltung zentral in Azure AD.
  • Conditional Access\Begrenzter Zugriff + MFA (Azure AD P1 Lizenz)

Voraussetzungen

Ablauf

Abbildung Ablauf SAML

Das SAML Protokoll wurde geschaffen um über eine Teilung in Identity Provider (IdP) und Service Provider (SP) die Authentication für Zugriffe zu ermöglichen. Dabei kann sofern eine Applikation z.B. aus der Cloud bezogen wird, trotzdem gegen einem IdP, der unter Kontrolle des eigenen Unternehmens steht authentifiziert werden (in unserem Falle ist dieser in der Cloud als MS Azure AD ausgeprägt). Der SAML SP (AAA auf dem ADC) vertraut diesem IdP und lässt den Request beim Vorhandensein der Authentifizierungsinformationen passieren. Sind die Informationen nicht vorhanden, würde der Citrix ADC auf die Anmeldeseite des SAML IdP weiterleiten.

In unserem speziellen Fall meldet das Gerät bereits beim MS Windows Logon den Benutzer in der Cloud beim Azure AD an. Der Benutzer besitzt daher zum Zeitpunkt seines ersten Zugriffs schon die entsprechenden Anmeldeinformationen und der ADC (bzw. die AAA / SP Komponente) lässt den Benutzer mit SSO passieren.

Deployment einer Enterprise Applikation in Azure (IDP)

Um eine Kommunikation mit dem Citrix ADC via SAML herzustellen benötigt man auf der Azure Active Directory Seite eine Enterprise Applikation. Diese wird im Azure Active Directory -> Enterprise Applications -> New Application
bereitgestellt und wird benötigt um sich mit dem SP per SAML auszutauschen.

Auswählen einer Vorlage im Browse Azure AD Gallery für das Citrix SAML Add On
Microsoft bietet bereits diverse Vorlagen für Enterprise Applikationen an. In unserem Fall benötigen wir die Vorlage „Cirix ADC SAML Connector for Azure AD“.

In der Enterprise Applikation müssen die benötigten Informationen wie Identifier, Reply URL und Sign On URL des Citrix ADC hinterlegt werden.

1.) Enterprise Applikation -> Name der APP -> Single Sign-on
Identifier: https://FQDN
Reply URL: http(s)://FQDN der WebApplication/cgi/samlauth
Sign On URL: https://FQDN/CitrixAuthService/AuthService.asmx


Ebenfalls finden sich dort die Informationen die der Citrix ADC im späteren Verlauf benötigt z.B. die Login URL von Azure Active Directory oder die Metadaten URL.

2.) Mittels Metadaten URL kann der Austausch der Informationen zwischen AAD und ADC automatisch erfolgen. Voraussetzung hierfür ist dass die Version des CItrix ADC den Austausch via Metadaten bereits unterstützt.

3.) Falls ein Austausch via Metadaten nicht in Frage kommt ,können die Informationen auch manuell dem Citrix ADC übergeben werden (Login URL, Zertifikat…).

Screenshot aus dem Citrix ADC SAML Connector

Berechtigungskontrolle für die Enterprise Applikation

Im Anschluss müssen die Benutzer noch die Berechtigungen erhalten, um die Enterprise Applikation nutzen zu können. In unserem Fall stellen wir die Applikation für alle Benutzer zur Verfügung. Wir deaktivieren somit die Zuweisung für einzelne Benutzer komplett:

Assignment required = No

Screenshot Zuweisung einzelner Gruppen und Nutzer
Falls eine Zuweisung an einzelne Benutzer erwünscht ist, einfach „Assignment required“ auf „Yes“ umstellen (Standardeinstellung) und die Zuweisung für Benutzer unter „Users and Groups“ durchführen.

Konfiguration des AAA Servers / SAML SPs auf dem ADC

Um eine Applikation auf dem Netscaler mit einer Preauthentication zu schützen, kommt die AAA Funktion zum Einsatz. Hierfür wird ein AAA Virtual Server Objekt angelegt, welches in der SAML Welt gleichzeitig den SAML Service Provider (SP) darstellt, der in unserem Fall dem Microsoft Azure Identity Provider (IdP) vertraut. Um für eine Web Applikation die Anmeldung am AAA bzw. dem SAML IdP zu erzwingen, wird der AAA Vserver auf dem enstprechenden Load Balancer oder Content Switch Objekt über die „Authentication“ Registerkarte verknüpft.

Anlage des AAA Virtual Servers

Screenshot  Anlage des AAA im Authentication Virtual Servers
add authentication vserver aaademo SSL 0.0.0.0

Ein SSL Zertifikat muss gebunden werden, auch wenn der AAA Vserver nicht direkt angesprochen wird.

bind ssl vserver aaademo -certkeyName AAA_test
bind ssl vserver aaademo -eccCurveName P_256
bind ssl vserver aaademo -eccCurveName P_384
bind ssl vserver aaademo -eccCurveName P_224
bind ssl vserver aaademo -eccCurveName P_521

Screenshot SSL Virtual Server Server Certificate Binding

SAML SP Server

Falls der Import der Metadaten nicht funktioniert, können die Daten auch aus dem XML extrahiert werden und manuell hinterlegt werden. Das IdP Zertifikat lässt sich auf der Azure Enterprise Appliacation im Azure Portal exportieren (Base64 bietet sich an).

Screenshot mögliche Konfiguration aus dem Configure Authentication SAML Server
SAML Action 1/3
SAML Action 2/3

Nach Citrix Best Practices muss zur Absicherung eine Relaystate Regel konfiguriert werden (vergl. Citrix Application Delivery Controller and Citrix Gateway – SAML Configuration Reference Guide):

SAML Action 3/3 – Relaystate Regel
add authentication samlAction AzureSSOHapp-SAMLServer -samlIdPCertName ADC-SAML-Connector -samlRedirectUrl "https://login.microsoftonline.com/883dfdf-154e-4fdf33-b857-1dfdf8d/saml2" -samlIssuerName "https://vipdemo.michael-wessel.de" -relaystateRule "AAA.LOGIN.RELAYSTATE.EQ(\"https://vipdemo.michael-wessel.de/\")" -logoutURL "https://login.microsoftonline.com/8dda6db-dde-4e33-dddd7-173179eb1e8d/saml2"

SAML SP Policy

Screenshot Configure Authentication Policy
add authentication Policy pol_AzureSSOHapp -rule true -action AzureSSOHapp-SAMLServer

Die erstellte SAML SP Policy muss dann an den AAA Virtual Server / SAML SP gebunden werden und der AAA Virtual Server auf der Registerkarte „Authentication“ des Load Balancers oder Content Switches verknüpft werden. Auf ADCs mit einer aktuellen Firmware haben sich zudem die Defaults für die Athorization geändert, so dass eine pasende Authorization Policy anzulegen ist.

Ausblick

Mit dem Vorliegen der Anmeldeinformationen kann auf dem Netscaler auch eine detaillierte Berechtigung auf bestimmte URLs anhand von z.B. Gruppenmitgliedschaften über Authorization Policies erfolgen.

Außerdem ist es möglich authentifizierte Benutzer z.B. per SAML oder KCD an Servern hinter der Pre-Authentication automatisch anzumelden.

Im MS Azure sind umfangreiche Möglichkeiten der Multi Faktor Authentifizierung und des Conditional Access möglich.

Mehr zu diesen und anderen Möglichkeiten werden sie in den weiteren Artikeln unserer Serie „verSAMLt“ lesen.

Citrix ADC/ Netscaler Full-VPN mit Client Choices

Neben der Nutzung des ADC als Load Balancer und Content Switch oder Gateway für Virtual Apps and Desktops, bietet die Lösung auch die Möglichkeit echtes SSL VPN zu implementieren.

Falls ein bestehender Gateway Virtual Server konfiguriert ist, kann dieser mit wenigen Schritten oft um ein wahlweises SSL VPN erweitert werden.

Voraussetzungen

  • Netscaler Gateway Virtual Server muss im Smart Access Modus sein („IcaOnly = false“)
  • Es müssen ausreichend Universal Licenses vorhanden sein, für alle Verbindungen zu diesem Gateway Virtual Server

Einbau in ein bestehendes Gateway

Am einfachsten lässt sich das Full-VPN in ein bestehendes Gateway implementieren, wenn man über eine Gruppenmitgliedschaft einem teil der Benutzer die selektive Auswahl des Full VPN als Alternative zum Virtual Apps and Desktops anbiete. Hierzu gibt es idealerweise in der LDAP Policy des Gateways eine funktionierende Group Extraction. Der ADC wird dann beim Login eines Benutzers versuchen LDAP Gruppenmitgliedschaften auf ADC Gruppenmitgliedschaften (hier: CitrixFullVPN) zu übersetzen.

add aaa group CitrixFullVPN

An diese Gruppe können wir nun den gewünschten Client IP-Bereich für das VPN binden und eine entsprechende Policy, welche die Benutzerauswahl („-Client Choices ON“) einblendet und die VPN Funktion zusätzlich konfiguriert:

add vpn sessionAction AC_VPN -splitDns REMOTE -splitTunnel OFF -transparentInterception ON -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy OFF -wihome "https://store.mycompany.de/Citrix/StoreWeb" -ClientChoices ON -ntDomain mycompany -clientlessVpnMode OFF -iconWithReceiver OFF
add vpn sessionPolicy PL_VPN-classic ns_true AC_VPN
bind aaa group CitrixFullVPN -intranetIP 192.168.1.0 255.255.255.0
bind aaa group CitrixFullVPN -policy PL_VPN-classic -priority 100

Bei der Konfiguration kann über die Parameter „-splitTunnel“ und „-splitDns“ angegeben werden, ob der komplette Traffic in den Tunnel geleitet werden soll oder nur ein Teil des Traffics. Eine ähnliche Konfiguration ist für DNS möglich. Im obigen Beispiel, wird der komplette Traffic nach dem VPN Verbindungsaufbau in den Tunnel geleitet und DNS Remote, also über den Netscaler abgewickelt.

Routing

Es ist theoretisch möglich die Full VPN Funktionalität ohne einen zusätzlichen Adressbereich zu nutzen, der Netscaler lässt dann alle Clients per Übersetzungstabelle über die SNIP kommunizieren. In der Praxis hat sich gezeigt, das einige Backendsysteme damit nicht klarkommen und der Traffic außerdem in einer Firewall selektiver behandelt werden kann, wenn ein zusätzlicher Adressbereich genutzt wird. Zu diesem Adressbereich wiederum wird dann über die bestehende SNIP des Netscalers geroutet. Es ist also auf einer zentralen Firewall oder einem Gateway eine Route analog dem folgenden Beispiel zu konfigurieren:

route add 192.168.1.0 255.255.255.0 <NetscalerSNIP>

Benutzeransicht

Login
„Client Choices“ Abfrage
Netscaler Gateway Plugin

Weitere Möglichkeiten

Das Netscaler Gateway Plugin beherrscht neben den klassischen primären und sekundären Faktoren auch die Anzeige der Netscaler NFactor Faktoren/ eines Flows im Plugin und kann somit auch damit kombiniert werden.

Die Verbindungen innerhalb des VPNs können mittels Authorization Policies pro Benutzer oder Gruppe eingeschränkt werden.

Citrix Dokumentation:

Full VPN setup on Citrix Gateway

Outlook Mobile: Microsoft sendet Mitteilungen an Outlook-User

Microsoft aktualisiert die Ankündigung „Benachrichtigung über Outlook Mobile in Outlook“ (MC207028) und erweitert das Gebiet auch auf Europa.

Seit dem 12. August 2020 informiert Microsoft an Outlook Benutzer, die noch kein Outlook Mobile nutzen, darüber das es Outlook auch für iOS und Android gibt.

Außerdem befindet sich in dieser Benachrichtigung ein Link, über den sich der Nutzer komfortabel die Outlook Mobile App für Android oder iOS Herunterladen können bzw. wird hier auf die entsprechende App Stores der beiden Plattformen verwiesen.

Wird diese Benachrichtigung geschlossen oder der Benutzer installiert sich Outlook Mobile, erscheint keine erneute Benachrichtigung.
Jedoch kann die Benachrichtigung auch zentral administrativ über ein entsprechendes cmdlet in Powershell deaktiviert werden.

Sollten Sie diese Nachrichten bei Ihnen und ihren Nutzern nicht wünschen, können wir sie dabei gerne unterstützen.

Wenden Sie sich daher gerne vertrauensvoll an uns.

Analyse und Incident Response CVE-2019-19781 (#citrixmash #shitrix)

Sowas passiert nur alle paar Jahre mal – eine Sicherheitslücke von solch drastischer Kritikalität. Das BSI hat denn auch die potenziellen Auswirkungen zunächst erheblich unterschätzt und den Fall als weit weniger kritisch bewertet als das US-amerikanische NIST. Inzwischen ist aber klar, dass der Fall es nicht umsonst bis in die Tagesschau geschafft hat.

Was wir wissen

  • Lücke ist seit Mitte Dezember bekannt, Citrix hat offiziell darüber informiert und Workarounds zum Schutz bereitgestellt
  • Für einen bestimmten Build (50.28) von Citrix ADC/Gateway (the artist formerly known as NetScaler) wirken die Workarounds aufgrund eines weiteren Bugs nicht – zusätzliche Maßnahmen oder ein Update auf einen halbwegs aktuellen Build von 12.1 sind erforderlich (siehe Citrix Artikel)
  • Citrix hat Updates zur Fehlerbehebung angekündigt, für die Versionen 11.1 und 12.0 sind diese Stand heute verfügbar, für weitere unterstützte Versionen sollen die Updates spätestens nächste Woche folgen
  • Seit der zweiten Januar-Woche wird die Lücke aktiv ausgenutzt, spätestens ab dieser Zeit konnten intensive Scans durch die ganze Welt beobachtet werden, die verwundbare Systeme identifiziert und vermutlich für spätere Angriffe dokumentiert haben
  • Nachdem die ersten weniger freundlichen Hacker ihren Exploit Code veröffentlicht haben, wurden weitere Skripte von gewissenhaften Security Experten veröffentlicht, da die Katze nun aus dem Sack war, die eigentlich noch zurückgehalten werden sollte
  • Auf einem verwundbaren System sind Spuren der Kompromittierung zu finden, so lange sich der Angreifer nicht sehr gründlich Mühe gibt, diese zu verwischen – und den nötigen Zugriff dafür erlangt hat
  • Falls keine Spuren zu finden sind, ist dies keine 100%-ige Garantie, dass nichts passiert ist
  • Bei den ersten Spuren sind insbesondere Zertifikate (Private Keys) auf den betroffenen Systemen als kompromittiert zu betrachten und sollten zurückgerufen und ausgetauscht werden
  • lokale Benutzer auf betroffenen Systemen sind insofern gefährdet als dass der Angreifer potenziell Hashes der Passwörter in seinen Besitz bringen konnte, die er nun versuchen kann in Ruhe per brute force zu enttarnen – Passwortwechsel sollten umgehend umgesetzt werden
  • Weiterhin sind auf dem betroffenen System konfigurierte Service Accounts für die interne Infrastruktur gefährdet und müssen als kompromittiert angesehen werden
  • Eine Neu-Installation betroffener Systeme sollte sowieso vorgenommen werden
  • Insbesondere falls keine Firewall vor dem betroffenen System ausgehende Verbindungen verhindert, kann der Angreifer sogar eine Remote Shell auf dem System erlangt haben. Von diesem Fuß in der Tür kann er alle darüber hinaus netzwerktechnisch erreichbaren Systeme ins Visier genommen haben – zusammen mit erlangten Informationen zu Service Accounts ein Silbertablett für weiteres Eindringen

Was wir tun

Nach der frühzeitigen Information und Unterstützung unserer Kunden im Dezember arbeiten wir seit einer Woche nunmehr in Eskalationen und Analysen bei zahlreichen Fällen mit. Dabei geht es immer um eine Kadenz von Maßnahmen:

  • Schutzstatus feststellen
  • Schutz ggf. herstellen
  • Kompromittierungsstatus feststellen
  • Isolation und Recovery ggf. einleiten
  • Mögliche Tiefe der Kompromittierung feststellen (was kann der Angreifer unmittelbar erlangt haben)
  • Mögliche Kompromittierungen weiterer Systeme analysieren (was kann der Angreifer ggf. über das direkt verwundbare System hinaus erreicht haben)

Das Ergebnis kann leider fast nie eine sichere Aussage der Art „es ist nichts passiert“ sein. Dieser kann man sich nur anhand von Indizien annähern. Lediglich bei unmittelbar nach Bekanntwerden konsequent und korrekt implementierten Schutzmaßnahmen gehen wir von einer faktischen Unversehrtheit aus. In allen anderen Fällen muss eine Risikobewertung stattfinden, um die Tiefe und Ausführlichkeit zu bestimmen, in der analysiert und bereinigt werden muss.

Aufgrund der Menge an Fällen sind unsere Vorlaufzeiten zur umfassenden Bearbeitung neuer Anfragen aktuell im Bereich von Tagen. Die ersten Schritte in o.g. Kadenz können aber jederzeit im Bereich Same, maximal Next Business Day gegangen werden. Kommen Sie gerne auf uns zu.

Remote Desktop Services und vertraute Domains

Nutzt man die Remote Desktop Services von Windows Server 2012/2016/2019 und befindet sich zeitgleich in einer Multi-Domain- oder Multi-Forest-Umgebung, so wird man schnell feststellen, dass sich in den Assistenten zur Autorisierung von Benutzern und Gruppen ein Fehler eingeschlichen hat. Versucht man dort eine Gruppe hinzuzufügen, die sich nicht in derselben Domain befindet wie der Server von dem man die Konfiguration vornimmt, so bekommt man die folgende Fehlermeldung:

An diesem Punkt würde man normalerweise überprüfen, ob die Domain-Konnektivität so wie die Trusts in Ordnung sind, allerdings ist das in diesem Fall (wahrscheinlich) nicht das Problem.

Um diesen Schritt erfolgreich durchführen zu können, muss jede zu autorisierende Domain der DNS Suffix Search List auf einem beliebigen Netzwerk Adapter des aktuellen Verwaltungshosts (auf dem die Konsole ausgeführt wird), hinzugefügt werden.

Diese Konfiguration kann zum Beispiel wie folgt aussehen:

Security/Wireless: WPA2-KRACK-Leak

Wofür steht KRACK?

Die Abkürzung KRACK steht für Key Reinstallation Attack, was das Verfahren des Angriffs beschreibt.

Wie funktioniert der Angriff?

Wie einige von Ihnen vermutlich schon mitbekommen haben, ist jüngst eine schwerwiegende Sicherheitslücke in der Implementierung des WPA2-Standards bekannt geworden, die es Angreifern ermöglicht, den Encryption-Key für den Traffic​ innerhalb des 4-Way-Handshakes abzufangen, auszunullen und dadurch lesbar zu machen. Continue reading „Security/Wireless: WPA2-KRACK-Leak“

Nach Sicherheitsvorfall: Citrix stellt neue NetScaler Builds bereit

Es war ein beispielloses Szenario: Für mehrere Tage waren keinerlei Firmware-Versionen von Citrix NetScaler zum Download verfügbar, zurückgezogen aufgrund eines nicht näher spezifizierten „Issues“, der gefunden worden sei.

Die Verweise auf Best Practises und Secure Deployment Guides legten bereits nahe, dass ein Sicherheitsrisiko im Bereich des Management Access vorliegen dürfte. Dieser ist immer auf der NetScaler IP (NSIP) als der primärer Management-IP zugänglich und kann auf jeder Subnet IP (SNIP) ebenfalls aktiviert werden. Welcher Dienst genau betroffen sei (in Frage kamen SSH oder der Webserver für die GUI), war nicht erkennbar. In den allermeisten Deployments  jedoch dürfte der verwundbare Dienst ohnehin nur im Management-Netz erreichbar gewesen sein, gemäß Best Practises sogar nur für explizit berechtigte Admin-Arbeitsplätze. Insofern erschien die Maßnahme überraschend heftig, zu der Citrix mit dem Zurückziehen sämtlicher Builds griff.

Jetzt hat Citrix neue Builds der supporteten Versionen 10.1, 10.5, 10.5e, 11.0, 11.1 und 12.0 bereitgestellt. Im zugehörigen Security Bulletin ist nun auch ausgeführt, worum es sich handelt: Die Authentifizierung am Management Interface kann unter bestimmten Umständen umgangen werden, so dass Unbefugte administrativen Zugriff erlangen können.

Zeitnahe Updates sind dringend angeraten. Derweil die schon empfohlenen Best Practises zum sicheren Deployment. In allen Punkten unterstützen wir zahlreiche Unternehmen aktiv – kommen Sie gerne auf uns zu, wenn Sie Fragen haben.

NetScaler Gateway: SSL-VPN CCU Lizenzen: Limitierung verringert / aufgehoben

Citrix hat es endlich gewagt!

Wir haben schon lange in etlichen internen Runden darauf gedrängt, und auch die ersten positiven Signale (natürlich streng vertraulich) bereits im Sommer zurückbekommen. Und jetzt ist es endlich offiziell: Citrix lockert die SSL-VPN Lizenzierung auf. Bisher konnten wir trotz der Investition in Citrix NetScaler Standard oder Enterprise Lizenzen nur 5 Concurrent User SSL-VPN nutzen. Weitere User mussten separat per NetScaler Gateway Universal License lizenziert werden oder aus XenApp / XenDesktop Platinum übernommen werden. Einzig die NetScaler Platinum Lizenz hat 100 CCU SSL-VPN mitgebracht.

Continue reading „NetScaler Gateway: SSL-VPN CCU Lizenzen: Limitierung verringert / aufgehoben“