The Dark Side of Certificates: Exposing Your Network to Hackers
Information from Subject Alternative Name (SAN) field in TLS/SSL certificates may pose a significant threat to your organization if not used properly.
Motivation
It is a paradox that the primary purpose of TLS/SSL certificates is to enhance security, yet their misuse may lead to exposing unwanted information and expanding the attack surface for malicious actors.
In this article, we will explore a simple yet powerful method called Simple Hostname Discovery (SHD) that can be used to gather critical information for enabling bad actors to learn more about new attack vectors towards previously unknown DNS hostnames.
Additionally, we will analyze the vendors involved in securing the internet landscape, learning about trends and leaders in enterprise endpoint security based on Fortune 500 company websites.
Finally, we will offer multiple ways to approach threat prevention related to the risks recognized during our research (and a bit more).
Research
To make this research more interesting and substantial, we decided to use the Fortune 500 list of websites published a few years back to see how they stack up against the SHD method.
Simple Hostname Discovery (SHD) Method
Simple Hostname Discovery is the term we use for discovering new hostnames from TLS/SSL certificate information, specifically from the SAN field.
A list of Fortune 500 websites was put through a simple nmap command:
nmap -p 443 --script ssl-cert <website>The output gathered from 500 websites is quite exciting and we start to see some potential. We are specifically looking at the Subject Alternative Name (SAN) certificate field, which yields interesting discoveries.
Scan Results
Here (large file) are all the DNS hostnames discovered during our scan on March 11, 2023 (raw scan results). By exposing this list publicly and making it discoverable through search engines, we hope to motivate some organizations to rethink their approach to creating certificates. Our intention is not to endanger anyone; this kind of information is widely available for everyone to see.
An excellent example is McDonald’s. As you can see in the scan results, the number of hostnames discovered is extensive! We encourage you to take a closer look and see if you can find any suspicious hostnames (e.g. used for development, staging).
Some certificates can have up to 410 entries in the SAN field! It doesn’t necessarily correlate with a higher threat level, but it’s undoubtedly mind-boggling.
Only 12% of certificates contain a single hostname (which is recommended) in the Subject Alternative Name (SAN) field. Meanwhile, 26% of certificates have two hostnames and 8% have three hostnames in the SAN field. Please refer to the Threat Prevention chapter for our recommendations.
What can the SAN certificate field tell us?
The SAN certificate field can expose more information than we might expect. It can contain DNS hostnames that were not visible in plain sight (e.g. in search engine results) and the information it contains can significantly expand the attack surface.
What types of attacks are possible against discovered DNS hostnames?
As always with hackers, imagination is the limit. A few that come to mind are DDoS attacks targeting a broader infrastructure footprint, running automated tools to discover services behind those DNS hostnames and attempting to exploit their vulnerabilities.
Additional Opportunities in Discovering DNS Hostnames
Certificate Transparency (CT) logs serve as public records of SSL/TLS certificates issued by Certificate Authorities (CAs). However, this also means that they can be a powerful tool for hostname discovery. It is essential to be aware that your CA most likely publishes certificate information to one of the public logs. These public CT logs are searchable, with a good example being https://crt.sh/ (although it has some stability issues). For instance, searching for McDonald’s mcd.com domain yields some concerning results.
https://dnsdumpster.com/ can provide valuable insight into additional DNS hostnames related to a given domain. It claims to use “open source intelligence resources”, which essentially means it’s a data aggregation tool that presents facts from multiple sources without actively auditing the hostnames in question. There’s no CLI or ability to interface with their API to automate discovery processes.
All DNS discovery tools are complementary. We found one example where DNSdumpster did not discover what the SAN certificate field could for the ameren.com hostname: www.dev.ameren.com
There are more tools, sometimes referred to as “hacker reconnaissance” tools, but discussing DNS hostname discovery tools beyond the SHD method presented here is beyond the scope of this article.
Analysis
While attempting to access newly discovered DNS hostnames, we can’t help but notice the various mechanisms in place that prevent malicious actors from causing harm — which is excellent! Common endpoint access control methods include the use of a Web Application Firewall (WAF) and various types of authentication methods.
Employees often require VPN (or similar secure connection to internal network) to connect to organization network(s) and then they are able to access private resources, even if those are publicly exposed in some cases. One other way is to be on premise within one of the offices that has a local network configured to be able to access private resources.
We can only hope that the majority of development, staging and similar endpoints discovered have Access Control List (ACL) rules allowing access only from organization network(s) or have implemented some kind of authentication — ideally, both.
During our research, we decided to conduct a few quick analyses to provide you with insight into the current state of leading vendors in the business of protecting organizations from malicious actors.
CA (Certificate Authority) Distribution
The graph represents Certificate Authorities (CAs) used for Fortune 500 websites, excluding CAs for additional hostnames discovered from the Subject Alternative Name (SAN) certificate field. CA names are taken directly from the certificate’s issuer field.
DigiCert is a clear winner in this sample. They appear to be a highly trusted CA and provide responsive, personalized support.
It’s nice to see organizations trusting free Let’s Encrypt CA. Cloudflare is present due to their low barrier to entry and the offering of TLS/SSL certificates in the form of a simple toggle. Sectigo is also popular due to its competitive price point and reliable support.
IP Range Owners
Compared to the CA distribution data that represents only websites from the Fortune 500 list, this graph shows the ratio of IP range ownership for all discovered DNS hostnames.
Akamai is the clear winner here.
IP range ownership provides a nice glimpse into services that Fortune 500 companies might be using to protect their resources. Those IPs often represent globally distributed edge proxy networks that apply rules configured by companies to safeguard their resources. Edge proxy networks are frequently leveraged as Content Delivery Networks (CDNs) that serve static content faster from the closest location to the end user. CDNs also reduce the load on an organization’s compute and cache storage resources.
It’s worth noting, many organizations use cloud providers like Amazon AWS, Google GCP and Microsoft Azure — but they may not necessarily be registered in the discovered IP ranges. This is because proxies from providers like Akamai, Imperva (Incapsula) and Cloudflare is first in line to establish connections towards origin servers (hosted in AWS, GCP or with other providers). This should not skew your perception into thinking that, for example, Akamai is hosting all the websites discovered in its IP range.
We used IPinfo’s services to build such a nice categorization of IP range ownership. 50k free queries per month was more than enough to fetch organization field (with ASN and organization name) from the returned JSON. The API is very simple and we used ~11k requests. Interestingly, they process about 1.5 billion requests per day or around 50 billion requests per month. They were also kind enough to suggest we could try their free “IP to ASN Database”.
Threat Prevention
As cyber threats continue to evolve, it is imperative for organizations to remain vigilant and proactive in their efforts to prevent potential threats. One area that organizations should focus on is preventing the misuse of the Subject Alternative Name (SAN) field in TLS/SSL certificates.
Subject Alternative Name (SAN)
We recommend serving each hostname with a dedicated certificate that has a SAN field containing only one item, where this item represents the same hostname that the certificate is served from. Alternatively, use a wildcard hostname in the SAN field. There should be no more than one hostname stated in the SAN certificate field.
Reducing the number of hostnames in the SAN certificate field to a bare minimum reduces the potential attack surface. Using a hostname with a wildcard character is better than explicitly stating all hostnames that one certificate would otherwise cover.
Taking Certificate Transparency (CT) logs into account, it is recommended to use wildcard certificates in order to hide your hostnames from the public eye. By doing so, subdomains will be concealed.
A hostname serving a certificate containing a wildcard character in the SAN field poses a certain risk: multiple hostnames can be affected if only one of the certificates is compromised. Proper risk mitigation comes in the form of frequent certificate rotation.
Certificate Rotation
Rotate your certificates at least 30 days before their expiration date. This helps achieve a few things: there is enough time to fix certificates if the rotation fails for any reason and you will generally skip at least a few expiration notifications sent by CA providers.
The duration of a certificate is recommended to range between 90 days to a year, depending on the application. The shorter the duration, the better.
There’s a very high emphasis on automation. With proper automation in place, like using cert-manager, no matter the rotation frequency, maintenance cost in the form of engineering time spent rotating certificates is completely removed. When evaluating your CA, check if they support the ACME protocol.
10% of the certificates were to expire within a month after scanning. The worst case was a certificate about to expire within five days after scanning. Interestingly, the new certificate shows it was issued more than a month before the expiration date, but was rotated just days before.
SSL Certificate Pinning
Mobile developers are often the most knowledgeable developers in the area of preventing Man in the Middle (MITM) attacks. SSL certificate pinning is a crucial security measure for mobile applications to protect user data and privacy.
This method prevents tools like mitmproxy, which can auto-generate certificates on the fly from locally trusted (arbitrary) CAs, to be used for decrypting traffic in communication between a client and origin server. Instagram is a good example — there is no way to easily decrypt TLS/SSL encrypted traffic between the application and its servers. Many other mobile applications do not use this technique, which means all traffic can be decrypted.
URL Request Rate Limiting
The reasons for implementing URL request rate limiting are straightforward: prevent DDoS attacks and unwanted strain on your system (mainly compute resources and traffic cost).
This is often achieved in a few ways. Either by leveraging the configuration of proxy services that are in front of your infrastructure (like Cloudflare or Akamai network proxies) or by configuring ingress controllers used in Kubernetes (many support rate limiting along with other features).
We recommend custom request limiting value per URL and a default rate limiting value for all URLs. In both cases, it makes sense only after there is historical or benchmark data to base the decision on. Too low rate limiting value might prevent legitimate users from accessing relevant content.
Cyber Security Suites
There are numerous cyber security tools available. We will not discuss them specifically, but rather which factors to take into account when evaluating.
When selecting a cyber security solution, start by evaluating it against this criteria: types of products offered by the vendor, the vendor’s reputation, whether it can be managed with an Infrastructure as Code (IaC) tool like Terraform to version very explicit configuration definitions which can then be additionally split by ownership, price, complexity of the solution vs. benefits, ease of maintenance, implementation and use, the size of community, paid support, maturity of the product(s), the presence of verbose audit logs along with their persistence for a significant amount of time, whether company’s internal security and policies are taken seriously.
Protecting User Devices
Protecting employee devices is critical.
This is not strictly related to certificate management, but employees are in a position to access private resources that would otherwise be blocked if accessed from the internet. This makes an organization’s network(s) as vulnerable as the least protected user device. If we assume that companies invest significantly more resources in endpoint security than in securing user devices, it becomes clear that significant risk exists in this area.
A Zero trust security model is a good way to improve security. This approach requires additional checks when trying to access different resources within the organization. Two-factor authentication (2FA), common authentication (OAuth, JWT) and audit logs can also be used to enhance security and visibility.
Threat Modeling
Unrelated to certificates, but for discovering more potential threats, you might be interested in playing a game with fun cards. Draw any of the cards from time to time in front of the team and see if they can recognize the opportunity to make the system (infrastructure, applications) more secure.
Conclusion
Discover what others can learn from the information you expose to the world through the data present in certificates. We hope our insights and prevention suggestions inspire positive change, making your organization more secure and resilient to malicious threats.
Visit www.relaymonkey.com to learn more.
Updates:
April 15th, 2023: Added percentages for a count of 1, 2 and 3 domains present in Subject Alternative Name (SAN) field.
April 16th, 2023: Added Certificate Transparency (CT) logs.