Jump to content
Welcome to our new Citrix community!

NetScaler EPA registry scan


Recommended Posts

Hi!

 

I'm experiencing some issues with the EPA registry scan. The documentation I found in a CTX article and eDocs is conficting.

 

http://docs.citrix.com/en-us/netscaler-gateway/11/vpn-user-config/endpoint-policies/ng-endpoint-expressions-client-security-preauth-con/ng-endpoint-expressions-for-registry-policies-tsk.html

 

The link above defines the syntaxes for querying the registry keys, the confusing part is the use of \, \\ and \\\\ (defined in the first part of the page).

 

http://support.citrix.com/article/CTX205267 indicates that there is another syntax to be used. In the examples here \\ is used before any underscores. 

 

When using the OPSWAT Editor in NS11 i get the following Query when adding a check for HKEY_LOCAL_MACHINE\Keyname_ValueToQuery.

 

CLIENT.SYSTEM(REG-NUM_PATH_==_HKEY\\_LOCAL\\_MACHINE\\\\Keyname\\_ValueToQuery_VALUE_==_1[COMMENT: Numeric Registry]) EXISTS

 

I expect this query to check for a DWORD value of 1 for ValueToQuery in the registry key HKEY_LOCAL_MACHINE\Keyname.

 

Does anyone have an example of a working query for NS11? I've tried the same queries on NS 10.5 as well, but the same issues are seen here as well.

 

EPA Policies with MAC and domain check works as expected, so it's only the registry queries I'm experiencing issues with.

 

I've also noticed that sometimes the policies I've made with the OPSWAT editor get changed when I edit the policy in the GUI, resulting in queries like this:

 

CLIENT.SYSTEM('REG-NUM_PATH_==_HKEY\\\\_LOCAL\\\\_MACHINE\\\\\\\\SOFTWARE\\\\\\\\

 

 

 

 

Link to comment
Share on other sites

Here's a sample from a working NetScaler:

 

CLIENT.REG('HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\CurrentControlSet\\\\Services\\\\Tcpip\\\\Parameters_Domain').VALUE == domain.name.local || CLIENT.FILE('C:\\file_directory\\filename.exe') EXISTS

 

Hi Jason!

 

Thanks for the tip. Simple EPA works as expected (tested OK with both String and DWORD values), but it seems like it might have a bad bug (?)...at least on NS11.0 64.34. Just for the test i used your query in a preauth policy, and this is the result:

 

Date:

3/23/2016

  Time:

21:15

  Error:

Case ID : 13fd6

Access might have been denied because of following issues. Please retry after rectifying relevant issues

  • 'C:file' file doesn't exist on your system
  • 'HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\ServicesTcpip\Parameters\Domain' registry's value doesn't match

 

I'm not that happy with disclosing or giving hints about what our scan is looking for. I just want it to state that it has failed. This is the first time I've seen this "troubleshooting" information when configuring an EPA scan. All my tests with advanced EPA scans have not disclosed any information on what I'm checking for (found the query with Fiddler when encryption was turned off - which is default, when encryption is enabled there is no trace of the query). Not sure if this behavior is by default, or if I accedentialy enabled some kind of feature that disclose more information than I want it to?

 

 

Tip: To encrypt client security expressions, go to Global NetScaler Gateway Settings -> Security tab -> enable "Client Security Encryption". This will encrypted the CSEC value. This way there is no way of snooping around to check what the EPA client is looking for.

 

 

Anyways, I would really want to achive this by using the advanced EPA queries, and not the old "legacy" ones. Have you tried the OPSWAT editor making an advanced query for the same scan? If so, does it work for you?

Link to comment
Share on other sites

  • 4 years later...

Agreed, I think that comparing hash values might be a better solution (unless someone turns a debug option on), as is it's very easy for someone to game an EPA scan by reading the logs.

Using the EPA editor to create a query for registry values is very confusing because if you select Non-numeric registry, the help tip says it's looking for a REG_DWORD or REG_QWORD, I'm thinking that only applies if you're checking a numeric registry value.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...