Since the certification authority Let’s Encrypt was founded in 2014 and went live at the end of 2015, more than 182 million active certificates and 77 million active domains have been registered to date (as of 05/2021). [1]
To make the certification processes more transparent, all certificate registrations are logged publicly. Below, we take a look at how this information can be used from an attacker’s perspective to enumerate subdomains and what measures organizations can take to protect them.
Let’s Encrypt
Since the introduction of Let’s Encrypt, the way of handling SSL certificates has been revolutionized. Anyone who owns a domain name these days is able to obtain a free SSL certificate through Let’s Encrypt. Using open source tools such as Certbot, the application and configuration of SSL certificates can take place intuitively, securely and, above all, automatically. Certificates are renewed automatically and associated web server services such as Apache or Nginx are restarted fully automatically afterwards. The age of expensive SSL certificates and complex, manual configuration settings is almost over.
Growth of Let’s Encrypt
Certificate Transparency (CT) Logs
Furthermore, Let’s Encrypt contributes to transparency. All issued Let’s Encrypt certificates are sent to “CT Logs” as well as also logged in a standalone logging system using Google Trillian in the AWS Cloud by Let’s Encrypt itself. [2]
The abbreviation CT stands for Certificate Transparency and is explained as follows:
“Certificate Transparency (CT) is a system for logging and monitoring the issuance of a TLS certificate. CT allows anyone to audit and monitor certificate issuances […].” [2]
Certificate Transparency was a response to the attacks on DigiNotar [3] and other Certificate Authorities in 2011. These attacks showed that the lack of transparency in the way CAs operated posed a significant risk. [4]
CT therefore makes it possible for anyone with access to the Internet to publicly view and verify issued certificates.
Problem definition
Requesting and setting up Let’s Encrypt SSL certificates thus proves to be extremely simple. This is also shown by the high number of certificates issued daily by Let’s Encrypt. More than 2 million certificates are issued per day and their issuance is transparently logged (as of 05/2021) [5].
Let’s Encrypt certificates issued per day
Certificates are issued for all kinds of systems or projects. Be it productive systems, test environments or temporary projects. Users or companies are able to get free certificates for their domains and subdomains. Wildcard certificates have also been available since 2018. Everything transparently logged and publicly viewable.
Transparency is great, isn’t it?
Due to the fact that all issued certificates are transparently logged, this information can be viewed by any person. This information includes, for example, the common name of a certificate, which reveals the domain name or subdomain of a service. An attacker or pentester is thus able to identify the hostname and potentially sensitive systems in Certificate Transparency Logs.
At first glance, this does not pose a problem, provided that the systems or services offered behind the domain names are intentionally publicly accessible, use up-to-date software versions and are protected from unauthorized access by requiring authentication, if possible.
However, our experience in penetration testing and security analysis shows that systems are often unintentionally exposed on the Internet. Either this is done by mistake or under the assumption that an attacker needs further information such as the hostname to gain access at all. Furthermore, many companies no longer have an overview of their existing and active IT assets due to grown structures. By disabling the indexing of website content (e.g. by Google crawlers), additional supposed protection is implemented especially for test environments. Accordingly, an attacker would have no knowledge about the system at all and some sort of security is achieved assumedly. Developers or IT admins are also usually unaware that SSL certificate requests are logged and that this allows domain names to be enumerated publicly.
Readout of CT logs
A variety of methods now exist to access public CT log information. These methods often take place in so-called Open Source Intelligence (OSINT) operations to identify interesting information and attack vectors of a company. We at Pentest Factory also use these methods and web services to identify interesting systems of our customers during our passive reconnaissance.
A well-known web service is: https://crt.sh/
Sample excerpt from public CT logs of the domain pentestfactory.de
Furthermore, a variety of automated scripts exist on the Internet (e.g., GitHub) to extract the information automatically as well.
The myth of wildcard certificates
After realizing the possibility of enumerating CT logs and therefore the incoming potential problem, companies often come up with a grandiose idea. Instead of requesting individual SSL certificates for different subdomains and services, one general wildcard certificate is generated and set up across all systems or services.
This means that the subdomains are no longer published in Transparency Logs, since the certificate’s common name is simply a wildcard entry such as *.domain.tld. External attackers are thus no longer able to enumerate the various subdomains and services of a company. Problem solved, right?
Partially. Correctly, the hostnames or subdomains are no longer published in Transparency Logs. However, there are still many opportunities for an attacker to passively gain information about interesting services or subdomains of a company. The underlying problem that systems may be unintentionally exposed to the Internet, use outdated software with publicly known vulnerabilities, or fail to implement access controls still exists. The approach of using a wildcard certificate to provide more security by simply hiding information is called Security through Obscurity. In reality, reusing a single wildcard certificate across multiple services and servers reduces an organization’s security.
For example, an attacker can perform a DNS brute force attack using a large list of frequently used domain names. Public DNS servers such as Google (8.8.8.8) or Cloudflare (1.1.1.1) provide feedback on whether a domain can be successfully resolved or not. This again gives an attacker the opportunity to identify services and subdomains of interest.
Example DNS brute force attack on the domain pentestfactory.de to enumerate subdomains
The dangers of wildcard certificates
Reuse of a wildcard certificate across multiple subdomains and different servers is strongly discouraged. The problem here lies in the reuse of the certificate.
Should an attacker succeed in compromising a web server that uses a wildcard certificate, the certificate must be considered fully compromised. This compromises the confidentiality and integrity of traffic to any service of an organization that uses the same wildcard certificate. An attacker, in possession of the wildcard certificate, would be able to decrypt, read or even modify traffic of all services reusing the certificate. However, an attacker must be in a Man-in-the-Middle (MitM) position between the client and the server to intercept the traffic. Accordingly, this attack is not trivial, but it is practically feasible by skilled attackers.
If unique SSL certificates were used for each domain/service instead of a single wildcard certificate, the attacker would not have been able to compromise all services at once. Other domains and corporate services would not have been affected at all, since an attacker would have to compromise those individual SSL certificates too. The company would therefore only have to revoke and reissue a single certificate and not the extensively reused wildcard certificate across multiple servers and services. Furthermore, the damage can be reduced by using unique certificates and its extent can be measured in case of a successful attack. Companies then know exactly which certificate for which domain or service has been compromised and where attacks may already have taken place. With the use of wildcard certificates and a successful attack, all domains and services are potentially compromised and the impact of the damage is opaque or difficult to assess.
More information about wildcard certificates:
Recommendation
Always be aware that attackers can gain a lot of information about your company. Be it public sources or active tests to obtain valuable information. The security and resilience of a company stands and falls with the weakest link in the IT infrastructure. In general, refrain from Security through Obscurity practices and always keep your systems up to date (patch management).
Rather, make sure that all your publicly accessible systems are intentionally exposed to the Internet and implement access control if necessary. Development environments or test instances should always remain hidden from the public and only be made available to the company itself and its developers. This can be achieved by whitelisting your company-wide IP addresses on the firewall or by implementing a simple authentication wall (e.g. using basic authentication for web services). Use a complex password with a sufficiently large length (> 12 characters).
SSL-Zertifikate sollten den exakten (Sub)Domänennamen im Common Name des Zertifikats definieren sowie von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt worden sein. Continue to ensure that all certificates are valid and renewed early before expiration. Furthermore, it is recommended to use only strong algorithms for singing SSL certificates, such as SHA-256. The use of the outdated SHA-1 hashing algorithm should be avoided, as it is vulnerable to practical collision attacks [6].
Professional support
Are you unsure what information about your organization is circulating on the Internet and which systems are publicly accessible? Order a passive reconnaissance via our pentest configurator and we will be happy to gather this information for you.
You are interested in the resilience of your public IT infrastructure against external attackers? Want to identify the weakest link in your IT assets and have your SSL configuration technically verified? Then order a penetration test of your public IT infrastructure via our pentest configurator.
Sources
[1] https://letsencrypt.org/de/stats/#
[2] https://letsencrypt.org/de/docs/ct-logs/
[3] https://www.eff.org/de/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
[4] https://certificate.transparency.dev/community/
[5] https://letsencrypt.org/de/stats/#
[6] https://portswigger.net/daily-swig/researchers-demonstrate-practical-break-of-sha-1-hash-function