Fraudsters modify eBay listings with JavaScript redirects and proxies

Fraudulent classified ads posted on eBay have been exploiting an opportunity to establish convincing attacks against potential car buyers. Simply viewing one of the sneaky eBay ads causes the victim's browser to instead request the same listing via an intermediate server, which subtly modifies the content of the page to the fraudster's advantage.

Similar to a man-in-the-middle attack, the modifications are performed on-the-fly by a web server located in the US.

1. Victim browses to one of the fraudulent listings on eBay.co.uk; 2. eBay returns the listing to the victim's browser; 3. The fraudulent listing automatically redirects the browser to the attacker's website, passing the eBay item number to a PHP script; 4. The attacker's website uses the item number to fetch the same listing directly from ebay.co.uk; 5. eBay returns the listing to the attacker's website; 6. The attacker modifies the real eBay page before returning it to the victim's browser.

When a customer views one of the fraudulent ads on eBay, specially crafted JavaScript embedded within the item's description will automatically redirect the victim's browser to the attacker's website. The eBay item number is passed to a PHP script on the attacker's site, which allows it to fetch the same listing from ebay.co.uk before delivering a slightly altered version to the victim.

Most customers would not expect their browser to end up on a different website by merely viewing a listing on the real eBay website, which makes this attack dangerously effective. Additionally, because the modified listing looks extremely similar to the real thing (and displays the item they were expecting to see), it is likely that many victims would have no cause to suspect that the bogus content is being served from a completely different website. Although there are still a few small clues for the wary, this apparent weakness in the eBay platform is certainly much easier to exploit than a completely undetectable man-in-the-middle attack.


The fraudulent sites can also display legitimate eBay listings, changing the seller's contact details on-the-fly.
Images are sourced directly from eBay's own web servers.

Interestingly, the only significant differences on the modified page are that the Email the seller and the Ask a question links have been replaced with different links which send an email directly to EBAY@REGOWNER.CO.UK. On the real eBay website, these parts of the page cannot be altered because the item description is displayed within an iframe, making any JavaScript within the description unable to directly alter the contents of the parent window. By encouraging victims to immediately establish an email dialogue outside of the eBay website, the fraudster can attempt to secure money through non-reversible payment methods without eBay being able to monitor even the initial communication.

Victims are unlikely to be spooked by having to deal directly with the seller. While eBay's terms and conditions forbid anyone to buy or sell outside eBay, this applies only to its auction-style and Buy-It-Now listing formats. This scam makes use of eBay's newer classified ad listing format, where a purchase can only be carried out by dealing directly with the seller. In these cases, the victim would not be covered under eBay's buyer protection policy, nor would they be able to leave negative feedback which might alert other potential victims.

The fraudulent listings used in these attacks are posted from compromised eBay accounts, which allows the fraudster to piggyback on the trustworthiness and reputation of established sellers. If these compromised accounts have accrued lots of positive feedback from previous auctions, then this will also serve to leverage the trust of potential victims much more than a brand new account possibly could.

This type of attack is rather subtle considering the other opportunities that could have been exploited by the fraudster. Most obviously, the fraudster could have attempted to steal login credentials by presenting a spoof login form, but clicking on the Buy it now or Make offer buttons, or the My eBay menu item, actually directs the victim to the real eBay login page instead. However, the subtle changes that are made are the only ones necessary for these types of listings — when it is possible to score thousands of pounds with a single fraudulent sale via email, perhaps it is not worth attracting undue attention by also phishing for account details.


A fragment of JavaScript used by one of the fraudulent eBay listings.
This automatically causes a browser to display the modified content from the fraudster's server, without any user interaction.

The man-in-the-middle scenario is made possible by the inclusion of arbitrary JavaScript in the fraudulent listings. eBay's HTML and JavaScript policy explicitly prohibits the use of JavaScript to redirect a user from eBay to another webpage, but this rule is clearly being flouted. Accounts may be suspended for breaching the guidelines in this policy, which is another reason why it is common to see fraudulent listings being posted from compromised eBay accounts – whether or not these accounts get permanently suspended is largely inconsequential to the attacker.

Banning nefarious JavaScript through policy alone is rather ineffective, as fraudsters aren't going to mind breaking the rules. Given the potential for misuse, the lack of sufficient technical measures to prevent malicious scripts being embedded within an eBay listing poses a security risk, and the fraudulent listings posted on eBay over the past week demonstrate that this issue can be exploited rather effectively.

Because the description of an eBay listing is displayed within an iframe, the attack relies on being able to use a hyperlink to change the location of the parent window. This could be prevented by using HTML5's sandboxing features, which would cause a hyperlink with a target="_top" attribute to do nothing. The framed content would only be able to navigate within itself and not change the contact details in the surrounding top-level parent.

Although the fraudulent listings are eventually deleted by eBay, the same fraudster keeps coming back for more. Buster Jack — who regularly reports such scams to eBay — noted a similar attack by the same fraudster more than a week ago, which presented the modified content via the yugoslavic.info domain. In terms of value, Jack told Netcraft that the used car market is the most serious area of fraud on eBay.

Within the past week, Netcraft has blocked more than 20 other websites that the same fraudster had been using to modify the content of eBay listings. All of these sites used the .info top-level domain, shared the same IP address, and were hosted by HostGator in the United States.

The Scamwarners forum has documented similar cases of suspected fraudulent activity on the car trading website Autotrader. Here, the same fraudster has attempted to get potential buyers to make contact via various email addresses under his regowner.co.uk domain, rather than by phone or via the Autotrader website. The affected listings have since been removed from the Autotrader website, but the regowner.co.uk domain is still operational and able to receive email. The domain name itself lends authority to the scam by pretending it has something to do with the registered owner of a vehicle, and the local part of the email address (the part before the @ symbol) was the same as the car's number plate, such as KX60YSJ@REGOWNER.CO.UK.

The regowner.co.uk domain was registered with eNom on 27 March and currently points to a holding page hosted by Arvixe in the UK. Despite the domain's WHOIS registration type being set to "UK Individual", the registrant's address is purportedly in the United States. The .info domains used by the man-in-the-middle scripts were also registered last month, using an address in London.

Heartbleed: Why aren’t certificates being revoked?

Netcraft's site reports now make it easy to see which websites have or have not revoked their SSL certificates in response to the Heartbleed bug.

Around 17% of all trusted SSL web servers were vulnerable to the Heartbleed bug when it was publicly disclosed earlier this month. The bug made it possible to steal a server's private keys, thus allowing unauthorised parties to impersonate an affected website using its own SSL certificate. Consequently, around a quarter of the 500,000+ potentially-compromised certificates have already been reissued to date, but despite the importance of doing so, relatively few of these have also been revoked.

Some website administrators quickly responded to the Heartbleed bug by upgrading OpenSSL and issuing new SSL certificates, but issuing new certificates alone is not enough. Despite the difficulties involved in online revocation checking during a man-in-the-middle attack, the previous, possibly-compromised certificates must be revoked. Revocation checking can still be effective in some cases, especially when the revocation is included in Google's CRLSets.

For example, Yahoo had several high-profile websites which were vulnerable to the Heartbleed bug, and if the SSL certificates' private keys were compromised, they still are. Although the underlying OpenSSL vulnerability was quickly fixed on Yahoo's servers, it was not quick enough to prevent the vulnerability being exploited to reveal some of the email addresses and passwords used by Yahoo users. Yahoo has since reissued the affected certificates, and with the possibility of a key compromise, it would also have been sensible for Yahoo to revoke the old ones — but they have yet to do so.

Netcraft's site report for https://login.yahoo.com shows that the site offered the Heartbeat TLS extension prior to the Heartbleed disclosure, but is now using a new certificate. However, the new Heartbleed revocation section shows that the certificate previously used on login.yahoo.com has not yet been revoked. This means that anyone who uses Yahoo Mail, Yahoo Messenger, Flickr – and anything else which uses Yahoo's single sign-on mechanism – could still be vulnerable to man-in-the-middle attacks until it is revoked, or if not revoked, until February 2015.

Unfortunately, even when a certificate has been revoked, there is no guarantee that it cannot still be used to carry out man-in-the-middle attacks. If the attacker is also able to hijack OCSP requests, then he can exploit a browser's "soft-fail" approach to revocation checking, where a failed request will cause the browser to assume that the certificate is still good. CRLs (and Chrome's CRLSets) potentially offer slightly better protection under these circumstances, as the revocation lists may have already been downloaded while the browser was connected to a trusted network.

Yahoo is not alone in failing to revoke all of the certificates it reissued in response to the Heartbleed bug. At the time of writing, other companies in the same boat include Twitter, LinkedIn, Facebook, Apple, FedEx, PayPal and American Express, as well as the Schneier on Security blog. Many of these websites use Akamai's content distribution network, which was previously vulnerable to Heartbleed.

But why haven't all sites revoked their potentially compromised certificates? Some believe that online revocation checking is useless, some may not want to incur the cost of revoking a certificate, and many others may simply not realise (or believe) it necessary. Nevertheless, anybody who reissued a certificate in response to the Heartbleed bug presumably accepted there being some risk of the previous certificate being misused, in which case there is little justification for not revoking the old certificate. Administrators may want to delay revoking certificates to ensure that the new certificate has been fully deployed, but arguably, certificate authorities should not allow the delay between reissuance and revocation to stretch to several weeks.

Certificate revocation: Why browsers remain affected by Heartbleed

More than 80,000 SSL certificates were revoked in the week following the publication of the Heartbleed bug, but the certificate revocation mechanisms used by major browsers could still leave Internet users vulnerable to impersonation attacks. Little has changed since Netcraft last reported on certificate revocation behaviour.

Why is revocation necessary?

The Heartbleed bug made it possible for remote attackers to steal private keys from vulnerable servers. Most web server access logs are unlikely to show any evidence of such a compromise, and so certificates used on previously-vulnerable web servers should be replaced without delay.

However, even if the certificate is replaced, the secure site could still be vulnerable. If the pre-Heartbleed certificate had been compromised, it will remain usable by an attacker until its natural expiry date, which could be years away. A correctly positioned attacker, with knowledge of the old certificate's private key and the ability to intercept a victim's internet traffic, can use the old certificate to impersonate the target site.

Certificate authorities can curtail the lifetime of the compromised certificate by revoking the certificate. In principle, a revoked certificate should not be trusted by browsers, which would protect users from misuse of the certificate. The realities of revocation behaviour in browsers, however, could leave some internet users vulnerable to attack with compromised certificates.

The Heartbleed bug is currently the largest cause of certificate revocations, but other reasons for revoking certificates can include the use of weak signature algorithms, fraudulent issuance, or otherwise breaching the requirements laid out by the CA/Browser Forum.

How does revocation checking work?

There are two main technologies for browsers to check the revocation status of a particular certificate: the Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs). OCSP provides real-time revocation information about an individual certificate from an issuing certificate authority, whereas CRLs provide a list of revoked certificates which is typically retrieved by clients less frequently.

Of the major browsers, only Internet Explorer and Opera behave correctly in a wide variety of revocation scenarios, including where end-entity and intermediate certificates had been revoked only via a CRL or only via OCSP. The remaining browsers — Google Chrome, Safari, and Firefox — all have less consistent behaviour when checking the revocation status of SSL certificates.


Firefox blocks access to certificates which have been revoked via OCSP.

OCSP, the more recent standard, is effectively the revocation method of choice on the internet: providing the URL to a CRL in individual certificates is optional in the Baseline Requirements, and only Opera and Internet Explorer consistently check them when OCSP is not available. The latest version of Firefox removed the last vestiges of CRL checking: previously CRLs were checked only for EV certificates when OCSP failed.

Although CRLs have some disadvantages — their size for one — they do offer some key advantages over OCSP: CRLs can be downloaded ahead of time on a trusted network and, unlike OCSP, CRLs do not reveal which sites you are visiting to the certificate authority. Google's decision to disable OCSP checking by default was also partly due to these privacy concerns.

OCSP stapling is an alternative approach to distributing OCSP responses. By including a recent OCSP response in its own TLS/SSL handshake, a website can remove the need for each visitor to make a separate connection to the certificate authority. As well as improving performance, stapled responses remove the privacy concerns surrounding standard OCSP leaking user IPs to certificate authorities. However, only 24% of all SSL certificates found in the most recent Netcraft SSL survey were used on websites that stapled an OCSP response.

Google has shunned the traditional methods of revocation: whilst Chrome does check the status of EV certificates, revocation checking is not enabled by default for any other type of certificate. Instead, Chrome uses its own updating mechanism to maintain an aggregated list of revoked certificates gathered by crawling CRLs. This is a subset of all revocations and is intended to cover only the most important.

Is revocation checking useful for certificates potentially compromised by Heartbleed?

As explained by Adam Langley, online revocation checking can easily be blocked if the compromised certificate is being used in a man-in-the-middle attack. An attacker able to intercept traffic to the targeted website will likely also be able to block OCSP requests. If the victim is using a browser which does not hard-fail (which is the default setting of all major browsers) when an OCSP response isn't received, the attacker will be able to use a revoked certificate as normal.

However, the same logic does not apply to CRLs: if the CRL was downloaded earlier when on a trusted network, a revoked certificate used in a man-in-the-middle attack will not be trusted. This requires the certificate to have been revoked before the CRL was downloaded; however, many CRLs can be cached for a significant length of time (up to 10 days in the Baseline Requirements). Although, if a new CRL is needed, its download can be blocked just as effectively as OCSP's can be. When CRLs are used, an attacker cannot rely on the certificate passing validation: a subset of users, those with cached CRLs, will be prevented from continuing on the attacker's site. The same logic also applies to Google's CRLSets, including the ability to block updates.

As such, despite the difficulties of revocation checking in the MITM scenario, it is still critical for site owners to revoke certificates. If the certificate is revoked, an attackers job is made that much more difficult: he must chose sites with certificates issued without a CRL distribution point (which is permissible under the Baseline Requirements) or that are not covered by Google's CRLSets, and his victims must be using a browser that checks neither. Certificates that are not revoked are unlikely to ever be included in more effective revocation methods such as CRLSets.

Should I enable revocation checking in Chrome?

Whilst OCSP is easily blocked in man-in-the-middle attacks, if revocation checking is enabled, Chrome (on both Windows and Linux) will check CRLs for certificates that do not support OCSP. It is likely that you will have cached CRLs for websites you have visited recently — if you move onto an untrusted network, you will be protected by the CRLs that were downloaded earlier. Over 4% of currently valid certificates are only revocable by CRL, including login.skype.com. Unfortunately, for the majority of sites where OCSP is available CRLs will not be downloaded, any OCSP requests made can be blocked, and the attacker can continue as if the certificate is not revoked.

Perfect OCSP checks: A chicken and egg problem

By default, all browsers take the "soft-fail" approach to OCSP checks. A revoked certificate will be regarded as valid if the OCSP request fails. While this sounds like unsafe behaviour, browser vendors are reluctant to force a hard-fail approach because of the problems it can cause. For example, paid-for internet connections, such as WiFi hotspots or hotel room connections, that use captive portals are one of the major chicken-and-egg scenarios. Before a user can access the internet, he must visit a secure payment page, but this would fail because the OCSP responder used by the site's certificate cannot be reached until after he has paid. There are methods to resolve this problem, including OCSP stapling and less restrictive blocking; however, such solutions are unlikely to adopted quickly.


Firefox can be forced to use a hard-fail approach to OCSP checking, but this setting is not enabled by default.

It is critical that OCSP responders have 100% uptime, as any outage whatsoever could provide a window of opportunity to misuse compromised revoked certificates. Netcraft publishes a list of OCSP responder sites ordered by failures over the past day. Partly due to the reliability concerns, the Mozilla Foundation suggests that there is some way to go before a hard-fail approach can be enabled by default.

Despite the drawbacks of soft-fail OCSP checking, there are circumstances in which a soft-fail approach can still be useful. For example, it might be desirable to revoke a domain-validated certificate which had been issued to a deceptive domain name (e.g. paypol.com), or when a domain changes hands. In the absence of any man-in-the-middle attackers, soft-fail OCSP is likely to be effective.

Irrevocable certificates

Browsers that do not support CRLs, such as Firefox, are not able to determine whether or not the 4% of certificates without OCSP responder URLs have been revoked. Only if an OCSP response has been stapled to the TLS connection can such browsers check the revocation status. Given the majority of certificates (76%) are served without a stapled OCSP response, such certificates are effectively irrevocable for a large proportion of internet users. As a result, the compromised certificates can be misused for fraud up until their natural expiry dates. A smaller number of certificates fail to specify URLs for either method of revocation, which makes them completely irrevocable in all browsers which rely on these technologies.

It is likely that browser vendors will be forced to take additional steps to ensure that irrevocable certificates are correctly regarded as invalid. Such measures were taken in 2011, when Mozilla released new versions of Firefox which explicitly blacklisted some of the fraudulent certificates generated by the Comodo Hacker, even though the affected certificates had already been revoked by the issuer. One of the fraudulent certificates released to the public impersonated Firefox's addons site at addons.mozilla.org. Google's CRLSet gives it the ability to distribute such revocations without relying on any certificate authority to revoke the certificate.

Accenture was using a CRL-only Extended Validation certificate on its website at https://apps.accenture.com using a vulnerable version of OpenSSL (1.0.1e). The potentially compromised certificate was subsequently replaced with a new certificate issued on 14 April, and the previous certificate (serial number 0x0100000000013b03d6adfeff5c37) was revoked. The serial number was added to the CRL at http://crl.omniroot.com/PublicSureServerEV.crl. If an attacker had managed to compromise the private key used by the old certificate, he can continue impersonating apps.accenture.com with a seemingly valid SSL certificate until its natural expiry date in November 2014 for victims using browsers which do not check CRLs, which includes Firefox 28. The only indication that revocation checking has not been completed is the lack of the EV browser cues. This certificate is present in Google's CRLSet, and so Google Chrome users are protected against its misuse.

A currently deployed EV certificate without OCSP in Firefox 28 (left). The EV browser cues are not displayed in Firefox as the revocation status has not been checked. Internet Explorer (right), which has checked the revocation status on the CRL, does display the additional green bar with the company's name.

Apple's Safari web browser also does not perform any CRL revocation checks for Extended Validation certificates despite doing so for non-EV certificates. This behaviour may be based on the Baseline Requirements and the EV guidelines, which have mandated that EV certificates contain an OCSP responder URL for some time. As a consequence, the certificate previously used on apps.accenture.com is also irrevocable in Safari. In addition, despite making no revocation checks, Safari retains the EV browser cues rather than downgrading to standard SSL.

Problems revoking intermediate certificates

Digital certificates are verified using a chain of trust. At the top of the chain is the root CA's public key, which is built into the browser. The corresponding private keys can be used by the root CA to sign an intermediate certificate one step down the chain. At the very bottom of the chain is the certificate for the website itself, which is signed by the sub-CA whose intermediate certificate is immediately above the site's certificate. A single chain of trust can have multiple intermediate certificates chained together in order to form a path from the website's certificate to a trusted root.

An example of an SSL certificate's chain. This one is used by www.mcafeecustomerrewards.com.

Browsers must trust each level of the chain: all intermediate certificates in the chain must ultimately be signed by a root CA in order for the website's certificate to be trusted. Most root certificate authorities are understandably paranoid about the security of their private keys, and so root certificates are rarely compromised directly. Smaller certificate authorities, however, may not have as much funding or expertise, and may be more likely to suffer from security breaches which could result in the disclosure of an intermediate certificate's private key.

If the private key of a sub-CA's intermediate certificate is leaked, it has serious implications for the whole internet. A fraudster could use the certificate's private key to issue arbitrary publicly trusted certificates, essentially allowing him to impersonate any website on the planet. It is imperative that compromised intermediate certificates are immediately revoked, but it difficult to achieve this in practice.

For example, when a Firefox user visits www.mcafeecustomerrewards.com, a website which has a non-EV certificate, Firefox will only make an OCSP request for the website's certificate. This means that the revoked intermediate certificate (McAfee Public CA v1) will continue to be trusted by Firefox, and the only way to resolve this would be for Mozilla to release a new version of Firefox. The same behaviour is seen in Google Chrome unless revocation checking is enabled, as the intermediate certificate is not in Google's CRLSet. When Chrome has revocation checking turned on, the certificate is correctly marked as revoked.

    Serial Number: 55A1BA093A529CB41F12EB6A1FF71EF6
        Revocation Date: Oct  7 14:03:19 2013 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation
            Invalidity Date:
                Oct  7 14:03:09 2013 GMT

The entry for McAfee Public CA v1 in http://www.rsasecurity.com/products/keon/repository/certificate_status/RSA_Security_2048_v3.CRL.

www.mcafeecustomerrewards.com uses a certificate which has been signed by a revoked intermediate certificate (McAfee Public CA v1). Firefox displays the site without showing any warnings.

Google Chrome revocation bug

Although Google Chrome does not perform OCSP checks by default, it does perform them in the case of Extended Validation certificates (unless the certificate is already covered by the CRLSet). However, the Linux version of Google Chrome does not prevent access to sites using a revoked EV certificate when not covered by the CRLSet. Despite the browser sending an OCSP request and receiving a 'revoked' response, it mishandles the results and fails to block access. Instead, the EV browser cues (the green bar) is removed. Netcraft reported this apparent bug to Google in August 2013, but it was classed as low severity and has yet to be fixed on Linux.

The Windows version of Chrome (on left) behaves correctly and blocks access to a site with a revoked EV certificate. However, Chrome on Linux (on right) does not display any errors when a site uses a revoked EV certificate; it merely downgrades the UI from EV to standard SSL.

Where can we go from here?

Each of the currently available revocation methods has significant disadvantages: CRLs are potentially very large; OCSP can be blocked easily; and CRLSets are not intended to provide complete coverage. To those looking to move towards hard-fail, despite being far from pervasive, OCSP stapling could offer the answer. When combined with must-staple, currently an Internet draft, it would enable per-site, opt-in hard-fail behaviour. However, this solution is limited by the length of time (the Baseline Requirements limit the validity to 10 days) an attacker can use a cached 'good' OCSP response saved just before the certificate was revoked.

In the meantime, CRLSets, if they provided wider coverage, would be a more robust alternative to soft-fail OCSP checking. Mozilla is also looking to join Google by move towards a CRLSet-like mechanism for some of the revocation checking in Firefox.

Even soft-fail OCSP checking can be made more robust by removing any secure indicators (such as padlocks) when visiting a site without up-to-date revocation information.

Chrome users oblivious to Heartbleed revocation tsunami

In the aftermath of Heartbleed, it has become clear that revoking potentially compromised certificates is essential. On Thursday, CloudFlare announced it was reissuing and revoking all of its SSL certificates. The effects of CloudFlare's mass revocation are evident in a single Certificate Revocation List (CRL) belonging to GlobalSign, which grew by almost 134,000 certificates.

The vast number of CloudFlare certificates is due, in part, to the way in which it serves content over SSL. In order to work around the lack of support for Server Name Indication (SNI) in some older operating systems and mobile devices CloudFlare uses GlobalSign's Cloud SSL product. CloudFlare's SSL certificates make use of the Subject Alternative Name (SAN) extension, which allows an edge node to use a single certificate for multiple domains. When a new CloudFlare customer enables SSL, CloudFlare reissues an existing certificate with the new customer's domain added to the existing list of other customers' domains.

The number of certificates revoked per hour since 7th April. GlobalSign's OV CRL at http://crl.globalsign.com/gs/gsorganizationvalg2.crl and other CRLs have been separated.

As a result of CloudFlare's revocations, GlobalSign's CRL at http://crl.globalsign.com/gs/gsorganizationvalg2.crl has ballooned in size and now weighs in at 4.5MB. The CRL is hosted at CloudFlare itself but has nonetheless experienced some performance problems. However, the CRL's performance problems will not have had a significant effect on internet users, as most major browsers use OCSP in preference to CRLs and GlobalSign's OCSP responder did not have any performance problems.

Time to connect to http://crl.globalsign.com/gs/gsorganizationvalg2.crl from Pennsylvania

Time to connect to http://ocsp2.globalsign.com/gsorganizationvalg2 from Pennsylvania

However, most Google Chrome users are left in the dark, as Chrome performs neither type of check for non-EV certificates by default. Instead of conventional revocation checks, Google Chrome relies on an aggregated list of revocations, dubbed CRLSets, which are compiled by Google. The revocations from GlobalSign's CRL have not yet appeared in Google's CRLSets and hence Chrome users will not be warned if presented with a potentially compromised, but revoked, CloudFlare certificate.

The CRLSets deliberately do not cover all CRLs in an attempt to reduce the total size of the aggregated list. In effect, Google has traded the completeness of their revocation checking for a speed advantage over rival browsers as downloading CRLs or making OCSP requests imposes a performance penalty.

Google Chrome setting to enable revocation checking.

However, it is possible to configure Google Chrome to check for revocation. There is a checkbox in the Advanced settings menu to "Check for server certificate revocation".

Netcraft releases Heartbleed indicator for Chrome, Firefox, and Opera

The Netcraft Extension: Heartbleed and phishing protection rolled into one

The Heartbleed bug affected around 17% of all trusted SSL web servers when it was announced a week ago. The critical vulnerability in the OpenSSL cryptographic library has the potential to allow attackers to retrieve private keys and ultimately decrypt a server's encrypted traffic or even impersonate the server. This is not a theoretical problem: practical attacks have actually succeeded in stealing private keys, yet despite the potential dangers, many of the affected sites have yet to take remedial action.

Even if heartbeat support has been disabled, or OpenSSL upgraded to the latest version, a website that was previously vulnerable to Heartbleed is not necessarily secure today. If the vulnerability had been exploited prior to the upgrade, the certificate's private key could have been compromised. If the certificate has not yet been replaced and the old one revoked, an attacker could impersonate the site and carry out man-in-the-middle attacks against the site's visitors.

Netcraft's updated extensions for Chrome, Firefox and Opera now allow you to see whether the sites you visit are still using potentially compromised certificates. The extensions use data from Netcraft's SSL Survey to determine whether a site offered the heartbeat TLS Extension prior to the Heartbleed disclosure. If this is the case, the extension will also check to see if the site's SSL certificate has been replaced; if it has not, then the site is considered to be unsafe, as the certificate's private key could have been compromised. Even if the certificate has been replaced, it does not guarantee that the site cannot still be impersonated with a copy of the old certificate unless the old certificate has been revoked – and even then, the revocation checking done by browsers is not infallible.

Go here to download the Netcraft Extension for Chrome, Firefox or Opera.


Heartbleed indicator in the Netcraft Google Chrome and Opera Extensions

The extension will indicate when a site is potentially unsafe by displaying a bleeding heart icon. Additionally, in the Google Chrome and Opera versions of the Extension, a warning triangle will be displayed on top of the Netcraft icon.


Heartbleed indicator in the Netcraft Firefox Extension

As well as indicating which sites are using a certificate potentially compromised using Heartbleed, the Netcraft Extension also helps protect you from phishing attacks, displays the hosting location and risk rating of every site you visit, and lets you help to defend the internet community against fraudsters.

Netcraft's site report pages can also be used to determine whether a website might still be affected by the fallout from the Heartbleed bug. For example, our site report for https://www.linkedin.com shows that it no longer supports the TLS heartbeat extension and is using a new certificate.

In contrast, the site report for https://www.fedex.com currently shows that the server previously supported TLS heartbeat and the SSL certificate has not been replaced. Even though TLS heartbeat is now disabled, the certificate could still be used to impersonate the site if it had been compromised prior to heartbeat being disabled. Fedex's website is hosted by Akamai, a popular Content Distribution Network, which was potentially vulnerable to Heartbleed. Akamai is in the process of rotating its customers' SSL certificates and stated that "some require extra validation with the certificate authorities and may take longer".

Heartbleed indicator in the Netcraft Site Report

Heartbleed: Revoke! The time is nigh!

As the results of CloudFlare's challenge have demonstrated, a server's private key can be extracted using the Heartbleed vulnerability. Consequently, the 500,000+ certificates used on web servers supporting TLS heartbeat should be urgently replaced and revoked. Whilst the replacement and revocation process has begun — 80,000 certificates have been revoked since the announcement — it is far from over.

Private key extraction is real

CloudFlare, which uses a modified version of the nginx web server, originally thought it would be extremely hard or impossible to use the Heartbleed bug to steal a certificate's private key from an nginx server. However, this was quickly proved wrong last week after CloudFlare set up a vulnerable website and challenged people to steal its private key. Later on the same day, the private key had been successfully stolen by exploiting the Heartbleed bug.

Fortunately, CloudFlare decided to play it safe and planned to reissue and revoke potentially affected certificates anyway. CloudFlare also acknowledges that the revocation process is far from perfect and not suitable at mass scale: "If every site revoked its certificates, it would impose a significant burden and performance penalty on the Internet". CloudFlare's own website at cloudflare.com started using a new SSL certificate yesterday, despite the new certificate being marked as valid from 10 April 2014.

Akamai is also planning to rotate all of its customers' SSL certificates after realising a flaw in its recent patch which it originally believed would protect users against the Heartbleed bug. Akamai is notable for its content delivery network of more than 61,000 servers, which they claim delivers 15-20% of all web traffic.

There are already reports that Heartbleed has been used to compromise secure web sites including Canada's tax agency and popular UK web forum Mumsnet.

Revocation is critical (even if it doesn't always work)

As of this morning (Tuesday 15th April), more than 80,000 certificates have been revoked since the public announcement of the vulnerability on 7th April.


The Heartbleed bug has caused a rise in certificate revocations, but the rate predictably fell over the weekend.

Based on list prices, the cost of replacing all of the potentially-compromised certificates with completely new certificates is more than $100 million, but, helpfully, most (but not all) certificate authorities are allowing their customers to reissue and revoke certificates for free. Nonetheless, plenty of the affected websites (e.g. Etsy, Yahoo, GitHub, Steam) appear to have bought new certificates instead of going through the reissuance process, as the new expiry dates are significantly later than the expiry dates in the previous certificates. Perhaps in the haste of resolving the problem, this seemed the easiest approach, making Heartbleed a bonanza for certificate authorities.

While some companies quickly recognised the need to issue new certificates in response to the Heartbleed bug, the number of revocations has not kept up. This is a mistake, as there is little point issuing a new certificate if an attacker is still able to impersonate a website with the old one.

Yahoo was one of the first companies to deploy new SSL certificates after the Heartbleed bug became public knowledge, but the certificate that was previously used by mlogin.yahoo.com has not yet been revoked — it has not been placed on a CRL, and the certificate's OCSP responder says the certificate is "good".

Yahoo is not the only company to have issued a new certificate without ensuring that the previously vulnerable certificate has been revoked. Other sites which fall into this category include banking websites (such as entry7.credit-suisse.ch), the United States Senate large file transfer system at lfts.senate.gov, and GeoTrust's SSL Toolbox at https://ssltools.geotrust.com/checker/ (GeoTrust is a brand owned by Symantec, the largest certificate authority).

Thousands of certificates could still be misused after being revoked

Critically, some of the certificates affected by the Heartbleed bug will remain usable even if revoked: Nearly 4% of the certificates do not specify a URL for an OCSP responder, which means that they can only be revoked via a CRL. This makes the certificates effectively irrevocable in some browsers — for example, the latest version of Mozilla Firefox no longer uses CRLs at all (previously it would fall back to checking a CRL if an OCSP request failed, but only for Extended Validation certificates).

Worse still, a small number of the certificates that could have been compromised through exploitation of the Heartbleed bug fail to specify either an OCSP or a CRL address. These certificates are therefore completely irrevocable in all browsers and could be impersonated until their natural expiry dates if an attacker has already compromised the private keys.

For example, Telecom Italia (a sub-CA of Verizon Business) is still using an irrevocable certificate on www.cloudpeople.it, which supported the TLS heartbeat extension prior to the disclosure of the Heartbleed bug. The 3-year certificate was issued by I.T. Telecom Global CA at the end of 2011 and will remain valid until the end of 2014 because it does not permit either form of revocation.

CRLs will balloon as a result of the surge of revocations

To obtain the certificate revocation lists (CRLs) used by each publicly trusted certificate authority, a web browser would need to download more than 100MB of data. These CRLs will grow by about 35% if all of the certificates affected by the Heartbleed bug were revoked. Downloading this much data is clearly impractical for many mobile devices, and several CRLs either time-out or take more than a minute to download, even from a desktop machine with a fast internet connection. This goes against the CA/Browser Forum's Baseline Requirements, which expect CAs to provide response times of less than 10 seconds.

The largest CRL (11MB) is operated by the US Department of the Treasury, and despite containing more than 200,000 revocation entries, it is only used by one publicly accessible certificate. Nonetheless, any browser wishing to perform a CRL check for that one site will have to download the whole list. Governments also feature amongst the worst-performing CRLs: For example, the Taiwanese government offers a CRL at http://hcaocsp.nat.gov.tw/repository/HCA/CRL/complete.crl, which would not respond when tested earlier today, and the Brazilian government offers several CRLs from its site at repositorio.icpbrasil.gov.br, but each took 2-3 minutes to download, despite being of relatively modest sizes.