At the beginning of the week I wrote here about the Cookie’s that the Netscaler uses for persistence. In that post I explained how I discovered that the Cookie name was encrypted using a simple substitution cipher. The cookie value itself was encrypted to contain the Service IP (the IP of the server that your session sticks to) and the Service Port.

I assumed that this part of the cookie was encrypted using a “real” encryption method such as SHA-256 or some other similar cipher. I spent the next couple of days looking online to see if I could match the cookie length and output (it’s all Hex) to a cipher. In the end I gave up, not because it was too difficult but because I thought of a more cunning plan.. 🙂

This is an example Netscaler cookie (and by example I mean from a website on the internet);

NSC_wtsw-bmufsjbo-qvcmjd-iuuq=ffffffffaf18363b45525d5f4f58455e445a4a423660

My previous post dealt with how the “encrypted” cookie name was formed (that’s the bit up to the ‘=’), this post is about the 8 characters after the ffffffff (everything else after that apart from the last 4 characters seems to be padding).

This is what I knew about the encrypted values:

- The cookie started with ffffffff which I believed was not required to identify the Service IP.
- The output was Hex, so I assumed that there must be some way to reverse engineer the encryption back to the real IP.
- The encrypted value for each octet of the IP address was not encrypted using the same method (I knew that because when looking at cookie value I could see the same IP octet encrypted to different values in the cookie).
- The encrypted values were consistent across different Netscalers (ruling out the encryption being based on appliance specific details i.e. hostname or MAC address).

In order to decrypt the Service IP out of the cookie I could decided that using a VPX (Virtual Netscaler) I could generate a cookie value for each of the 255 IP address in each octet, armed with the power of Excel and Notepad I generated the necessary Netscaler config to create my samples and then using this command on the Netscaler;

`show lb vserver [vserver name] | more`

This allowed me to see each server and the matching Netscaler cookie value. I started entering these into Excel with the “real” IP value. I had worked through about 60 of the last octet (starting at x.x.x.0) when I realised that I was seeing a pattern. To work out the pattern I took a wild guess (they are the best sometimes) and tried this in Excel;

=HEX2DEC(CELL)-Real Value

This was the breakthrough I was looking for.. and here’s why

On the last octet of the IP address the Hex value 11 was really 0 if you the formula above you get the result “17”, use this formula for the next 16 real values (remember I have collected 60 already from earlier) and you see the following pattern:

Real Value Difference

0 17

1 15

2 17

3 15

4 17

5 15

6 17

7 15

8 17

9 15

10 17

11 15

12 17

13 15

14 17

15 15

Carry on for another 16 and you find this:

Real Value Difference

16 -15

17 -17

18 -15

19 -17

20 -15

21 -17

22 -15

23 -17

24 -15

25 -17

26 -15

27 -17

28 -15

29 -17

30 -15

31 -17

The next 16 after this repeated first example, in fact all of the decryption for each octet required a repeating pattern, I just needed to find the key. Before rushing ahead I used the 2 patterns above to fill the remaining last octet of 255 addresses but I swapped the formula to create the Netscaler Hex value (and save myself sometime);

=DEC2HEX(Difference+Real Value)

I then double checked this was correct by looking at my other generated cookie values and checking some from another 2 Netscalers that use this method in “live”. I was one happy geek, I then needed to do the same pattern matching for the other 3 octets, but because I knew I was looking for a pattern I only needed to generate a smaller sample set to work with.

Whereas the first pattern I discovered was based on chunks of 16 the others weren’t, the first octet is using the numbers 1 & 3 in chunks of 4 (and the negative values for these as well), the second octet is just based on 8’s in chunks of 8(+8 and -8), and the third was totally random (not the pattern, more the logic behind it) and work on 2,6,10,14,18,22,26 & 30 in chunks of 16 again(and then the negative versions).

Rather than boring you with pages of information I’ve produced a PDF with it all in here.

So I’ve tested this as much as I can, and it works, the cookies I’ve looked at (where I know the Service IP) matches against this decryption sheet and again that is over 4 different Netscalers, running different appliances, IP addresses and versions of firmware.

Once I learn how to write in some sort of programming language I am hoping to write this into an application, where you can input the cookie value and it will provide you the decrypted values, I can think of a couple of uses outside of Netscaler administration and I’m sure any Pen Testers/Ethical Hackers reading this can probably think of a few more.. 🙂

So to recap, I now know how to decrypt the Load Balancer name from the Cookie name and the Server IP from the Cookie value, the remaining part is the Service Port but I’m not too worried about that (at the moment) as I know that it if a Netscaler cookie ends 3660 then it’s port 80.

Let me know if you have any questions or feel that my maths is wrong somewhere along the line..

Happy cookie decrypting.

The Geek

I’m a pen-tester and came across a client which also had the “NSC_” netscaler cookie. When looking on the internet I came to your posts about it.

Using your PDF I’ve figured out how they are encoding/decoding the IP address. It’s a simple XOR operation. Since I only have come across cookies with 3660 at the end I can only assume they used the same XOR trick for the port.

The XOR key for the IP is “03081e11”. So if you take ‘af1fe728’ from your example in part 1 you get “af1fe728 XOR 03081e11 = ac17f939 (172.23.249.57)”. Because of how XOR works getting the XOR key is quite easy if you use the ip 0.0.0.0 (first row in your PDF), there the ‘difference’ is the actual key (decimal: 3 8 30 17 = 03 08 1e 11).

As for the port I can only guess that because 3360 is port 80 that the XOR key will be 3630 (3360 XOR 3360 = 50, 80 in decimal).

I don’t know what the ‘45525d5f4f58455e445a4a42’ part in the middle is, but using google I see that there are alot of netscaler cookies which have this part.

Hi Daniel,

First off I’m pleased that you were able to use my posts about the Netscaler cookie’s, I’m hoping maybe to get into Pen testing in the future so that the fact it’s helped you in that aspect is an added bonus. 🙂

Secondly thank you for taking the time to come up with a much simpler solution, that makes decrypting them a lot easier and makes more sense then the rather large spreadsheet.

Edit: Sorry forgot to say the ‘45525d5f4f58455e445a4a42’ part in the middle I think is just padding, it never seems to change regardless of the service IP or port. Port 3128 is ‘encrypted’ as 3a08 and the difference for the last 2 digits is 48 & 16. So a real zero is a Netscaler ’30’ (if that makes sense).

Adam

Hi Adam,

I’m glad to help, if port 3128 is ‘encrypted’ as 3a08 then my assumption that it is XOR-ed with 3630 is correct.

If we XOR the encrypted port 3a08 with the key 3630 the result is ‘0C38’, in decimal that is 3128 and that is the correct decoded port :D.

Pingback: Netscalers: Making sense of the cookie – the finale « The IT Geek Chronicles