Vulnerability Scope
A NetScaler vulnerability was disclosed at seclist.org called "Citrix Gateway & Cloud MFA - Insufficient Session Validation". The vulnerability has relatively low score of 5 and affects Citrix Cloud as well as on-prem NetScalers (all firmware versions). It hasn't been registered at nist.gov and it doesn't have an official CVE from Citrix.
The vulnerability consists of not validating stolen (but still valid) session cookies.
-
Citrix Cloud demonstration youtube.com.
-
NetScaler OnPrem demonstration youtube.com.
Vulnerability Detection
Since there is no official CVE, tools are not yet reporting it. Nevertheless, below are some options for checking for unpatched CVEs:
Xpand Config Analyzer Xconfig.io is free online tool that analyses NetScaler config files and provides remediation actions. This includes detecting vulnerable NetScaler versions:
NOTE! Your configuration is loaded and analyzed only in your local browser session. XConfig does not store the ns.config file on server side, unless you choose to do so! Even upon saving a strict privacy settings apply, like retantion period and masking all sensitive info (IPs, sensitive CLI strings, etc.)
Citrix AMD Service Citrix.com under the Security Advisory, you will find indication of CVEs impacting your firmware.
Vulnerability Details - Session Hijacking
HTTP protocol is stateless by definition, hence web applications need the concept of a session in order to pair subsequent requests to a client. Cookies are the predominant Session ID transport mechanism, often representing not only identification tokens, but also authenticator tokens, serving as a temporary static passwords for session access.
The CVE in questions is labeled as "Insufficient Session Validation", potentially resulting in Session hijacking (cookie hijacking). The attacker first needs to be in possession of the NSC_TMAS or NSC_AAAC cookie. There are different techniques of implementing Session hijacking, but the main idea is stealing the cookies and replay them to gain access to the web session. The thesis is that not every cookie steal should result in Session hijacking if you have some additional Session Validation.
Is Hell real and is it a sin accepting session cookies without additional validation?
MFA is very effective against stolen passwords, but stolen Session ID (cookie) becomes even more popular for bypassing MFA and second factors, since the cookie is a signle token representing the first & second factor of authentication. The growth of SSO applications has made it even more attractive as you’re not just getting access to one application, but to many that fall under the same SSO (becoming a threat multiplier).
Susceptibility to session hijacking could be decreased by implementing some or all of the below:
- Unpredictability of session values (supporting encryption)
- Secure flag (Enforce TLS transfer)
- Lifetime of a user's session (Session timeout would narrow the exposure)
- HttpOnly flag (defending against cross site scripting (XSS))
- Cookie domain restrictions (a restrictive path is typically more secure)
- HSTS Header ('always-on' TLS)
All of the above are supported by the NetScaler appliance.
Still these methods are indirect protection, mainly against stealing the cookie, but not protecting you once the cookie is stolen. In other words we need an anti-replay mechanism or session validation. A mechanism to detect an attacker who's in possession of a valid credentials (a stolen Session Cookie). Not even huge companies like Google, PayPal, Apple, Facebook have mastered this.
One of the big questions is should the browsers protect the cookies more effectively or should the SSO providers lock these cookies down?
It’s not particularly easy to detect session hijacking, nor to answer the above question, but there are a few options:
- Session ID (cookie) validation based on device identifier
- New HTTP session mechanisms
The idea being to detect parallel sessions and potential hijacking from a threat actor based on additional session validation conditions. Session ID validation example: Would a valid cookie come from a new source IP the server to require re-authentication (expiring the old cookie).
The idea is to have Hash Value validating the session cookie in the HTTP request. Combining as many values as possible together can create something that's going to be a reasonably unique fingerprint. Based on that fingerprint hash we'll detect that the session operator (device) has changed. Examples of such identifiers are user-agent, unique IP, etc. User-identifiers should be included as well, so we can distinguish two users on the WiFi in the same public library.
Notice we're speaking about web based applications, not native mobile apps that have access to hardware device identification as IMEI, MAC, Private IPs.
There are challenges with each option. With roaming sessions it's difficult to maintain mobility without a security cost. Proxies, dynamic IP addresses and other factors can also obscure the IP address of the actual device initiating the session.
Second option is new HTTP session mechanisms. Such had been proposed in the past 15 years, but they've never made it to adoption. They require a formal specification in order, where usually the web client and the web server must both run & support the implementation.
Javascript
The choice of Device Identifier could be different from an IP, but presents an equal challenge. Some vendors use javascript to assist in the Device identification, opening questions about non-browser clients. APIs suffer from same vector of attack if JWT token gets stolen.
Javascript assisted device fingerprints are deffinately better than purely IP based identifiers by providing an additional layer of security, despite client-side JavaScript lack of device info access, the attacker will have to deal with some reverse engineering. Most probably the truth lies somewhere in the middle as a combination of all these.
More on digital fingerprinting and tracking at eff.com
Actions
There is always a trade-off between security and usability, because you have an imperfect mechanism of detecting Session Hijacking. Due to this flawed by design mechanism, inevitably you'll have false positives, so the question arises:
What course of action do you wish to take upon detection?
- Block the HTTP request
- Expire the cookie (logoff)
- MFA Prompt
That's for a considerably longer discussion due to all the possible scenarios, but should be noted as there is no easy answer.
Vulnerability Mitigation
NetScaler WAF
The NetScaler offers Cookie Hijacking protection, but it won’t function as expected on the AAA engine itself. This is due to processing order of Packet Flow:
NetScaler WAF configurations are to protect the backend resource (and its session cookies) not the Authentication vServer (AAA).
NetScaler Rewrite Feature
Johannes Norz wrote a blog back in 2018 about cookie theft protection and storing (in encrypted format) user-agent & source ip identifiers in cookie values. If the cookie value does not match the current TCP session Source IP and HTTP User-Agent, the request is blocked. You can read it at norz.at.
We differ in the desired action. I would like to initiate a logoff for the compromised session. The action verdict (block or logoff) depends on your id method and the likelihood of being a false positive.
The AAA Feature supports rewrite policies, so we can create the encrypted IP validation cookie:
The manual (rewrite) cookie fingerprint method has one flaw - there is no pairing between NSC_TMAS Cookie and the Validation Cookie.
Due to this "no pairing between cookies" I can steal the NSC_TMAS Cookie and use the received Validation Cookie from my threat actor browser!
There are other issues with this implementation:
In my desire to iniate a logoff (not block the request) the traffic policy will allow you to complete that single last request, cause it does need to expire the cookie in your browser, doesn't it?
While the IP Validation Cookie concept works, the User-Agent Validation Cookie doesn't work when applied on the AAA vServer (value is empty). I need to validate the AAA Cookies, not the backend. In my tests X-NSC-V is the IP Validation Cookie, while the X-NSC-L is the User-Agent Validation Cookie (these are usually encrypted):
The manual rewrite method is a no go for the AAA engine. Nevertheless, below is the CLI from the performed tests:
// Rerwrite Cookie Policy & Action
add rewrite action RW_ACT_SESSION_VALIDATION insert_http_header Set-Cookie "\"X-NSC-V=\" + CLIENT.IP.SRC.TYPECAST_TEXT_T.ENCRYPT + \";HttpOnly;Path=/;Secure\""
add rewrite policy RW_POL_SESSION_VALIDATION true RW_ACT_SESSION_VALIDATION
bind authentication vserver AAA_VS_GENERIC_ACC -policy RW_POL_SESSION_VALIDATION -priority 100 -gotoPriorityExpression NEXT -type AAA_RESPONSE
// Logoff Traffic Policy & Action
add tm trafficAction SESSION_V_LOGOUT -persistentCookie OFF -InitiateLogout ON -kcdAccount NONE
add tm trafficPolicy TRAF_POL_SESSION_V "(HTTP.REQ.COOKIE.VALUE(\"X-NSC-V\").LENGTH.EQ(0)&&HTTP.REQ.COOKIE.VALUE(\"NSC_TMAS\").LENGTH.EQ(0).NOT)||(HTTP.REQ.COOKIE.VALUE(\"X-NSC-V\").LENGTH.EQ(0).NOT&&HTTP.REQ.COOKIE.VALUE(\"X-NSC-V\").DECRYPT.EQ(CLIENT.IP.SRC.TYPECAST_TEXT_T).NOT)" SESSION_V_LOGOUT
bind lb vserver LB_VS_SERVER -policyName TRAF_POL_SESSION_V -priority 100 -gotoPriorityExpression END -type REQUEST
Possible Alternatives
I could create a similar session manager to what Ronan wrote at citrixie and make the Set Cookie validation concept working, I could go even further and use some javascript fingerprinting as part of the nFactor.
Conclusion
Despite being fun, figuring out the implementation, the cookie validation on the AAA shouldn't be left to us. I would love to see options for customizing any existing cookie validation feature as well as being able to seamlessly integrate the AAA and the NetScaler WAF.
By the way, the vulnerability bypasses any EPA that hasn't been configured for periodic continuous validations.
Thank you for reading!