AttackFlow Findings Dictionary

Finding A Way To Try AttackFlow Enterprise Edition?

If so, click to download 15 days full version for free!

Custom SSL Validation

The attacker can read the sensitive traffic in clear text between clients and the server, such as usernames, passwords, credit card numbers, etc.

Severity

Urgent

Fix Cost

High

Trust Level

Medium

SSL is the de-facto standard used to provide end-to-end secrecy between clients and the server over HTTP.

HTTPS using server administrators buy valid SSL certificates from valid certificate authorities. They provide these certificates to the user agents during connection and the user agents, browsers, apply various check mechanisms to make sure that the user is connecting to a valid domain. A few of these checks;

  • The domain name on the certificate should match the target domain name that the user wants to connect
  • The certificate shouldn’t be expired
  • The certificate shouldn’t be revoked
  • The certificate should be signed with a valid certificate authority (prebuilt into the browsers)

If any of these checks fail, the end user is presented an interface saying that the connection isn’t secure. This warning interface is the single most important warning medium for the end users against attackers executing man in the middle attacks using hacking techniques such as ARP poisoning.

Sometimes, we write code connecting to a test server during testing which has a self-signed SSL certificate. The self-signed SSL certificates can’t provide the security assurance that the above controls want to assure, however, SSL certificates are somewhat expensive and needs time to acquire. So during test process self-signed SSL certificates are installed into the test servers.

The code that connects to one of these test servers fail miserably because of the the last control listed above. For example;

                                     
WebRequest request = WebRequest.Create("https://www.selfsigned.com");
            
            

The exception thrown contains message which is similar to Remote certificate is invalid according to the validation procedure. If this error message is searched in the Internet for a solution, the following wrong suggestion might be given;

            
public bool vsc(object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors){
return true;
}

WebRequest request = WebRequest.Create("https://www.selfsigned.com");

ServicePointManager.ServerCertificateValidationCallback +=
new RemoteCertificateValidationCallback(vsc);
            
            

The code above will make the exception disappear, however, since no validation check will be done in method vsc, the attacker will have the opportunity to intercept the traffic using man-in-the-middle attacks but the code won’t produce any warning messages.

SSL is the de-facto standard used to provide end-to-end secrecy between clients and the server over HTTP.

HTTPS using server administrators buy valid SSL certificates from valid certificate authorities. They provide these certificates to the user agents during connection and the user agents, browsers, apply various check mechanisms to make sure that the user is connecting to a valid domain. A few of these checks;

  • The domain name on the certificate should match the target domain name that the user wants to connect
  • The certificate shouldn’t be expired
  • The certificate shouldn’t be revoked
  • The certificate should be signed with a valid certificate authority (prebuilt into the browsers)

If any of these checks fail, the end user is presented an interface saying that the connection isn’t secure. This warning interface is the single most important warning medium for the end users against attackers executing man in the middle attacks using hacking techniques such as ARP poisoning.

Sometimes, we write code connecting to a test server during testing which has a self-signed SSL certificate. The self-signed SSL certificates can’t provide the security assurance that the above controls want to assure, however, SSL certificates are somewhat expensive and needs time to acquire. So during test process self-signed SSL certificates are installed into the test servers.

The code that connects to one of these test servers fail miserably because of the the last control listed above. For example;


URL url = new URL("https://www.selfsigned.com/");
HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
    

The exception thrown contains message which is similar to Remote certificate is invalid according to the validation procedure. If this error message is searched in the Internet for a solution, the following wrong suggestion might be given;


TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {	 
public X509Certificate[] getAcceptedIssuers() {
return null;
}

public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
    
public void checkServerTrusted(X509Certificate[] certs, String authType) {    
}
}
};

SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

URL url = new URL("https://www.selfsigned.com/");
HttpsURLConnection con = (HttpsURLConnection)url.openConnection();

The code above will make the exception disappear, however, since no validation check will be done in method vsc, the attacker will have the opportunity to intercept the traffic using man-in-the-middle attacks but the code won’t produce any warning messages.

Finding A Way To Purchase AttackFlow Enterprise Edition?

If so, click to buy now for yearly subscriptions!