Is this website secure? Well, it just contains statically generated content and holds no personal information, so most likely it is. But how would you be able to tell whether it actually is secure?
This problem is exactly what security seal providers are trying to tackle. These seal providers offer a service which allows website owners to show their customers that their website is secure, and therefore safe to use. This works as follows:
- The security seal provider initiates a vulnerability scan towards the to-be-sealed website.
- When the website is found to be without vulnerabilities, the website owner can include a seal on his website, which links to the seal provider, and shows the security of the sealed website is A-ok.
- In case some vulnerabilities were found, the seal provider reports these to the webmaster, who has a limited amount of days to fix these before the seal becomes invisible (more on this later).
- This process is repeated every day, week, month or quarter, depending on the security seal provider.
Now, does having such a security seal on your website actually mean you can trust what the seal provider is claiming, and that your website is secure, or does it actually introduce new types of vulnerabilities and increase the likelihood of compromise? This is exactly what we wanted to find out in our research.
Before getting into the results, and new types of attacks we found, let me first guide you through some more background on how the different seal providers operate, and which experiments we executed to evaluate the claims of security by the seal providers.
Security Seals
In our research, we evaluated 10 different security seal providers, whose security seal you can see below. These seals can be included with some basic HTML code, for instance:
<a href="https://seal-provider.com/verify/?id=mywebsite.com">
<img src="https://seal-provider.com/seal.png?id=mywebsite.com">
</a>
The security seal image is dynamically generated, based on the state of security in mywebsite.com. In case the website was found to be secure, the seal will be shown (just as the seals below). This seal also links to the website of the seal provider, so the visitor can verify that the seal is valid, and is not just an image the website administrator put on his website.
In case the website was found to be vulnerable, none of the seal providers will show this on their seal. Instead, most of the seal providers will just make the seal invisible (by turning it into a 1x1 px image, or making it transparent). So to an average visitor, a vulnerable, sealed website will just look like a website without a security seal. Note: when a vulnerability was found in a sealed website, most seal providers allow the website administrator a grace period of a couple of days during which he can fix the vulnerability before his seal becomes invisible.
As I’ve said before, in our research we wanted to find out whether having such a security seal on your website actually means your website is more secure. There have been some reports on security seals being sketchy, but these were mainly anecdotal or for a handful of websites. We wanted to look at the security seal ecosystem, and verify the security-claims at a large scale. In order to do so, we collected a list of seal-using websites by crawling the homepage of the 1 million most visited websites according to Alexa, and looking for the presence of a security seal. By using Google dorks, we managed to discover some more websites. For instance, using site:mcafeesecure.com/verify?host= allows you to discover a large number of McAfee SECURE customers (as you can see for yourself on Google). As a result, we discovered 8,302 websites using security seals which we then evaluated. Interesting to note: most of the seal-using websites are webshops, which makes sense, as these websites may benefit financially by having users trust them. From an attacker’s perspective, this is also interesting, as these websites often hold valuable data (credit cards, …).
Security Evaluation
To analyze whether sealed websites are actually secure, or at least more secure than non-sealed websites, we executed three experiments:
- A comparison of adoption of security mechanisms in sealed websites versus non-sealed websites
- A manual penetration test of sealed websites which were willing to cooperate
- Analyzing the vulnerability scanners employed by seal providers by setting up a vulnerable webshop
I will briefly discuss each experiment and its results. For more details, please refer to our paper.
1. Comparison to non-certified websites
In this experiment, we made the assumption that websites with a security seal try to protect their users as good as possible. Next to trying to identify and fix vulnerabilities in your website, one can also use certain security mechanisms which will make it much harder for an attacker to successfully exploit a vulnerability. For example, when the HttpOnly attribute is set on a cookie, this cookie is not accessible through JavaScript. So even if an attacker is able to find an XSS vulnerability in your website, he will not be able to steal the cookie.
In our experiment, we evaluated the presence or absence of nine security mechanisms, which are indicative of a website’s “security hygiene”. We compared the adoption of these mechanisms between sealed websites and equivalent (same category, similar Alexa ranking) non-sealed websites, and found what previous reports already indicated: sites with a security seal are not significantly more secure than sites without such a seal.
2. Penetration testing
So sealed websites don’t adopt security mechanisms more often than non-sealed websites. Perhaps they don’t need these, as they were thoroughly scanned and therefore shouldn’t contain easily discoverable vulnerabilities? To verify this claim, we executed another experiment where we did a manual penetration test of max. 8 hours (approximately the time a moderately interested attacker would be willing to spend).
In order to find websites willing to cooperate (i.e. allowing us to do a free penetration test, of which the results would be used anonymously), we contacted a total of 1,000 sealed websites by filling out the contact form on the website, or sending them an email.
Interesting sidenote: the template text we used, contained the contraction don't; something we didn’t pay attention to, until at one point we received a MySQL error, indicating the contact form was actually vulnerable to SQL injection attacks.
Of the 1,000 websites we contacted, very few responded. Next to the emails we received where we were explicitly prohibited from doing any sorts of tests, we did manage to find 9 websites willing to cooperate. The results of the penetration test of these nine websites are quite worrisome: we found vulnerabilities in 7 out of the 9 websites. In most cases, these vulnerabilities were easily discoverable, e.g. several cross-site scripting vulnerabilities where a GET parameter was reflected without proper encoding. This shows there are definitely quite some shortcomings in thoroughness of the security tools used by seal providers.
3. Vulnerable webshop
To further evaluate the thoroughness of the vulnerability scanners used by the seal providers (the performance of these scanners is key for the trustworthiness of a security seal), we set up a vulnerable webshop for which we tried to obtain a security seal. The webshop was an outdated version of PrestaShop (a popular open-source e-commerce web application), where we included several vulnerabilities, such as XSS, SQL Injection, …
We managed to buy (or get free trials for) security seals from eight companies. Surprisingly, we could immediately include two seals in our website, as the two seal providers did not find any vulnerability in our website. By looking at our server logs, we found that the lack of vulnerability discovery actually was not that very surprising. One of the seal providers merely ran a port scan using Nmap, and the other did a very basic Nessus scan. These tools are definitely not adequate to perform a rigorous security evaluation of a website.
The other six seal providers did manage to find *some* vulnerabilities, but performed far from sufficient. Five seal providers found a third or less of the vulnerabilities, and one found almost half. Of course, you could argue that we made it incredibly hard for the seal providers to find these vulnerabilities. That’s why we compared the coverage of found vulnerabilities with three popular vulnerability scanners (Acunetix, HP WebInspect, Burp Suite). These tools, which can also be used by an attacker, found at least as many vulnerabilities as the best-performing seal provider.
I guess it doesn’t really come as a surprise that these experiments show that sealed websites are not more secure than non-sealed websites in general. But well, there is no harm in using one of these security seals, right?
Attacks
Although the services offered by seal providers attempt to improve the security of websites that make use of, we found several attacks which are inherent to the security seal ecosystem. These attacks may expose a sealed website to an additional risk of being exploited. In this section I will discuss a subset of the attacks we found, for the complete list, please refer to our paper.
1. Using security seals as an oracle
In the beginning of this post, I mentioned that when a vulnerability was found in a seal-using website, this seal will become invisible. This means that an adversary can infer the state of security from the security seal: visible means no vulnerability was found, invisible means the website is actually vulnerable. Now, all an attacker needs to do in order to discover vulnerable websites, is (1) collect a list of seal-using websites - this is quite easy using Google dorks, (2) grab the seal for each website every day, and (3) check whether the image is invisible.
We actually did just that during a two-month-long experiment, and found a large number of websites with an invisible seal. Next to being vulnerable, having an invisible seal can also mean that the contract between the website and seal provider ended. But for an attacker, having an invisible seal on your website may already be enough incentive to launch an attack.
Next to the visibility of a security seal, there’s another way to leak the state of security of a certain website: the seal-verification page on the seal provider’s website. This page contains some basic information on the website, the offered services, and the results of the scan (e.g. the last day the website was found to be secure). For some seal providers, this leaks some additional information, and allows an attacker to identify whether an invisible seal means the contract has ended, or that the website is actually vulnerable. In our experiment, we found over 100 websites that most likely contained a vulnerability (or at least one that was found by the seal providers) at some point during the two months the experiment ran.
Update: At Derbycon 2012, Jay James & Shane MacDougall presented a tool called “Oizys” which would try to enumerate customers of McAfee and Trust-Guard and pinpoint vulnerable websites by analysing disappearing seals.
2. Identify vulnerabilities
When the attacker found a vulnerable website, he will still need to identify the vulnerability. He could do this by starting a vulnerability scan in his favorite tool, manually pentest the website, or again abuse the security seal services to help him with this daunting task. The latter may actually work best, since the seal provider found the vulnerability before, and will probably find it again.
So in order to discover the vulnerability that lead to the seal turning invisible, the attacker can do the following:
- Set up a proxy, this proxy will forward all incoming requests to the vulnerable website, and return its response.
- Register for a free trial at the seal provider (most seal providers offer this)
- Tell the seal provider to scan the security of the proxy-server
- Once the scan has completed, the seal provider will share the vulnerabilities it found in the proxy (so actually in the attacker’s target)
Easy peasy!
3. Improve phishing campaigns
If the presence of a security seal actually improves the trustworthiness of a website, the same should hold for phishing websites. So to improve the trustworthiness of a phishing campaign, attackers can include a security seal. Although attackers can simply duplicate the security seal image and place it on their phishing page, clicking the image will not show the website is secure. This is because some seal providers check the Referer header. If the value of this header does not match the domain of the seal, it is not shown.
Interestingly, when the Referer header is missing, seal providers happily show the security seal and status page. An attacker can easily achieve this by adding following HTML tag to his phishing page: <meta name="referrer" content="never">. According to the W3C specs, this will suppress the Referer header from being sent.
4. Attack 3rd-party websites
In this last attack, I will show how an attacker can trick a seal provider to start a vulnerability scan against an arbitrarily chosen website. Running a vulnerability scan against a website may come with a certain cost for the attacker. We found that a single seal provider made over 170,000 requests to check the security of our relatively simple webshop. How nice would it be if you could just let the seal provider do the heavy lifting and receive a report with all the vulnerabilities that were found?
When signing up with a seal provider, one first needs to prove ownership of the website you want to obtain a seal for. This proof-of-ownership is usually as follows: the seal provider supplies a file with a randomly generated name, e.g. j52ykxg4emi7nda49ofk, and content, e.g. ojh199xpovu8uxmx4n1q3qzv6j6eo13t4bbtb36s. The website owner then uploads this file on his website, and tells the seal provider to check the authenticity. The seal provider will then request http://attacked-website.com/j52ykxg4emi7nda49ofk, and check for the presence of the randomly generated string. Some seal providers will just verify whether this string appears *somewhere* on the page.
Now take a look a my freshly created Vimeo page: https://vimeo.com/j52ykxg4emi7nda49ofk. This page contains the randomly generated string ojh199xpovu8uxmx4n1q3qzv6j6eo13t4bbtb36s as part of my bio description. This means that I can trick the three seal providers that don’t require an exact match of the uploaded file, to do a security scan on vimeo.com, and report back the vulnerabilities they found to me.
Conclusion
This research shows that websites containing a security seal are not significantly more secure than sites without such a seal. This has two major implications: (1) users of sealed websites are often falsely tricked into believing they are secure, and (2) owners of sealed websites are lead believing their website is secure, which may prevent them from spending additional resources (e.g. by implementing security mechanisms) to make their website more secure.
The discovery of the discussed attacks shows that signing up for a security seal service may even be hazardous. By having a security seal, websites may actually become an easy and alluring target for attackers.
