Last updated at Wed, 07 Apr 2021 18:26:22 GMT
While it's no surprise that both attackers and defenders can garner valuable information about the networks that they’re targeting (or defending), it may come as a surprise that a smörgåsbord of information on these networks is often publicly available. Moreover, once this information has been made available to the public, it can be exceedingly, if not impossibly difficult to remove or redact.
Consider the transient nature of DNS records. While these records may be used to enumerate the sub-domains associated with a particular domain and identify third-party services which are used by a particular entity, they can be freely changed at any time by their owners. For example, the A record associated with a particular subdomain may be removed at any time by the owner of that subdomain. Similarly, the PTR records associated with a particular A record may change over time or be removed at the owner’s discretion (an A record maps a hostname to an IP address, and a PTR record maps an IP address to a hostname).
In contrast, consider the Certificate Transparency (CT) initiative that was launched by Google in March 2013. This experimental protocol ensures a certain degree of accountability when it comes to issuing TLS certificates, since all Certificate Authorities (CAs) are required to maintain a public and verifiable log of each and every one of the TLS certificates that they issue.
Under this protocol, all CAs are required to insert a copy of any TLS certificates that they issue within a tamper-resistant, append-only log of digital certificates.
In order to achieve both tamper-resistance and easily verifiable consistency proofs, a CT log is modelled in the form of a Merkle tree (i.e., a hash tree). This allows auditors to easily identify any CT log forks and track the insertion of any backdated certificates. That being said, the append-only nature of a CT log also implies that any digital certificates that have been stored within a CT log cannot be deleted, or modified, in any way.
The semi-permanent nature of CT logs provides for interesting takeaways for a security analyst. In addition to offering details information about a particular environment, this layer of transparency gives us the ability to learn more about how different entities interact with that environment.
These logs can be invaluable from a threat intelligence perspective. Since nearly all organizations use TLS certificates internally for the purpose of protecting information in-transit, there’s no limit to what you can find. As the age-old HaXmas adage goes, “Each time a TLS certificate is signed by an external CA, a corresponding entry is created in a publicly available CT log somewhere.”*
In addition to providing analysts with the ability to identify phishing domains, newly provisioned servers, and mis-issued certificates, CT logs can also be used for the purpose of identifying internal subdomains. In order to do this, you can simply inspect the Common Name (CN) field associated with each and every TLS certificate that you’ve parsed from a CT log, and compare the CN to the domain name that you’re interested in.
For example, if a Continuous Integration (CI) server uses a publicly-issued TLS certificate rather than a self-signed or internally-issued certificate, one could reasonably assume that the certificate will be publicly available. Moreover, if the domain name associated with the build server appears within the certificate, then the domain name associated with the CI server will be publicly available as well - even if the server is isolated behind the mightiest, and bravest of firewalls.
The real-time nature of CT log updates also allows us to learn more about freshly deployed servers—and this can lead to interesting adventures!
As of December 25th, 2017 there have been over 846 million entries made to the set of CT logs that Google monitors. These entries may include root, intermediate, or leaf certificates.
The vast network of CAs is hierarchically structured and consists of root CAs who entrust a number of intermediate CAs with the permission to sign TLS certificates on their behalf. These intermediate CAs then sign leaf certificates on behalf of registrants as a means of proving that the registrant is who they claim to be.
For example, consider the CT logs associated with example.com.
At a glance, we can see that there are three valid TLS certificates associated with this domain, as well as three recently expired certificates. After closely inspecting each of these certificates, we learn that they also reference a number of domain names within the Subject Alternative Name (SAN) X.509 extension field associated with each certificate.
An X.509 extension field is essentially an optional field that can be added to an X.509 certificate in order to describe additional data that isn’t captured by the mandatory fields.
From a threat intelligence perspective, that’s more information that can be collected in support of a particular engagement. More data = more information to go on!
While each of the domains mentioned within the Subject, or SAN X.509 extension field associated with a given TLS certificate may not be addressible from the public internet, or at all, they’re always worth diving into when searching for interesting things.
After all, who knows what kinds of goodies are being protected using TLS?
Google Chrome and other browsers may start to reject TLS certificates that have not been written to at least one CT log in the interest of ensuring that all TLS certificates are both cryptographically and publicly verifiable.
Let’s consider how a security analyst could use this information for the purpose of identifying the internal subdomains associated with a particular organization. Moreover, let’s consider how those subdomains could be identified without interacting with any of the hosts on that domain.
In order to do this, we could need combine information from at least one set of CT logs with a historical Forward DNS (FDNS) scan of 0.0.0.0/0 from Project Sonar (i.e., a set of DNS ANY responses across 0.0.0.0/0, which includes A/CNAME records), and a little bit of HaXmas magic.
First, we could identify each of the TLS certificates associated with a particular organization by comparing the name of that organization with the Organization (O) and OrganizationalUnit (OU) fields of each TLS certificate in a given log. Then, a unique set of subdomains could be extracted from the set of certificates by parsing the CN and SAN extension fields associated with each certificate.
We can identify each of the subdomains associated with a particular organization by comparing a particular domain name with each of the subdomains that were identified using the aforementioned FDNS scan.
If we subtract the set of subdomains which were identified using FDNS scans from the set of subdomains identified using CT logs, we would be left with a set of subdomains that either do not use TLS or are internal to a particular network.
From there, an analyst could use this information for the purpose of identifying all sorts of goodies, ranging from publicly accessible AWS S3 buckets to database servers. The point is: publicly available information can be used to identify where and how you’re storing information.
This holiday season, talk to your analysts about the gift that keeps on giving. After all, who knows what people are using TLS for?
*We might have made this adage up.
