Cordex XDR blocking SQL server connection

[sagar1]

Hi,

We are facing error while connecting to SQL server database from our application. We noticed that, once we start the application might be Cordex XDR adding the -agentpath (-agentpath:C:\Program Files\Palo Alto Networks\Traps\cyjagent.dll) in JVM arguments. Can any one please confirm on this? And things are working fine if we disable the Java Deserialization EPM module from the Cordex XDR.

Below is the piece of stack trace:

Caused by: java.lang.VerifyError: Bad type on operand stack
Exception Details:
Location:
com/sun/jndi/dns/Resolver.<init>([Ljava/lang/String;II)V @10: invokestatic
Reason:
Type uninitializedThis (current frame, stack[0]) is not assignable to 'java/lang/Object'
Current Frame:
bci: @10
flags: { flagThisUninit }
locals: { uninitializedThis, '[Ljava/lang/String;', integer, integer }
stack: { uninitializedThis, '[Ljava/lang/String;', 'java/lang/Integer', 'java/lang/Integer' }
Bytecode:

... at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:573) ~[jdk.naming.dns:?]
at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:434) ~[jdk.naming.dns:?]
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) ~[?:?]
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) ~[?:?]
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) ~[?:?]
at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) ~[?:?]
at com.microsoft.sqlserver.jdbc.dns.DNSUtilities.findSrvRecords(DNSUtilities.java:44) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.dns.DNSKerberosLocator.isRealmValid(DNSKerberosLocator.java:38) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.SSPIAuthentication$1.isRealmValid(SSPIAuthentication.java:82) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.SSPIAuthentication.findRealmFromHostname(SSPIAuthentication.java:107) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.SSPIAuthentication.enrichSpnWithRealm(SSPIAuthentication.java:142) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.SSPIAuthentication.getSpn(SSPIAuthentication.java:191) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.NTLMAuthentication$NTLMContext.<init>(NTLMAuthentication.java:300) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.NTLMAuthentication.<init>(NTLMAuthentication.java:339) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection.logon(SQLServerConnection.java:3961) ~[mssql-jdbc-8.4.1.jre11.jar:?]
at com.microsoft.sqlserver.jdbc.SQLServerConnection$LogonCommand.doExecute(SQLServerConnection.java:3932) ~[mssql-jdbc-8.4.1.jre11.jar:?]

So wanted to know as this exception is coming from standard libraries, will it get help after updating the OpenJDK / mssql-jdbc driver? 

Any pointers on this will be really appreciated. Thanks in advance.

Regards,

Sagar

[neelrohit]

Hi @sagar1 ,

Thank you for writing to live community!

We are sad to hear that you are facing issues with the SQL server connection.

In order to isolate the issue whether Cortex XDR is causing problems with the same, we would request you to kindly perform some steps as an isolation mechanism:

Since you already mentioned that post disabling Java Deserialisation module, you are not facing issues, we request you to kindly perform the steps below: 

1. Open a CLI commandas admin /live terminal to the endpoint, navigate to the traps folder where cytool exists and run the following command:
   cytool log set_level 7 all
2. Enable the Java Deserialisation Protection from the exploits profile and perform cytool runtime stop and cytool runtime start on the endpoint. Try reproducing the issue.
3. Disable Java Deserialisation Protection and try reproducing the issue again.
4. Enable Java Deserialisation Protection back again and go to Exceptions profile, under the process exceptions attached to the policy for that server, add java process as exception with Java Deserialisation protection as shown below and try reproducing the issue. 
    
5. If the issue is resolved with this, kindly keep the exception for now. If it does not go back to exploits and kindly disable Java Deserialisation protection on that server. Back on the CLI as admin/Live Terminal, run the command:
   cytool log set_level 6 all
6. Retrieve the tech support file from the endpoint 
7. Kindly retrieve the tech support file from the agent please log a TAC case with the log file to be sent to our engineering teams for investigation and fix. 

Alternatively, you can simply log the TAC case for the same and the respective teams will help you do the troubleshooting steps accordingly.

Hope that answers your question!

Regards.

[sagar1]

Thank you so much @neelrohit for the quick reply.

[sagar1]

Hi @neelrohit,

Could you please confirm on this as well. We noticed that, once we start the application might be Cordex XDR adding the -agentpath (-agentpath:C:\Program Files\Palo Alto Networks\Traps\cyjagent.dll) in JVM arguments. Is that our correct assumption? Thanks.

Regards,

Sagar

[neelrohit]

Hi @sagar1 ,

Cortex XDR inorder to perform protection on the endpoints we inject dlls into the processes for protection against memory corruption exploits. the path is added as a premeptive monitoring of execution events to see if it is legit to malicious by nature. 

Please look here for file analysis and protection flow for exploits for Cortex XDR

Hope that clarifies it

[sagar1]

Hello @neelrohit,

One more question, actually we wanted to file a customer support case & for that we need to provide the log information related to the process Cordex XDR (Java Deserialization EMP) is blocking. So wanted to know, In which log file of Cordex XDR I can find these information?  Thanks.

Regards,

Sagar

[neelrohit]

Hi @sagar1 , 

Whenever you have alerts generated from XDR agent alerts, you can right click on the alert> Retrieve Additional Data> Retrieve alert Data.

For alerts from exploits module the option changes to alert> Retrieve Additional Data> Retrieve alert Data and Analyze. Click yes and go to action center. You will observe an entry by the name Retrieve alert Data. Once the data retrieval is completed, download the zip file and attach it to the case for investigation by our engineering team. 

Retreive Alert Data

 

 Additionally, if you have no alerts and the TAC team is asking for Cortex XDR logs, the simply retrieve the Tech Support files from the endpoint and share the same with them and mention that you do not have any alerts on the same.

[sagar1]

Hello @neelrohit ,

One more last question, as this issue is getting occurred on one of our customer side so to reproduce this on our local machine, can we download & install the trial version of Cordex XDR? If yes, could you please provide the link from where I can download the trial version. Thanks.

[neelrohit]

Hi @sagar1 ,

Unfortunately, that is not possible as we do not sign up trials without account team's involvement and we do not have any trial licenses we offer publicly without sales quotes. Also, this issue that you reported will not necessarily  reproduce on your environment as there may be variation in activities. We have also not heard as of now regarding this issue and the recommendation would be to reproduce the issue on the server or its parallel servers and get the logs from them.

You do not need access to the machines to get the logs and run the commands and all the steps mentioned can also be done via live terminal(except starting and stopping agent services using cytool) and cortex XDR console as mentioned above.

Hope that answers your question.

Regards.