My team is conducting academic research on Java Cryptography API based misuse using your tool.
During our analysis, we found that we could not detect some potential cryptographic vulnerabilities. We believe this may be due to underlying implementation or design gaps.
Here are the details of our analysis and the cryptographic misuses:
Using QARK version 4.0.0
Using Python version 3.5.2
Using OpenJDK version 1.8.0_232 64 bit
Running on Ubuntu: 18.04 Kernel: 4.4.0-174-generic
Each cryptographic vulnerability was generated as a barebones Java project that only contained a single vulnerability in the main function and used up to two java source files. Additionally, all cryptographic API calls were from Java Cryptographic Architecture (JCA).
We are reporting this since in your readme you mention that “Improper x.509 certificate validation” is attempted to be found.
Attempting to use a vulnerable SSL verification with an empty checkClientTrusted and/or getAcceptedIssuers is created in anonymous inner class objects created from theX509ExtendedTrustManagerclass from JCA:
public class BareBone_X509ExtendedTrustManagerCanBypass {
public static void main(String[] args) {
new X509ExtendedTrustManager(){
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public X509Certificate[] getAcceptedIssuers() {
// TODO Auto-generated method stub
return null;
}
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType, Socket socket)
throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType, Socket socket)
throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType, SSLEngine engine)
throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType, SSLEngine engine)
throws CertificateException {
// TODO Auto-generated method stub
}
};
System.out.println("Hello World");
}
}
Attempting to use a vulnerable SSL verification with an empty checkClientTrusted, checkServerTrusted, and/or getAcceptedIssuers that is created in anonymous inner class object created from an empty abstract class which implements the X509TrustManager interface from JCA:
public abstract class BareBone_X509TrustManagerCanBypassExt implements X509TrustManager {
}
...
public class BareBone_X509TrustManagerCanBypass {
static X509TrustManager getTrustManager(){
return new BareBone_X509TrustManagerCanBypassExt(){
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
// TODO Auto-generated method stub
}
@Override
public X509Certificate[] getAcceptedIssuers() {
// TODO Auto-generated method stub
return null;
}
};
}
public static void main(String[] args) {
getTrustManager();
System.out.println("Hello World");
}
}
Please let me know if you need any additional information (e.g., logs from our side) in fixing these issues.
Hi,
My team is conducting academic research on Java Cryptography API based misuse using your tool.
During our analysis, we found that we could not detect some potential cryptographic vulnerabilities. We believe this may be due to underlying implementation or design gaps. Here are the details of our analysis and the cryptographic misuses:
Using QARK version 4.0.0 Using Python version 3.5.2 Using OpenJDK version 1.8.0_232 64 bit Running on Ubuntu: 18.04 Kernel: 4.4.0-174-generic
Each cryptographic vulnerability was generated as a barebones Java project that only contained a single vulnerability in the main function and used up to two java source files. Additionally, all cryptographic API calls were from Java Cryptographic Architecture (JCA).
We are reporting this since in your readme you mention that “Improper x.509 certificate validation” is attempted to be found.
Attempting to use a vulnerable SSL verification with an empty checkClientTrusted and/or getAcceptedIssuers is created in anonymous inner class objects created from theX509ExtendedTrustManagerclass from JCA:
Attempting to use a vulnerable SSL verification with an empty checkClientTrusted, checkServerTrusted, and/or getAcceptedIssuers that is created in anonymous inner class object created from an empty abstract class which implements the X509TrustManager interface from JCA:
Please let me know if you need any additional information (e.g., logs from our side) in fixing these issues.