Table of Contents
Overview
Quick Post about what is the hijacking of an authenticated NetScaler user session and how to protect yourself from it. This feature starts with 13.1 Build 53.17 and 14.1 Build 25.53
There are two cookies responsible for a User Session, depends on your usage of NSGW / AAA. They get issued after a successful authentication.
NSC_TMAS = AAA protected Webserver
NSC_AAAC = NetScaler Gateway
How’s the process of the cookie hijack looking? An example for NetScaler Gateway:
On Client1, browse to your NetScaler Gateway URL and authenticate. Go to Devtools and copy the Name of the cookie NSC_AAAC and the corresponding Value.
On Client2, browse to your NetScaler Gateway URL and do not authenticate. Go to Devtools, create a new cookie with the Name NSC_AAAC and paste the corresponding Value. Refresh the Page and you’re authenticated. That’s it.
Configuration
What’s new in these Firmware to protect from that? NetScaler now maps every authenticated Session to Source-IP, so there’s a new expression called AAA.USER.SOURCEIP which can be used in Responder (which works on every license edition)
The config is quite simple, here’s an example for creating a short blocked page when someone is trying to hijack a User’s session.
add responder action RespAct_SessionHijack respondwith "\"This IP address (\"+ CLIENT.IP.SRC +\") is blocked to connect to this service.\"" add responder policy RespPol_SessionHijack "AAA.USER.NAME.LENGTH.NE(0)&&AAA.USER.SOURCEIP.NE(CLIENT.IP.SRC)" RespAct_SessionHijack bind vpn vserver YourNSGW -policy RespPol_SessionHijack -priority 10 -gotoPriorityExpression END -type REQUEST bind authentication vserver YourAAA -policy RespPol_SessionHijack -priority 10 -gotoPriorityExpression END -type AAA_REQUEST
Bind the policy to your NSGW / AAA vServer:
Now when I try to copy the NSC_AAAC cookie of an authenticated User session on Client2, I’m getting the following page:
Limitations
As this feature works on Source-IP, there are the following limitations based on the architecture:
- NetScaler needs access to the public Source-IP of the User Session
- Protection will fail if the Attacker and the Victim are both on the same network or rather accessing from the same Source-IP
Summary
With that short Responder policy, you’re able to gain a lot more safety for your NSGW / AAA environment. A must have!
Thanks for this, it is a pretty scary exploit if I am able to do it.
One thing we did was instead of popping a message, is instead do a redirect to the https://Gateway/cgi/logout page.
We did this so that people that might sleep their laptops and then move from network to network wouldn’t get blocked and have to find and clear cookies. It also keeps any hackers from knowing that we have your remediation in place and keep trying to find other ways in.
Thanks for that idea, Jeff!
Hi Julian,
I tested and it’s not working so far. Honestly I’m not sure if I’m doing anything wrong.
Is there any cache cleanup that needs to be done at the NetScaler side before testing it?
Hi, it’s directly working after binding the responder policy, there’s no need of any cleanups to be done.