Security | Software Development
Caveats and pitfalls of cookie domains 
Freek Wielstra 14 Mar, 2017
Share 
TLS should be mandatory for every website. But, when you set it up, make sure you configure the certificate correctly. This includes not having any sensitive data in any of the fields of the certificate. Because that certificate will become publicly available if you use a CA supporting Certificate Transparency. By Marinus Kuivenhoven and Jeroen Willemsen .
Let’s first start with stating the most important part of this article: there is nothing wrong with Certificate Transparency (CT). CT enables you to “…detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.” (Source: https://www.certificate-transparency.org/).
Browsers like Chrome use CT to verify whether a certificate was issued correctly and whether it can trust the certificate. Chrome can see various things in the CT system, such as which correct certificate of a given CA should be used.
But there is a certain downside to CT: services like censys.io, that try to index the internet, allow you to browse through the certificates. And those are quite a few:
Source: censys.io
In this very long list of certificates, we found internal APIs, middleware, IoT device endpoints, intranet websites, etc. that were designed not to be indexed or made public. Most of them will contain host names that elude to specific frameworks, like K8s and cucumber, or tools, like timeservers and databases.
How can you see whether your internal domains are exposed? Check via https://censys.io/certificates?q= or via https://crt.sh.
Why is this a problem?
Whenever an attacker or a pentester starts, he or she will first do a reconnaissance. A reconnaissance results in a functional and technical map of the IT-landscape. In the past, mistakes in DNS zone transfers or reverse lookup tables would give the adversary insight into which hosts run what in the network, but are not exposed or reachable from the outside. Because of the advances in security, those types of information disclosure are becoming quite rare. The CertShout discloses the information in a similar way and without the owner knowing that the information has been leaked.
Great. How do I proceed?
Here are a few things to consider:
- Don’t refrain from using TLS.
- Don’t play at being your own CA. Unless you are really confident you know what you’re getting into. It is no trivial thing.
- Understand that whatever you put into a certificate generated by a CA that supports CT, will be public: don’t put sensitive information in any of the fields.
- Verify what’s in your certs with services like censys.io or crt.sh.
- If you don’t want a server to be reachable from the outside world, be sure to take additional precautions on a network level.
Afterthought
There are plenty of ways to find your internet-connected service/device, CT is just one of them. Think about using search engines (Google Dorking) or repositories (Github or Bitbucket) to find security issues on publicly available resources – or services like Shodan to find any internet connected devices. Automating the scanning of these resources for new instances is a great way to start enhancing your Security Orchestration, Automation and Response (SOAR).
This summer-CERT is brought to you by Xebia Security.
Typical security jack-of-all-trades. Hands-on security architect with a nack for security, automation, and risk management. Jeroen has been involved in various OWASP projects. He enjoys a pentest every now and then, while helping organizations to get secure enough. Jeroen is often engaged in knowledge sharing through talks, blogs, projects at github, and trainings. Want to reach out? Check his allmylinks page.
