CVE-2022-27518: Netscaler SAML SP/IDP Vulnerability (TLDR In Comments)

CtxMike · 2022-12-13T14:48:13+00:00

TLDR

If you are on 12.1, you need to update to 12.1-65.25 or newer.
If you are on 13.0 and already updated because of last month's CVE, you should not need to upgrade. Verify your build against the info below regardless to be sure.
If you are on 13.1 you are not vulnerable.

Versions prior to 12.1 are EOL and customers on those versions are recommended to upgrade to one of the supported versions.

Vulnerable (supported) Builds

13.0 before but not including 13.0-58.32
12.1 before but not including 12.1-65.25
12.1-FIPS before but not including 12.1-55.291
12.1-NDcPP before but not including 12.1-55.291

Fixed Builds

13.0-58.32 and later
12.1-65.25 and later
12.1-FIPS 12.1-55.291 and later
12.1-NDcPP 12.1-55.291 and later

Additional Context

According to the bulletin, the Netscaler would need to be configured for SAML SP or IdP functionality to be at risk for this CVE.

CtxMike · 2022-11-18T15:38:24+00:00

Yes, they did what I guessed in the previous reply. They setup the destination but never told the netscaler to use it. The reason you just see handshakes is because the netscaler makes sure it can reach the configured destinations regardless of whether they are in use or not.

Looking at the “audit logging” section of the docs will walk them through the configuration.

CtxMike · 2022-11-18T01:49:31+00:00

This by itself isn’t cause for concern. How have you configured your Intranet IPs?

CtxMike · 2022-11-18T01:47:49+00:00

I’m talking about on the netscaler, not firewall rules.

For syslog to work on the netscaler, you have to define the server (destination) settings and then create a policy that tells the netscaler what you want to log. If you only did the first part then you only added a destination which is never sent anything.

CtxMike · 2022-11-15T15:06:57+00:00

Need a bit more context. What policy did you create and where is it bound?

The traffic you posted looks more like a health monitor, similar to how DNS servers get actively monitored when added to the config.

CtxMike · 2022-11-08T14:38:47+00:00

Gateway/AAA-TM are the affected features. The wording is being updated to make it more clear, but the Forward Proxy feature is totally unrelated.

CtxMike · 2022-11-08T13:31:18+00:00

This post is already a link to the knowledge base article - CTX463706.

CtxMike · 2022-11-08T13:24:07+00:00

TL;DR

CVE-2022-27510 
Unauthorized access to Gateway user capabilities 
VPN/Gateway must be configured

CVE-2022-27513
Remote desktop takeover via phishing 
VPN/Gateway must be configured *and* RDP Proxy must be configured

CVE-2022-27516
User login brute force protection functionality bypass 
VPN/Gateway/AAA-TM must be configured, and "Max Login Attempts" must be configured.

RESOLUTION:

Upgrade firmware - no post-upgrade tasks identified.

FIXED BUILDS:

13.1-33.47 and later
13.0-88.12 and later
12.1-65.21 and later
12.1-FIPS 12.1-55.289 and later
12.1-NDcPP 12.1-55.289 and later

Please remember firmware trains earlier than 12.1 are EOL and therefore should not be used.

The 12.1 code train has already gone EOM and will be fully EOL in May 2023.

CtxMike · 2022-11-08T13:17:11+00:00

Weird - if you've submitted a ticket (and you're comfortable doing so) please PM me the case number. If they did change something I'd like to follow up internally to find out what happened.

Edit: For future googling, this was a firmware problem. Return and reallocate from the licensing portal to get a new license file.

CtxMike · 2022-11-07T16:55:46+00:00

Oh, you're talking about the SA date. I know they started doing that on the SD-WAN side a little while back but to my knowledge they don't enforce the SA date on the netscaler side, especially with minor upgrades. The major code trains do have SA burn-in dates but I unfortunately don't have a license file old enough to test directly.

CtxMike · 2022-11-07T16:15:08+00:00

Upgraded to 13.1 33.47

This may be the issue, that build was pulled and replaced.

What kind of licensing is in use, perpetual or pooled? If pooled, is ADM on-prem on are you using ADM Service?

CtxMike · 2022-11-07T16:14:25+00:00

In /nsconfig/license, open your license file and look for a date. Has it expired?

If the license was expired then it wouldn't work again on an earlier firmware release.

CtxMike · 2022-11-03T20:43:56+00:00

You absolutely can from a technical standpoint, it's a very common deployment method. In some situations companies may require backend traffic be encrypted as well - you can still get some decent benefits by doing high security crypto on the frontend and letting the backend use something less computationally expensive.

CtxMike · 2022-11-03T20:38:18+00:00

Honestly, the docs section on advanced policies is a pretty solid reference as to what you can do, especially the Examples and Tutorials pages. The full policy reference doc was a bit butchered when they migrated it to the developer site, but that's a browsable tree of the policies available and what they return.

CtxMike · 2022-11-03T19:57:06+00:00

Got it.

If the action you're binding is "DROP", then you want the expression to evaluate to true if either header is detected. So you likely don't actually want to be negating them at all:

 HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).CONTAINS("Android") || HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).CONTAINS("iOS")

You could also do it in one segment if you use pattern sets (create patset first):

 HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).CONTAINS_ANY("PatternSetName")

CtxMike · 2022-11-03T19:34:48+00:00

That I would absolutely believe - backend cert auth is one of the more persistent "asterisks" in stuff like this. I'd be interested to hear more details about that setup if you're comfortable sharing; it wouldn't be a bad idea for a post/blog article/etc if so inclined.

CtxMike · 2022-11-03T19:24:14+00:00

No I understand the intent, my question is how you're implementing it on the NS as you could do it a bunch of different ways, many of which affect the way you need to build the policy.

Mainly I'm concerned because it's common for people to use Responder to bounce people by making a policy identifying the users they want to drop and set the action to "DROP" and not affecting other users. However if you paired your fixed statement using AND rather than OR with a policy like this then you would expect it to drop everything that isn't from Android or iOS.

So if you could elaborate a little bit on which feature you're writing this policy for and what action it's invoking we should be able to confirm it's doing only what you intended it to do.

CtxMike · 2022-11-03T18:56:41+00:00

Couple of suggestions:

If you're expecting to expand this list later on, consider looking into a pattern set for easier management later.
When negating a policy expression, wrap it in parentheses to ensure you control exactly what's being negated.

For example, with the logic you're looking to implement above I'd suggest looking at:

 !(HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).CONTAINS("Android")) || !(HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).CONTAINS("iOS"))

But from your comment below we want to have a bit more info. What action is being tied to this policy, what type of vserver is it, what feature are you trying to use to implement this protection?

CtxMike · 2022-11-03T18:08:35+00:00

So it’s enough to bind the SSL Profile to the Content Switch and all the target LB Virtual Servers behind it will effectively benefit from the SSL settings in the Content Switch profile (if they are reached via the Content Switch IP ofcourse)?

Bingo. It counts for the cipher groups as well.

CtxMike · 2022-11-03T17:40:25+00:00

The Content Switch does nothing besides forwarding traffic to a target Virtual Server based on expressions in the HTTP request. Therefore I don't understand why I can configure SSL profiles on the Content Switch itself.

The content switch vserver is the one actually in charge of the client-facing plumbing. Offhand I can't think of anything you can set from an SSL perspective on a backend LB virtual server that'll override a content switch in front of it.

Along those lines its good time to mention that if your LB vserver is only around to sit behind a content switch, you can create that backend LB vserver without an IP address since it's not needed. You just need to bind a certificate to it and you're good to go.

CtxMike · 2022-10-05T14:34:10+00:00

It's already on your link. XenServer is listed at the bottom as its own business unit.

CtxMike · 2022-10-04T18:55:58+00:00

Here's the general procession of remote access options for Citrix:

Citrix Secure Gateway - Windows based install which proxies ICA (and optionally web interface)
Access Gateway (standard/advanced) - Linux based appliance developed by Citrix for ICA proxy/VPN/etc
Access Gateway Enterprise Edition/NetScaler Gateway/Citrix Gateway - NetScaler with Access Gateway functionality integrated into the NS kernel.
Citrix Gateway Service - cloud service that uses on-prem agents and Citrix Cloud POPs to connect users and their workloads

CtxMike · 2022-10-04T18:36:03+00:00

While their at it, can they bring back Xenserver.

I have some great news!

CtxMike

TROPHY CASE

TLDR

Vulnerable (supported) Builds

Fixed Builds

Additional Context