Oh, NOW I have your attention, huh… What started out as an interesting vulnerability in Citrix NetScaler / ADC code going back clear to version 10… just became a bigger problem. And many people were putting off fixing it until today.
My own opinions about this aside in terms of ethical hacking – a group claiming to be acting in the collective best interest of the world has released a code that exploits CVE-2019-19781 and starts mining bitcoin on the ADC.
Note the massive uptick in incidents. These people aren’t doing anyone any favors or trying to make a statement. People are out to make a coin at your expense. But surely it won’t end there so you really need to pay attention!
I (DJ) am working with some additional industry professionals to create a step-by-step course that you or your company will be able to purchase. The course will guide you through what we know so far, what you should know and how to remediate it. More importantly, the course will be updated and updates announced to purchasers and have ‘office hours’ for support via chat. The course will include videos, examples and downloadable templates. The course will be offered thru the Citrix Hero Community, our free Citrix geek exclusive Mighty Network app. Pricing for the course itself has not yet been determined but will be announced by this weekend. To get notification of this offering, join the community or sign up for our email list and get a free e-Book.
What we know about CVE-2019-19781
The vulnerability affects all supported product versions and all supported platforms:
• Citrix ADC and Citrix Gateway version 13.0 all supported builds
• Citrix ADC and NetScaler Gateway version 12.1 all supported builds
• Citrix ADC and NetScaler Gateway version 12.0 all supported builds
• Citrix ADC and NetScaler Gateway version 11.1 all supported builds
• Citrix NetScaler ADC and NetScaler Gateway version 10.5 all supported builds
Basically- it allows an attacker to place arbitrary code into portions of the ADC which can allow for a variety of badness to occur. Badness like grabbing password files or mining bitcoin (or whatever), possibly even attempting to create other backdoors.
One thing I will say, especially given how certain people have responded to this – is that this does not at all shake my faith in Citrix ADCs. Show me a company that has never had an exploit – you’ll see that same company probably is too small to really matter. NetScaler / ADC deployment is massive, and the fact that it took this long to discover the issue at all speaks to the stability of the platform. Those calling for abandoning Citrix ADC are either acting out of fear, trying to profit from it, or are just jerks. No product out there is perfect or will never have an exploit found. Citrix is not ignoring this, though and neither should you. But don’t be that person to use hurtful hashtags or spread fear rather than solutions.
Action Steps for CVE-2019-19781
Last update – 1.17.2020
Fix Script for Citrix NetScaler ADC
Use the instructions at https://support.citrix.com/article/CTX267679right now. The extended Citrix community is working on additional scripts. The easiest way to deploy these is to use Notepad ++ and PuTTY. I say this because you need to be aware of the way that your web browser will display quotation marks verses the way that the ADC will take it. Using Notepad ++ will help identify if you have a bad quote mark. Basically if one looks ‘upside down’ from the other, you need to replace it with one from your keyboard. Fortunately – the fix is quick but does require a reboot to take full effect.
Some builds of NetScaler and Citrix ADC have not been properly applying the remediation patch due to a feature flaw that was patched in later builds. Full information from Citrix can be found here, but this looks to be specifically for builds In Citrix ADC and Citrix Gateway Release 12.1 build 50.28. You can logon to your ADC web admin page to verify the build – look in the upper right hand corner. I will be recommending an update regardless but if you are on this build you have to update for this to work, so I’d do so now.
If someone is cryptomining on your ADC- you’ll see high utilization – but there’s a catch. 100% is EXPECTED on newer versions of NetScaler/ADC.
Here’s what do to. After you’ve run the prevention script and rebooted, get into the shell, or just enter
shell top -n 10
What you are likely to see is a process called NSPEE-00 or similar running at 100%. This is normal. What you DON’T want to see is other strange processes taking up a lot of CPU that stay that way. Knock on wood- so far I have not discovered any clients with active miners. But I have found a few that were compromised. To monitor continuously, just type in top without the -n 10. Once you’re satisfied Ctrl-C will take you out of that.
However, in my mind, cryptomining is a secondary concern. Your company’s information may have been exposed at some levels that have not yet been fully determined.
The big indicator of a compromise at this point is .xml files in directories they don’t belong or have odd names. I will update this list soon but for now, look for some of the indicators noted at https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ Always run the workaround script first, but if you suspect you’ve been exploited, exporting your configuration and configuring from fresh firmware isn’t a bad idea.
If you are compromised:
Take the ADC off the network.
Change the password of any LDAP or other AD/network accounts stored on the ADC.
Re-issue a new SSL Certificate and key file for any client SSL files on the appliance – the keys are stored in files that could theoretically have been read by the compromise.
If this is a VPX appliance, if you have snapshots of the machine prior to Jan 9th, 2020 it may be worth restoring that first but this is NOT A GUARANTEE of safety. My suggestion to be completely sure is to save your configuration file and restore it to a new VPX download.
Restore without starting – NOTE from the field: make sure your restore has the same Hardware address or your license will be invalid…
Disconnect the network before starting
Start the machine and verify using the console that the VPX does not appear compromised
Change the nsroot password
Attach the internal network only
Run the fix (alternatively- type this via the console to be safer)
attach the external network
Keep an eye on the logs
Replace SSL Certificates on the appliance at your earliest opportunity
Timeline and Updates
Jan 13 2020 Citrix has announced a timeline for ADC firmware that will include fixes.
Note- these are the initial timelines superseded on Jan 19th
Expected Release Date
31st January 2020
20th January 2020
20th January 2020
27th January 2020
27th January 2020
Jan 14 2020
I have started working with clients to remediate compromises and double-check other clients. I’ve updated some suggested quick things above.
I’m tracking reports from AWS users that if their nsroot password was not changed during deployment, it would expose their instance ID – if anyone can confirm this please let me know so I can update this. It is probably safe to assume at this point that any information stored in the ADC can be read by someone who knows what to look for. Change those passwords, people!
…more updates as I have validated them – there are a few additional remediation scripts being evaluated by other CTAs and CTPs especially.
Carl Stalhood is at it again, with new build guides for Citrix ADC (formerly NetScaler). He has been so helpful over the years so I thought I’d boost the signal to his site a bit. He is a big reason I don’t currently make my own guides. Why would I need to? His are great! We will keep this post up to date as best we can – Carl moves faster than we do, though!
We’re back, talking more NetScaler Security! This is part of our four part series using my recommended Assess (or Understand), Design (Plan), Change (Build) and Maintain (Manage) Methodology.
In Part One we went into detail on how to assess and find just how secure your NetScaler configuration really is. We went thru a few of the very many leading practices and how to determine variances from them. If you didn’t read that one, go ahead and read it… I’ll wait. If you have gone thru the article and have your spreadsheet (or notes), we’re ready to continue! Also check back on it from time to time- I’ll be updating the article every now and again when new threats or methods emerge!
NetScaler Security Goals
First, let me say outright that we are not taking actions on this step. That will come in Part 3, Change. For now, we are making a plan of action- what do we intend to do in order to address the concerns we have from our Assessment. Setting some goals is key here.
Setting NetScaler Security Goals
Let’s go thru the list and determine what we want for the best balance between simplicity to deploy and good NetScaler security. We’ll start with the Highest Urgency and Importance items.
Score an A+ at SSLLabs.com. Looking from my example, I can see that my NetScaler Gateway is scoring a “C”. I think having an A+ will be a good indicator of acceptable NetScaler security.
Ban SSL3 and TLS 1. With TLS 1.2 supported and 1.3 on the horizon, my goal will be to sunset older SSL ciphers completely for better protection.
Secure the NetScaler Management Interfaces. I want to make sure that the leading NetScaler security practices are followed to prevent attacks. This will include defining ACLs and restricting access to the NSIP interface. And, of course- change the NetScaler’s NSROOT password.
Upgrade to the Best Firmware Choice. As I mentioned in Part One, just because a firmware update has been released doesn’t mean it is automatically best to use it. In my case, I want to be sure the firmware chosen meets minimums for NetScaler security, not features as my primary concerns.
Address Leading Security items. Our assessment indicated at least one leading practice that is security related, so we will validate those settings.
Fine Tune for XenApp and XenDesktop
Several lower priority findings and other items marked as Low Urgency and Importance.
Validate Leading Practices. As the Health Check Summary from CIS indicated there were several leading practices in need of adjustment from the defaults. I’ll focus on the ones that affect overall NetScaler security.
Address Functionality Items. Our assessment had a few items of low priority that may affect the functionality of other systems. In fact, in our case I’m going to even add one that I know needs to be addressed for functionality of the new EDT protocol.
In the Design phase, we will be determining Design Decisions – in this case declaring the configuration changes that will give us the best NetScaler security that makes sense for our use cases.
Score an A+.
I know that to get to A+ I have a lot of things to address, but I am going to first start with a pretty major caveat. Just as I noted in Part 1, we need to declare a minimum support for our SSL settings. If we go too strict, we lose the ability for certain endpoints to connect entirely. On the other hand, we may only want those with secure and updated operating systems to be able to connect at all. For our example, we know that the following is true:
We only support connections from up to date browsers and operating systems. All others are best effort and must meet NetScaler security minimums. That means no XP, Vista or out of date OS configurations. Sorry, for those of you stuck in 2008.
We do not have Thin clients in scope so the need to continue allowing TLS 1.1 to support older thin clients does not apply. We can also apply STS.
First- let’s deal with the same things I mention in my original NetScaler security article about getting the Best SSLLabs Rating (which will be updated from time to time)
First we will go with the most secure Cipher sets and configuration possible. Now- I know a few things going into this that I want to share with you:
First- upgrading firmware. In 2018, SSL Labs will begin downgrading scores for those that are vulnerable. When upgrading firmware, I typically start with the minimum I need and go up to the latest firmware as long as it is at least a month old. This is from experience in feature releases causing disruption for other functions. The most common I’ve seen is problems with AppFlow. If you’re using HDX Insight (and let’s be honest, you should be) this is something you need to be aware of. If you’re not using AppFlow… knock yourself out with the latest; odds are good you’ll be fine. But I can’t stress enough how important validation testing is when upgrading to new major releases (say, 11 to 12 for example). If you’re stuck or less confident- phone a friend. Or contact me using the form over to your right…
The way SSL Ciphers are named gets confusing in a hurry- but the names are organized in such a way that indicates a balance between security and performance. NetScaler Gateway has some pretty specific processing needs, especially when using a VPX which doesn’t have an offload chip. Therefore, the selections we’ll make as primary will be driven by performance first. This means in the case of DHE vs ECDHE, we’re going to favor ECHDE because they will perform better in our use case. If you don’t know what I’m talking about… that’s okay. I barely know myself if I’m being honest. But this what I have tested and deployed to over 50 NetScalers last year. Here’s more information if you are hungry for it: https://docs.citrix.com/en-us/netscaler/12/ssl/supported-ciphers-list-release-11.html Note again- that if you are using a FIPS Appliance, you’ll want to review this: https://docs.citrix.com/en-us/netscaler/12/ssl/fips-approved-ciphers.html The list gets complicated, but few care more about NetScaler Security than those using FIPS appliances. Best to understand what Ciphers will be supported for your appliance because the mileage varies!
We will make a set of Ciphers specific to NetScaler Gateway, which we will refer to as “NSG”
We will separate RSA from non-RSA keys for TLS 1.2 and above, because there is drama emerging there right now. To be flexible in the future, we’ll make it easy to disable the cipher set for testing.
Beware ROBOT. I did a re-scan of my SSLLabs assessment and found that at the end of Feb 2018, my NetScaler security score would be an F! This is due to the firmware being vulnerable to ROBOT attack. You can test for that vulnerability here: https://robotattack.org/. We will update the firmware as part of our process to deal with this threat.
Speaking of SSLLabs- another up and coming trend you need to be aware of is Perfect Forward Security (PFS). To explain this as briefly as possible, there are two ways to achieve PFS, by using DHE or ECDHE keys. Based on my limited testing and research, I have found that ECDHE performs better than DHE, though DHE does offer better security. If you are running an MPX or SPX appliance you may want to look into DHE (Diffe-Helman Exchange). I do not yet recommend this for VPX that are not hosted on SPX. A lot more information can be found here: https://support.citrix.com/article/CTX205282 But- as long as the ECC curves are in place (they usually are if you have any ECDHE ciphers bound, which we will), this is not a concern for you until the ‘rules’ change to favor DHE more heavily. You may also want to enable STS on your StoreFront servers if you have internal connections- but be aware that this may cause disruption to certain thin clients so TEST TEST and then TEST AGAIN!
Note- There are new Ciphers coming soon to support TLS 1.3 – for this article, however I am assuming that we will not have access to that firmware and I’ll update this later with those new sets. We’ll create a Cipher set name that we will keep updated as the latest and greatest and include “CurrentCiphers” in its name.
Other Recommended Settings
Remember that we are going to change our NSROOT Password. I thought about suggesting Active Directory integration for NetScaler as well but that is probably best for another blog post or referring you to other sites. If you’d like to learn more about the process and include it in your document, it is something I recommend as you won’t have your NSROOT password floating all over the place. https://support.citrix.com/article/CTX123782 Regardless- change your NSROOT password on a regular basis even if you have AD authentication configured.
Unless our testing reveals something different, we plan on implementing all the recommendations found in our Scout report. Rather than type them twice, I’ll list them in the design document below.
NetScaler Security Design Document
Pulling from all the items above, we can generate a document that lays out our plan for better NetScaler security so we can share it with others if needs be- but is also very useful if it is something that will take some time to get approved. It doesn’t have to be anything fancy, but I always advise people to write things down first – here’s something to get you started. PLEASE NOTE- these are just the items I found on my assessment example. You’ll want to include any findings you have as well!
Change to a complex password
Store the new password securely! I use Dashlane to store and securely control sharing of passwords with 2FA security. Sign up here to get $20 off for you and give $20 for me too! Way safer than putting them in a file!
Upgrade Firmware to latest stable within our major version release.
We’ll be using the 12.0 56.20 build in our example. I chose this simply as it is the latest at the time of writing and met the criteria of not being vulnerable to CVE-2017-14602 and 2017-17382.
Note- check with your Network Administrator to be sure the Window Scaling option will be supported (SACK is tied to Scaling.) If not, only list Nagle’s. Another key metric here is the Factor for Scaling. Typically 4 is correct but see the article at https://support.citrix.com/article/CTX113656 to be sure you will not need to adjust this value after conferring with your Network Administrator.
Drop invalid HTTP requests
Whenever possible, I believe in using a non-production test environment or components to validate changes before impacting users. Part of our Deployment Plan will involve testing these settings on a test NetScaler VPX prior to deployment in production. Once our changes are validated, we’ll set a time for a production outage so that we can roll back changes if required. For an HA deployment, it is very possible to do the updates in a way that minimizes production impacts. However, with NetScaler Gateway connections will be disrupted when we reboot. So whenever possible with this kind of update, I recommend declaring an outage or at the least setting the expectation that sessions may disrupted during a defined time window when the changes will be made.
So write out a deployment plan with a rollback plan. This is very useful especially when you must generate something for a Change Control board. Here’s the high-level plan:
Save the Running Configuration of the test NetScaler VPX
Upgrade NetScaler Firmware (if HA, use the advice in the article above to list out your steps)
Secure the NSIP Interface by introducing new ACLs (VERIFY before you continue)
Make the other changes noted above
Next time- I’ll guide you thru the process of actually making the changes! When we’re done, you’ll have NetScaler Security at a level of confidence that will exceed most enterprise customers I’ve been visiting lately!
The worst time to find out about problems in your Citrix environment is after they are already happening. But the built-in tools (Director) don’t really always paint the full picture to give you quality Citrix monitoring. You need Proactive Citrix Monitoring and ControlUp is here to help!
Citrix Monitoring Webinar on 11-29-2017
Yoni Avital (Founder & CTO of ControlUp) and I had an hour long CUGC Connect webinar hosted by the Citrix User Group Community! Wednesday, November 29th 2017 at noon Central (US).
Yoni first showed me ControlUp almost 4 years ago and I’ve been enjoying watching them improve every year. I have loved the single-pane-of-glass approach they take to environment monitoring and engagement.
Why View the Replay?
Aside from hearing my soothing voice moderate… Yoni demoed ControlUp 7.1 which I believe excels not only at Citrix monitoring (as in XenApp/XenDesktop) but NetScaler monitoring as well!
New features also include adding nVidia vGPU at the VM and process level to your Citrix monitoring, metrics of your published applications (yay!) and a new troubleshooting feature.
Will there be a Demo?
YES- you’ll be able to see this all in action live in the webinar.
So you have this “NetScaler” thing to front end your XenApp or XenDesktop environment… But maybe you are like me and NetScaler Security isn’t what you spend most of your day dealing with. So, how can you make sure in light of recent security threats that it is running properly? In a post in 2016 I discussed how to get an A+ Rating at SSL Labs for your NetScaler Gateway in under 5 minutes. I figured it was time for an update for 2017 taking some new things into consideration but approach this from the point of view of someone like me that isn’t “A NetScaler Person.”
[*updated 1/4/2019 with new link for Citrix article]
Steven Wright of Citrix Consulting has released another guidance for getting an A+ NetScaler Rating at SSL Labs (SSLLabs.com) on June 9th, 2016. The good news is that I’ve validated it works- read on to see the proof!
Why You Want an A+ NetScaler Rating at SSLLabs.com
Security is very much front-of-mind these days, and fortunately SSLlabs.com has a tool to scan your site, including NetScaler Gateway, to detect known problems against current threats.
In case you missed it, you have a whole new reason to re-visit your NetScaler SSL configuration, even if it is a VPX which previously didn’t support nifty security like TLS 1.2. This changed after the last round of updates, so you no longer are forced into an MPX to get good security (though admittedly the CPU usage is a bit higher without the offload chip offered in the MPX and SDX platforms).
If you are running a NetScaler VPX, your out-of-the-box configuration will likely give you a NetScaler Rating of either an F or a C in most cases. Around here, we go for the big grade- so here’s how to get an A+ NetScaler Rating, even with a VPX.
Words of Warning
A few caveats that I know of – First off- I don’t really consider myself an authority on NetScaler, so take all of this with a grain of salt and ALWAYS TEST BEFORE YOU GO LIVE IN PRODUCTION. Messing with SSL ciphers can cause outages, especially for NetScaler Gateway.
Second, if you need to support older clients, especially Windows XP clients, be VERY CAREFUL deploying all of these settings. You may be stuck with a “C” score for needing SSL v3 to stay turned on in some cases. Even a C rating can still be very secure, this is just how SSLLabs.com rates things even if there’s just one attack vector left (unfortunately, SSL is a big one).
But… if not, you can get a score that looks more like this:
What an A+ Rating looks like from a NetScaler Gateway VPX
Before we go further, I want to reiterate that I’m just validating what someone else created- don’t credit me with this, Steven Wright and Citrix Consulting Services (CCS) did all the work making this possible! Even though I still do occasional work for CCS, I want to make sure noone gets confused!
The nice thing here is that the blog article has all the steps you need, so break out that puTTY connection and get started!
First things first- note your current rating at SSLlabs.com – I typically do NOT share my results, but feel free if you like to brag.
My configuration included a more modern GoDaddy SSL cert with SHA256 and RSA 2048 strength on a NetScaler VPX 200 with the Enterprise license.
I tested this with firmware 11.0 65.72.nc using the NetScaler Gateway wizard. In my case, it works, so don’t hate me for taking a shortcut 🙂
As I mentioned above- this gave me a NetScaler Rating of “C”. You can test yours by going back to SSLLabs.com and hitting ‘clear cache’ to re-test.
SSLLabs C Rating on NetScaler VPX
Going from C to B
Disable SSL v3
I Disabled TLS 1 and 1.1
I tried first enabling ECDHE cipher group settings included as a default
Not too bad- a Solid B with this change! I thought it would be an A- but I think there may be a few things in the ECDHE group that will rob you of the rating. You’ll need to define your ciphers manually.
SSLLabs B Rating on NetScaler VPX
Getting a NetScaler Rating of A+
Removed Ciphers (all)
Implemented STS (Strict Transport Security)
Added the cipher lists that Steven came up with, below
Bound the new cipher sets and made sure to use the ECC Curve configuration
Here's the commands to use in the CLI- note that everything in BOLD ITALIC is a name you will need to give it yourself, not a specific command.
add ssl cipher custom-ssllabs-cipher
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-AES-256-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-AES-128-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName SSL3-DES-CBC3-SHA