In the last week, Citrix have released an advisory which included a fix for a critical RCE vulnerability within Citrix ADC and NetScaler Gateway. There have been indications that the exploit for this has been sold on the internet since some time in June, however this advisory solidified the presence of a real vulnerability.
If you are just looking for a script to determine the exploitability of this issue for your Citrix machines, you can obtain our detection script here: https://github.com/assetnote/exploits/tree/main/citrix/CVE-2023-3519.
Note: our analysis so far indicates that SAML has to be enabled for exploitation, this may change as we continue to reverse engineer this vulnerability. We will update our blog post accordingly.
We’ve spent a lot of time auditing and reviewing Citrix’s ADC and NetScaler Gateway in the last year, leading to the discovery of CVE-2023-24488. Upon seeing the advisory of CVE-2023-3519, our security research team has been tasked to build accurate detections for this issue for our Attack Surface Management platform.
In this blog post, we’ll be describing our efforts so far in reverse engineering Citrix and our analysis from the patch diffing that we performed. We do not yet have a working exploit chain, however we have worked on a detection mechanism that is higher signal than relying on Last-Modified dates or scraping version numbers from /vpn/pluginlist.xml.
As we are still working through the process of reviewing the patch diffs, our analysis is not complete and will be updated as we discover more information about this vulnerability. Given that this vulnerability is being exploited in the wild, we wanted to share what we know so defenders can better detect vulnerable instances on their attack surface.
The Citrix website does not make it obvious for where to register an account (necessary to claim the licenses). We were able to register a Citrix account through the following link: https://onboarding.cloud.com/. After the account has been registered, you can head to the following link to claim an evaluation license. You will need to repeat this process twice to obtain two evaluation keys (one for your patched instance and one for your unpatched instance).
After obtaining copies of each version we generated a BinDiff file for their nsppe binaries. When comparing these we found roughly fifty functions were different and proceeded to investigate each one. Eventually, we got to ns_aaa_saml_parse_authn_request and noticed an error log was added in the patched version. From the message it sounded like a check was added to ensure a list of canonicalization methods did not exceed a maximum value. Our suspicion was that in the unpatched version, it is possible to exceed this limit.
We believe that this issue is within the SAML processing components of Citrix ADC and NetScaler Gateway. We appreciate the analysis from Ron Bowes which came to a similar conclusion as us on this issue.
In the ns_aaa_saml_parse_authn_request function the SAML payload is parsed into a struct containing the relevant details. We believe this struct includes a fixed array of canonicalization method values. Each time the parser sees a new CanonicalizationMethod tag it checks the Algorithm attribute against a list of supported algorithms and adds an associated enum value to the array. In the unpatched version there is no bounds check performed and as such, it is possible to write off the end of the array. This corrupts the rest of the struct and any allocated memory that follows.
Because the parser checks the Algorithm attribute and writes a corresponding enum value, we were only able to write bytes 0x3 or 0x2 into this buffer. Through this, it was possible to cause segfaults and corrupt memory, but we have not been able to demonstrate RCE so far.
In addition to our analysis above, we noticed that the behaviour above can only be triggered if SAML is enabled. It seems that the requests are stopped pretty early in the chain when SAML is not enabled.
This is not a final assessment of the issue as there may be different entry points that do not require SAML being enabled. The advisory from Citrix and all public information so far also does not mention the requirement of SAML having to be enabled to exploit this issue
Based off the responses returned by Citrix, we were able to determine whether or not a Citrix instance may be vulnerable through the following error oracle:
- SAML Disabled ->
Matching policy not found while trying to process Assertion; Please contact your administrator - SAML Enabled + Patched ->
Unsupported mechanisms found in Assertion; Please contact your administrator - SAML Enabled + Unpatched ->
SAML Assertion verification failed; Please contact your administrator
This error oracle works by sending a POST HTTP request to /saml/login where the SAML assertion contains 11 instances of CanonicalizationMethod whereas the max permitted on patched instances is 10. This check does not cause any disruption on the instance and there is a clear difference between an unpatched and patched instance in the error messages.
The following request will trigger the error: SAML Assertion verification failed; Please contact your administrator error message on unpatched instances. on unpatched instances:
POST /saml/login HTTP/1.1
Host: 192.168.1.225
Connection: close
Content-Length: 3150
Content-Type: application/x-www-form-urlencoded
SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0icGZ4NDFkOGVmMjItZTYxMi04YzUwLTk5NjAtMWIxNmYxNTc0MWIzIiBWZXJzaW9uPSIyLjAiIFByb3ZpZGVyTmFtZT0iU1AgdGVzdCIgRGVzdGluYXRpb249Imh0dHA6Ly9pZHAuZXhhbXBsZS5jb20vU1NPU2VydmljZS5waHAiIFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUE9TVCIgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPSJodHRwOi8vc3AuZXhhbXBsZS5jb20vZGVtbzEvaW5kZXgucGhwP2FjcyI%2BCiAgPHNhbWw6SXNzdWVyPkE8L3NhbWw6SXNzdWVyPgogIDxkczpTaWduYXR1cmUgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPgogICAgPGRzOlNpZ25lZEluZm8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgIDxkczpTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjcnNhLXNoYTEiLz4KICAgICAgPGRzOlJlZmVyZW5jZSBVUkk9IiNwZng0MWQ4ZWYyMi1lNjEyLThjNTAtOTk2MC0xYjE2ZjE1NzQxYjMiPgogICAgICAgIDxkczpUcmFuc2Zvcm1zPgogICAgICAgICAgPGRzOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNlbnZlbG9wZWQtc2lnbmF0dXJlIi8%2BCiAgICAgICAgICA8ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8%2BCiAgICAgICAgPC9kczpUcmFuc2Zvcm1zPgogICAgICAgIDxkczpEaWdlc3RWYWx1ZT5BPC9kczpEaWdlc3RWYWx1ZT4KICAgICAgPC9kczpSZWZlcmVuY2U%2BCiAgICA8L2RzOlNpZ25lZEluZm8%2BCiAgICA8ZHM6U2lnbmF0dXJlVmFsdWU%2BQTwvZHM6U2lnbmF0dXJlVmFsdWU%2BCiAgPC9kczpTaWduYXR1cmU%2BCiAgPHNhbWxwOk5hbWVJRFBvbGljeSBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OmVtYWlsQWRkcmVzcyIgQWxsb3dDcmVhdGU9InRydWUiLz4KICA8c2FtbHA6UmVxdWVzdGVkQXV0aG5Db250ZXh0IENvbXBhcmlzb249ImV4YWN0Ij4KICAgIDxzYW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPnVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0PC9zYW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogIDwvc2FtbHA6UmVxdWVzdGVkQXV0aG5Db250ZXh0Pgo8L3NhbWxwOkF1dGhuUmVxdWVzdD4%3D
On unpatched instances, you can include as many instances of CanonicalizationMethod where all of them are parsed, before the flow failing due to the SAML assertion having an incorrect signature. On patched instances, it assumes that there is something wrong before getting to the verification step.
We also discovered the endpoint /cgi/samlauth which expects a SAMLResponse, but this endpoint also requires SSO to be configured in order to exploit this vulnerability based off our testing. At this time, we have not discovered an endpoint which allows for exploitation without SAML being enabled.
We’ve built the following Python script to detect the presence of this vulnerability: https://github.com/assetnote/exploits/tree/main/citrix/CVE-2023-3519.
Our checking mechanism is much more high signal than anything currently out there when assessing exploitability. Most other scanners and scripts are relying on version based checks to determine the exploitability of this issue. So far based on our analysis, SAML needs to be enabled to make the system vulnerable.
As always, customers of our Attack Surface Management platform have been notified for the presence of this vulnerability. We continue to perform original security research in an effort to inform our customers about zero-day and N-day vulnerabilities in their attack surface.