When testing applications at Cyberfort, we review the TLS certificates used to identify the web services being tested. We have noticed some very subtle security issues can occur with server certificates over and above the usual fare of:
- Weak ciphers
- Insecure signing hashing
- Weak Diffie Hellman keys
In hindsight, there are obvious reasons why these subtle issues have occurred. But, unlike the usual certificate issues reported on many a test, the risks posed by these subtle issues can be of a greater magnitude.
Web Server Attacks: Let’s Set the Scene
Often we test web applications in non-production environments. This means that the web server certificate for the non-production environment is likely to be a wildcard certificate based on the domain name for the production web server.
A wildcard certificate is a public key certificate which can be used with multiple sub-domains of a domain. The principal use is securing websites with the HTTPS protocol. Wildcard certificates are cheaper and, at first glance, easier to maintain – you only need one certificate for all the servers: a single certificate for all main domains and subdomains.
The wildcard certificate installed on the server is the private key and needs to be protected from compromise (being leaked).
Points to be aware of in terms of their scope:
- The wildcard does not match full stops in a domain name, so sub-domains of a sub-domain are not covered by the wildcard server certificate for the main domain.
- The main domain needs to be added to the subject alternative name field on the wildcard certificate.
So, Are Wildcard Certificates Less Secure?
By their very usefulness, wildcard certificates for multiple sub-domains will be deployed everywhere a sub-domain is serving web content that needs HTTPS. Again, this is a known problem and is normally captured during any assessments.
But what may not be fully obvious is that the client is likely also using that wildcard certificate to host content on other third-partymanaged servers.
An Example of a Potential Web Server Attack Caused by Wildcard Certificates
One bank we have tested uses a marketing agency to manage their static content. The bank gave the marketing agency a wildcard certificate to allow the agency to host static content and create their own production, staging, QA etc. environments for the bank’s static web content. What’s more, this agency used the same physical server to host their other client’s applications.
This dramatically increased the attack surface for the bank. The bank’s security now depended on the security of the marketing agency’s other client’s applications. If any one of those applications was compromised, it would allow an attacker access to the private key of the wildcard certificate for the bank’s production systems.
At this point, the attacker would be able to create malicious spoof bank websites, hack the unsuspecting bank’s clientele, and reap the benefits.
The bank should never have issued production web server certificates to a third party, especially not wildcard certificates! The good news: certificates that have been issued in this manner can be revoked. This, at least, can be managed.
Hunting Down the Increased Attack Surface
If, during a penetration test, you come across a wildcard certificate, we recommend taking the following actions:
- Locate and note down all the domains and alternate names the certificate is valid for.
- Locate all the live IP addresses associated with these domains.
- Use dictionary and brute force attacks, as well as open-source intelligence gathering, to locate other live sub-domains.
- For the discovered sub-domains, find all the associated IP addresses.
- Remember a domain or a sub-domain may have multiple IP Addresses – find them all – e.g. you can use nmap scripts to locate all the IP addresses for a given domain name.
- Ask for permission to investigate the increased attack surface. They may be hosted on third-party systems whose owners may not take kindly to being penetration tested.
- If permission is granted, increase the scope of the test and see what else is being served at those IP addresses (think reverse lookups).
- If not granted, report it and let the client determine their own risk acceptance for the issue. They can send in their compliance team to ask the third party what else they are hosting and if they can guarantee the bank’s certificate safety.
A client may be quite happy that the keys to their kingdom are being managed by a third party.
I suspect they won’t be, but at least you have done your due diligence and the client can make the hard decisions.
If you’re concerned about the security of your web server certificates contact us today to find out how we can support your organisation.