By
Despite many cyber-security advances over the last 20 years, well-known cyber-criminal exploits like phishing still pose pervasive threats. Verizon Enterprise’s 2018 Data Breach Investigations Report (DBIR) has found this to be so. Of the 53,000 incidents it received in the reporting period, Verizon Enterprise found phishing to be the third most widely used incident action variety at 1,192 events. Phishing also registered as the top social attack method observed by Verizon Enterprise, a finding which indicates that bad actors continue to abuse technology in order to prey on human weakness.
The misuse of technology can even contribute to the effectiveness of phishing attacks. In this article, I will be focusing on one such technology: wildcard certificates. I will give a few real-world examples of how cyber-criminals exploit the trust organizations have in such certificates, and I will provide some recommendations for protecting your resources from phishing scams.
Using a wildcard certificate on a publicly facing web server increases the risk that cyber-criminals will use the webserver to host malicious websites in phishing campaigns.
To understand why you must understand a bit about wildcard certificate security. A wildcard certificate is a public key certificate used by all subdomains within a larger domain. Using wildcard certificates reduces the overall burden on system administrators. However, from a security standpoint, these certificates open up a can of worms.
Any subdomain created for the domain on a web server that uses a wildcard certificate will use the same certificate. For example, a webserver with a wildcard certificate is hosting the domain https://example.com. Anyone with access to the webserver can set up a subdomain, https://phishing.example.com, on the webserver using the wildcard certificate. Visitors to the phishing site do not realize that they are on the phishing site because their browsers establish an HTTPS connection using the legitimate wildcard certificate.
You’re probably asking yourself, “Who would fall for something so simple? Surely anyone would recognize the illegitimate website.” But that’s not always true.
According to recent research from Venafi, attackers commonly outfit their phishing sites with lookalike domains that are differentiated by just a few characters or even homoglyphs designed to look like the legitimate domain. Most phishing sites also use long URLs to take advantage of the fact that a user is not likely to scroll through the entire URL. Additionally, the browser truncates the long URL, only showing, for example, the green highlighted part and not the malicious site: https://paypal.com.ylv=4$qid?532093256142-2-0351439098.webscr?cmd.phishing.example.com/83529hrs5.
Setting up a subdomain is exactly how cyber-criminals exploited a wildcard certificate security issue on the Malaysian Police portal in the summer of 2013 and used the portal for a phishing attack.
In the last five years, malware designed to steal keys and certificates has proliferated, and a thriving marketplace for stolen certificates has sprung up. The work of BlackTech and its use of PLEAD and DRIGO to steal D-Link certificates for signing malware presents yet another example of how cybercriminals stage attacks to steal organizations’ encryption assets. Like compromising a webserver, gaining access to a wildcard certificate’s private key provides an attacker with the ability to impersonate any domain that is using a wildcard certificate (*.example.com).
When cyber-criminals compromised DigiNotar back in 2011, the attackers were able to steal a Google wildcard certificate (*.google.com). Using the stolen wildcard certificate, an attacker would be able to set up a fake website for any Google service and then direct victims to the fake service by poisoning DNS services. Because the attacker is using a stolen wildcard certificate, the victim receives no warning when visiting the fake Google website.
In addition to compromising a certificate authority like DigiNotar, attackers can prey upon users with the help of digital certificates in other ways. Illustrating this fact is the March 2015 case of someone having obtained a privileged email account for Microsoft’s live.fi domain and abused that access to register a bogus SSL certificate, which bad actors could have leveraged to conduct phishing and/or man-in-the-middle (MitM) attacks. The security industry has also at times spotted vulnerabilities that could allow bad actors to spoof SSL servers via wildcard certificates.
A simpler option than compromising a CA is to trick a CA into issuing a wildcard certificate for a fictitious company. Once a hacker has the fictitious company’s wildcard certificate, the hacker can create subdomains and establish phishing sites that masquerade as belonging to any organization.
Digital attackers are specifically turning to Let’s Encrypt to obtain certificates for fictitious companies. They’re doing so as a matter of ease and cost. On the one hand, certificates obtainable from Let’s Encrypt are free, which lowers the costs of conducting phishing attacks. At the same time, Let’s Encrypt is automated, making it less difficult to obtain certificates in the first place.
Given the advantages explained above, it’s not surprising Venafi found that Let’s Encrypt accounted for 84 percent of the digital certificates issued to lookalike domains. The service issued 15,000 certificates containing the word “PayPal” between January 1, 2016 and March 6, 2017, for example. Of those issued certificates, 95 percent of them were used for phishing sites.
Clearly, attackers are comfortable with using wildcard certificates for phishing email attacks and other attacks. Fortunately, security controls and solutions can help block an attack. By putting these defenses in place, you increase the effort that a malicious actor must take to compromise your network. Your goal is to make compromising your network so expensive that cyber-criminals would rather focus their attention on someone else. As the saying goes: When a lion chases you, you don’t need to be the fastest runner; you just have to be faster than the person behind you.
You can make your organization more costly to exploit by avoiding wildcard certificates. Although wildcard certificates make business operations simpler, they provide a tremendous opportunity to any cyber-criminal who compromises your webserver or steals a wildcard certificate’s private key.
Don’t let cyber-criminals use your wildcard certificate security in malicious campaigns. Avoid using wildcard certificates on production systems, especially public-facing ones. Instead, you should use subdomain-specific certificates that are rotated often. Compromised wildcard certificate security can lead to serious repercussions, but, by using short-lived, non-wildcard certificates, you significantly mitigate the impact of an attack.
Originally published by Gavin Hill on March 18, 2014
Lorem ipsum dolor sit amet, consectetur elit.
Thank you for subscription
Scroll to the bottom to accept
VENAFI CLOUD SERVICE
*** IMPORTANT ***
PLEASE READ CAREFULLY BEFORE CONTINUING WITH REGISTRATION AND/OR ACTIVATION OF THE VENAFI CLOUD SERVICE (“SERVICE”).
This is a legal agreement between the end user (“You”) and Venafi, Inc. ("Venafi" or “our”). BY ACCEPTING THIS AGREEMENT, EITHER BY CLICKING A BOX INDICATING YOUR ACCEPTANCE AND/OR ACTIVATING AND USING THE VENAFI CLOUD SERVICE FOR WHICH YOU HAVE REGISTERED, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY AND ITS AFFILIATES TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY AND ITS AFFILIATES. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICE.
You shall not access the Service if You are Our competitor or if you are acting as a representative or agent of a competitor, except with Our prior written consent. In addition, You shall not access the Service for purposes of monitoring its availability, performance or functionality, or for any other benchmarking or competitive purposes, and you shall not perform security vulnerability assessments or penetration tests without the express written consent of Venafi.
This Agreement was last updated on April 12, 2017. It is effective between You and Venafi as of the date of Your accepting this Agreement.
The Venafi Cloud Service includes two separate services that are operated by Venafi as software as a service, each of which is separately licensed pursuant to the terms and conditions of this Agreement and each of which is considered a Service under this Agreement: the Venafi Cloud Risk Assessment Service or the Venafi Cloud for DevOps Service. Your right to use either Service is dependent on the Service for which You have registered with Venafi to use.
This License is effective until terminated as set forth herein or the License Term expires and is not otherwise renewed by the parties. Venafi may terminate this Agreement and/or the License at any time with or without written notice to You if You fail to comply with any term or condition of this Agreement or if Venafi ceases to make the Service available to end users. You may terminate this Agreement at any time on written notice to Venafi. Upon any termination or expiration of this Agreement or the License, You agree to cease all use of the Service if the License is not otherwise renewed or reinstated. Upon termination, Venafi may also enforce any rights provided by law. The provisions of this Agreement that protect the proprietary rights of Venafi will continue in force after termination.
This Agreement shall be governed by, and any arbitration hereunder shall apply, the laws of the State of Utah, excluding (a) its conflicts of laws principles; (b) the United Nations Convention on Contracts for the International Sale of Goods; (c) the 1974 Convention on the Limitation Period in the International Sale of Goods; and (d) the Protocol amending the 1974 Convention, done at Vienna April 11, 1980.
In the meantime, please explore more of our solutions
In the meantime, please explore more of our solutions
This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly. Find out more on how we use cookies.