0 Replies Latest reply on Feb 22, 2012 5:31 PM by ashyoungblood

    VulnResearch - Untrusted TLS/SSL server X.509 certificate (tls-untrusted-ca)

      Please note that I am not affiliated with Rapid7, LLC and the information detailed below are my personal findings and opinions.  They do not reflect or imply the views or liability of Rapid7, LLC, or any current employer.  Furthermore, I will not and cannot be held liable for use of this information beyond educational purposes.  All information contained within is after LONG hours of personal research, and in some cases, extensive collaboration with Rapid7 technical staff.


      Please leave comments with any requests for information regarding this particular vulnerability and/or researching its validity.


      Vulnerability - Untrusted TLS/SSL server X.509 certificate (tls-untrusted-ca)


      This vulnerability has a relatively high false positive rate.  However, since it is also capable of being perfectly legitimate, it's important to distinguish between FP instances and truly vulnerable instances.  Note that this vulnerability is confirmed when CN data for the associated certificate is self-signed or trusting an internal certificate issuer.


      Reason(s) for potential False Positive:


      1. The NeXpose certificate keystore is outdated - NeXpose's cert keystore is derived from the Java Runtime Environment (JRE) used within the console installation.  The last documented update to this component was on 6-20-2011 and it applied JRE 1.6.0_25.  As of 2-22-2012, the latest builds are JRE 1.6.0_31 and JRE 1.7.0_3.
        1. While currently unsupported, it is possible to update NeXpose's keystore following the information provided by Chad Loder, here: https://community.rapid7.com/thread/1540
        2. It is also my understanding that this feature may be added in a future NeXpose release so that it is supported.
      2. The certificate path is incomplete - Web browsers seem to make a logic jump from endpoint certificate to root authority.  However, a non-browser based validation will usually validate via the certificate path (e.g. SSH).  NeXpose's test is based on the certificate path.  If the endpoint, intermediate, and root certificates are not installed (per best practice) the chain is invalid and NeXpose will REFUSE (as it should) to recognize the root CA regardless of whether the CN data matches or not.
        1. The caveat here is that while this condition will produce a false positive, the finding is still technically accurate.  Your admins SHOULD be installing the full certificate path on all devices.  In most cases where it's not done it is because of: 1) Poor/lazy habits - we all have them, 2) The device does not allow for specifying how or how many certificates are installed, 3) Improper installation of the certificate(s).  To learn how to properly install the certificate path, I recommend: http://help.godaddy.com/article/5346?locale=en


      Verifying the false positive:


      1. The NeXpose certificate keystore is outdated
        1. The easiest method (and most common) is to fire up Chrome and Firefox and visit the specific IP/Port mentioned in the scan data for being vulnerable.  Once loaded (and providing no security exception prompts have occurred) click the security icon within the browser   As an example, you would click the "site icon" on the left within Firefox 10 > "More Information" > "View Certificate" > Select the "Details" tab > Review "Certificate Hierarchy".
        2. In instances where this is not possible, you can compare the PROOF column data (the first line contains the CN name from the scan information (Click the IP, then the vulnerability) against: Linux - Output from the java keystore tool against an up to date JRE instance; Windows - Control Panel > Java > Security > Certificates > System > Secure Site CA.
      2. The certificate path is incomplete
        1. Linux - ensure OpenSSL is installed. Issue the following command openssl s_client  -connect IPADDRESS:PORT
          1. Verify that the return contains a depth level of 0-3 to assure the certificate path is not the issue (obviously the actual root cert authority is a non-issue so long as you know they're a trusted CA)
        2. Windows - The only valid method I'm aware of involves the same steps as for linux.  You can obtain OpenSSL binaries for Windows here: http://www.openssl.org/related/binaries.html


      Well, that's it for now.  Hope you everyone finds this helpful, and if so, I may do a few more.


      Planned Updates (time permitting) - Duplicating the existing tls-untrusted-ca check, descriptor, and solution data to provide intelligent solution data that covers all possible reasons for this finding.


      Message was edited by: Ashley Youngblood - 2/22/12 - 17:31 EST