Netscaler Endpoint Analyse (EPA) Pre-Authentication bypassing!

UPDATE: bypassing the EPA scan with this method is only possible when using the Netscaler default settings. read the update at the end of this article, which explains how to enable encryption for the client security expressions.

Citrix Netscaler Gateway offers the ability to scan client computers and check certain requirements. these include operating system, ports, registry, antivirus, files and a many more items.

these scans can take place even before a user logs in and we can control who actually is able to see the login page at all. if a scan fails, the user gets redirected to an error page and can then run the scan again. with this feature, we can check if a computer is a business device or a home computer and for example block all private devices.

first i need to say that remote client security is very difficult to control, because an administrator of a machine can virtually do anything he wants. this includes debugging of running code, analyzing and manipulating network packets and intercepting http requests. an endpoint analyse software can therefore be analyzed, monitored, modified and tricked to send back wrong results.

just out of curiosity i have analyzed the Netscaler EPA scan and tried to bypass it. this turned out to be very easy and im somewhat surprised, that it is implemented in such a weak way. actually i have found a very simple backdoor and also some unwanted information leaking – an attacker can easy find out, which components must be present on an endpoint to pass the scan.

just for proof of concept, i have also used sysinternals procmon and i was able to find the registry and filechecks pretty easy – this is why i said, client security is difficult to control – these checks cant be really hidden on the endpoint and will always be revealed rather quickly.

but even if a company decides to add 100 checks for files, antivirus, registry keys, domain membership etc, etc – my discovered backdoor will allow a quick access to the login page and tricks the EPA scan.

first, let me explain how the EPA scan in detail works:

epa_scan

i discovered this by using OWASP ZAP Proxy while analyzing the http requests. by doing so, i have found something very interesting. when the epa client connects to the /epaq to load the items for local execution, the configuration is transfered IN CLEARTEXT!!! this means, we can very quickly find out, which items the EPA scan actually checks on the endpoint. but this is information, that an attacker shouldnt get that easy! check here the screenshot from ZAP:

zap_config

this is exactly what i have configured in my netscaler EPA Pre-authentication policy! a domain check for “mydomain.local” and the file “c:\securefile.bin” – ouch! sure, the connection from the client to the Netscaler is SSL protected, but with a local proxy, we can intercept this traffic and analyze it.

but it gets actually even worse – after that checks, the EPA client sends the result back to the Netscaler – and by results i mean just a result code!

epa_code

i analyzed a successful EPA scan and the code just changed to 00 – now guess what we can do here? yeah… with ZAP we can set a breakpoint on the /epas url and then simply change the resultcode – this will completely override the EPA scan result and we can get the login page with a non compliant machine!

the question is, can we even trick the EPA scan without ZAP? yes we can – with a simple Firefox addon called Modify Headers!

modifyheaders

just install the addon in firefox and add the custom header “CSEC” with the value “00” to it. now we can recreate the process explained on first image with our browser – but because it needs the cookies that Netscaler sends in the first request, we cannot simply surf to the /vpn page directly. here is how you can do it, if you dont want to use ZAP – just dont forget the Modify Header plugin and to set “CSEC=00”.

  1. open the root page from the Netscaler Gateway and let it redirect to /epa/epa.html
  2. the EPA client will launch – dont close it!
  3. now surf to the same site but change the url to /epatype – it will display “Epa:on;deviceCert:off;”
  4. change the url manually again to /epaq – an empty page will appear.
  5. put /epas in your browser and it will display “10”
  6. now surf to the main site or add /vpn/index.html to the location bar
  7. done. you are able login with your credentials now, even if the computer didnt pass the EPA scan!

it does not really matter, what the EPA client scans on the machine – the custom header must match “00” and all is fine! not so good 🙁

how could this be improved then?

  • the Netscaler should at least check, from which client the requests are sent (User-Agent, nonce)
  • configuration should be encrypted and not clearly visible in the http traffic (DH Key Exchange, proper Crypto)
  • result code should be something unguessable or use encryption to protect it
  • the EPA client could also check for procmon and other reverse engineering tools

i did not yet analyze how the EPA scan works when using it in a session policy. some items can be configured to be checked with a time interval – im not sure, if this can be tricked too – but for the pre-authentication policy this doesnt really matter.

the best solution for EPA and pre-authentication is definitely to use client certificates – i was not able to trick EPA when i had configured a client certificate check!

i have informed Citrix Security about this issue and the answer is pending – as soon ive get a statement, ill post it here.


UPDATE 31.05.2015:

i did analyze the nsepa.exe to see if its possible to patch it and it is actually possible! with a hex editor its easy to look for “CSEC %s” and replace the “%s ” with “00” and the EPA scan will always pass. this means, there is no integrity checking and no encryption or obfuscation in the binary itself. this is a dirty patch and might corrupt the stack, but its the most easy way and the nsepa.exe is terminated after the scan anyway.

nsepa_patch

but now comes a good message! looking at this binary reveals some interesting strings “Encryption of CSEC result failed” – hey this is exactly what we want in this scenario – an encrypted CSEC value, but where can we configure that?

i have found this little checkbox in the global settings under security of the Netscaler Gateway:

epa_secure

this setting is disabled by default, but it should actually be enabled on every Netscaler that uses EPA. this does exactly what it should have been done from the beginning: it encrypts the CSEC values and even the result code.

encrypted_epa

now its not possible anymore to see what the EPA client scans and also the result code is not visible anymore. i even tried to resend the same encrypted result code in a new session, but this didnt work. the encryption is based on RSA and AES – i did not analyze this in detail (yet) and cant tell if its secure, but it will stop an easy attack!

for some reason this setting is not documented very well – if you google “Client Security Encryption” and Netscaler, you wont find that easy what this setting really does. the popup in the Netscaler GUI states “Enable encryption of client security expressions” and googling this gives only a few hits where only two are from citrix. you can set this checkbox with “set vpn parameter” on the command line:

encryptCsecExp

Enable encryption of client security expressions.
Possible values: ENABLED, DISABLED
Default value: VPN_SESS_ACT_DISABLED

conclusion: it turned out, that Netscaler has the correct security already built in, but its not enabled by default. i suspect, that most installations with EPA scans dont have this setting enabled and the therefore it can easy be bypassed. in my opinion, citrix should enable this feature by default for every Netscaler. i for sure will in the future 🙂

if you scan for registry keys or files, try to hide them as good as possible. dont use keys like HKLM\SOFTWARE\MyCompany and dont check for obvious filenames either. as i said earlier, with a procmon an attacker can find these values rather easy, but if you check for something like HKEY_CLASSES_ROOT\CLSID\{CAFEEFAC-0017-0000-0009-ABCDEFFEDCBA}\InprocServer32 its not so easy to locate, because the nsepa.exe queries a lot registry keys itself already.

the nsepa.exe itself does still not contain additional security and can be modified and debugged. here is a PoC patch (with hackers view) that will change the nsepa.exe and set the result code to “0” before it gets encrypted. this will override all EPA scans (Version 10.5.57.7).

hiew_nsepa

you can download the patched nsepa.exe (10.5.57.7) here. just replace it with your local one at “C:\Program Files\Citrix\Secure Access Client” and it will pass any EPA scan – even if the Client Security Encryption is turned on.

as stated in the beginning – client security is not easy to achive, but for sure there are ways to make it better. i actually like to see some additional protection in the nsepa.exe and the encryptCsecExp should set be to enabled in future Netscaler versions. also the EPA scan should better submit something more secure than just a result code – this is too easy to manipulate.

 

Be the first to comment

Leave a Reply