Continuous SSL Certificate Monitoring - not just for HTTPS

Does your organization use “secure communication” channels, such as HTTPS? Has your IT staff placed trusted certificates on all of your critical and important web services? What about your SMTP, FTP, IMAP, LDAP, POP3, ACAP, NNTP and XMPP servers? Have any of your certificates expired? Have hackers compromised your servers and replaced them with fake certificates? Secure communications with SSL is a lot more complicated than simply going to sites that have an “https” in front of them. This blog entry discusses how active scanning with the Nessus vulnerability scanner and network monitoring with the Passive Vulnerability Scanner (PVS) can be leveraged for continuous monitoring of your SSL certificate infrastructure.

Performing Active Vulnerability Scans with Nessus

Tenable’s Nessus vulnerability scanner identifies many different aspects of SSL security information including:

• SSL/TLS detection (multiple checks)
• Supported algorithms and key strengths (#10863, #21643)
• The presence of insecure ciphers or hashes (#26928 and #35291)
• Signature signing algorithms (#10863 and #31705)
• SSL certificate validity and expiration (#15901, #42980 and #42981)
• SSL certificate common name (#45410 and #45411)
• Low entropy Debian keys (#32321)

Nessus also includes a variety of credentialed configuration audits and patch tests that can identify outdated libraries, misconfigured web servers, vulnerable web servers and more.

To configure a scan with Nessus or the Tenable SecurityCenter to look for SSL services you should:

• Modify the default scanned port range to target all of the ports you wish to discover SSL services on.
• Set the “Service Detection” plugin preference for “Test SSL Based Services” to “All”.

Many of Tenable’s customers perform SSL certificate testing as part of their web application assessments. Nessus automatically recognizes SSL on many ports, and makes uses of extensions such as STARTTLS in many other protocols to enable SSL support and test for the certificates.

Following is an example report of a Nessus scan performed under SecurityCenter that identified an SSL certificate hostname mismatch:

Real-time network Monitoring with the PVS

The PVS includes many generic checks to find web services and encrypted services as well as two specific checks to search for expired SSL certificates and to gather general information about certificates. No additional configuration is required for the PVS to detect this information in real time.

Following is an example screen capture of a PVS record detecting an expired SSL certificate:

Analysis of SSL Certificate Data

Once you have collected SSL certificate data, what should you do with it? There are some obvious checks that can be accomplished and some subtle ones that can be of great value.

Do all secure channels have SSL?

Before focusing on whether an SSL certificate is proper and secure or not, you should consider all of the web services discovered by the PVS and Nessus scans and attempt to determine if they need to be encrypted.

Don’t just look at systems with port 80 open. Nessus and the PVS have protocol independent methods to find web servers on any port. This allows quick discovery of administration, management, vendor and other interfaces you may not be aware of.

The PVS also records every active web site on each web server that it has observed. Manual reviews of this data may identify developer, administrator, data management and other interfaces that need to be encrypted.

Nessus and the PVS also identify any type of HTTP authentication that occurs. This facilitates listing the systems that require logins and then auditing them to see if these logins need to be performed over SSL.

Are any SSL certificates expired?

An expired SSL certificate will not be accepted by many web browsers and may not be trusted by your users. Your users may also take it upon themselves to accept the risks of the expired SSL certificate, placing your organization’s data at risk. Since an SSL certificate is typically something that is paid for, or manually created, an expired one could indicate several potential issues:

• The system with the certificate was deactivated, is no longer maintained or perhaps a newer web interface is being used. These types of systems may have many web vulnerabilities that aren’t being fixed and a hacker won’t be concerned with an old certificate as they are executing malicious code on your servers.
• A demo or evaluation product is on your production network. Many firewalls, web application firewalls, web proxies, web appliances, etc require some form of certificate and when these expire, they may show up in your list of SSL certificates. There have been several instances of web interfaces for appliances being shipped with the same identical certificate that do not create a custom one during the installation process. If your organization has replaced these with a custom certificate, it may expire at some point as well.
• Is there a misconfiguration on your server? Sometimes a system is  maintained well, but due to the complexities of running an Apache, IIS, WebSphere or other type of framework, the certificate is not actually being used correctly. This can be common if there are multiple web sites being hosted on one framework.
• Has a hacker replaced your certificate with an expired one? This attack is not common, but must be considered. Most hackers who have access to a web application that passes sensitive data will be able to attack the file system or back-end traffic to obtain sensitive data. However, if an attacker were to set up a malicious secure web server on your network, they may use an older SSL certificate.

Are any SSL Certificates Unsigned?

An unsigned certificate means that the certificate was not digitally signed by a trusted third party. All major web browsers include certificate authorities from the major services used to sign certificates. This ensures that the web site you are visiting is very likely the one you intended to visit.

However, it is very common for organizations to create unsigned certificates for internal services, internal applications and to place onto vendor applications that support loading of certificates. Since these certificates are not signed, users of secure sites typically have to “accept” this certificate as untrusted. A hacker could have replaced this certificate or used a client web attack to redirect users to a spoofed web site and the certificate does not provide any protection from this. It is important to note that the certificate does provide a basis for encryption of the traffic.

Consider the following factors when analyzing the list of web servers with unsigned SSL certificates:

• Are these internal systems used only by internal employees or trusted third parties?
• Is this web service available to the public?
• Does this web server have any security issues that would allow it to be the target or source of a malicious redirect?

How often and how thorough does “continuous” SSL certificate monitoring need to be?

I’ve spoken with many Tenable customers who want to perform SSL monitoring as part of their general security program, PCI auditing or real-time continuous security efforts.

Even if you have never taken the time to analyze the results of a Nessus scan that contains SSL certificate audit information, you may already have some data from  previous scans you can start with. Nessus SSL audit results typically have severity levels of LOW or MEDIUM with CVSS scores in the one through four ranges. As such, they tend to be overlooked in the face of missing patches or the latest zero-day of the month.

If you are performing PCI scans with Nessus, many of the SSL items tested will result in a failed PCI scan. Many of Tenable’s customers use the PCI standard as a basis for auditing all systems and internal servers. How often these audits are performed is a manner of policy and effort. We have some customers who perform manual PCI scans with Nessus monthly, as well as others who perform daily scans with SecurityCenter and multiple scanners.

If your organization is large or does not have a robust scanning infrastructure, it may benefit greatly from passive monitoring with the PVS. Tenable has helped many large government, commercial and educational institutions deploy a handful of PVS nodes to monitor traffic for 20-100k nodes.

Having both active and passive SSL data in a central location such as the SecurityCenter allows for a variety of analytics, reporting and alerting. These include:

• Alerting and trending when new SSL certificate information is available
• Comparing the number of SSL certificates passively discovered with those actively discovered
• Combining SSL certificate data with corporate asset data so organizational issues regarding SSL certificate management can be identified
• Identification of SSL certificates that don’t contain expected ad hoc organization unit and other types of data associated
• Associating SSL certificate information with web application security audit results

For more Information

Tenable offers many video demonstrations of Nessus, the SecurityCenter and the Passive Vulnerability Scanner. If this type of monitoring is of interest to you, we have also blogged and placed content on our web site about a variety of web application and database activity monitoring issues:

• Web Application Security Scanning
• Database Activity Monitoring
• Passive web site enumeration and detection
• PCI scanning with Nessus
• SQL database audits with Nessus 

A “Continuous Web Security Monitoring” webinar recording is also available. The video details how sniffing, log analysis, scanning and file integrity monitoring can be used to monitor web sites in real time.