Keys left unchanged in many Heartbleed replacement certificates!

Although many secure websites reacted promptly to the Heartbleed bug by patching OpenSSL, replacing their SSL certificates, and revoking the old certificates, some have made the critical mistake of reusing the potentially-compromised private key in the new certificate. Since the Heartbleed bug was announced on 7 April, more than 30,000 affected certificates have been revoked and reissued without changing the private key.

Internet users rely on public key cryptography to verify the identity of secure websites: SSL certificates contain a public key that is generated from its associated private key. At the start of the secure connection, the server proves that it has the private key by decrypting messages encrypted with the public key, or by cryptographically signing its own messages. Keeping the private key secret is critical — if an attacker steals the private key, he can impersonate the secure website, decrypt sensitive information, or perform a man-in-the-middle attack.

Although we typically refer to "potentially-compromised" certificates when discussing the Heartbleed bug, the CA/Browser Forum adopts a much more cautious approach to its terminology. This group lays out the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, and they consider a private key to be "compromised" if there exists a practical technique by which an unauthorised person may discover its value — even if there is no evidence of such a technique having been exploited.

By reusing the same private key, a site that was affected by the Heartbleed bug still faces exactly the same risks as the those that have not yet replaced their SSL certificates — if the previous certificate had been compromised, then the stolen private key can still be used to impersonate the website's new SSL certificate, even if the old certificate has been revoked. Certificates that have been reissued with the same private key are easy to identify, as the new public key will also be identical to the old one.

Only 14% of affected websites (Zone A in the above Euler diagram) have done all three required steps after patching the Heartbleed bug – they have replaced their SSL certificates, revoked the old ones, and made sure to use a different private key. This zone also includes sites with certificates that expired shortly after the bug was disclosed.

Zone B represents the 5% of sites that have made the fundamental mistake of reissuing their certificates without changing the private key. This is the most dangerous zone, as not only could these websites still be vulnerable to impersonation attacks, but the website administrators will probably believe that they have done everything necessary to fix the problem. An additional 2% have reused the same private key and not revoked the old SSL certificate.

The white outer zone represents nearly 57% of the affected sites which have taken no action whatsoever — they have neither reissued nor revoked their certificates. A further 21% have reissued their certificates with a new private key, but failed to revoke the old ones.

The Canadian government ought to appreciate the risks posed by the Heartbleed bug more than others, particularly after the bug was exploited to steal social insurance numbers from the Canadian Revenue Agency. However, some parts of the Canadian government have made the mistake of reusing private keys while trying to mitigate the risks.

The Quebec Automobile Insurance Corporation is a crown corporation responsible for licensing drivers and providing personal injury insurance to the public. One of its websites at was issued a new SSL certificate in response to the Heartbleed bug, and the previous certificate was revoked on 29 April. The CRL revocation status listed the reason as "keyCompromise", but the issuing certificate authority nonetheless allowed the new certificate to be signed with the same private key. This means the new certificate can also be impersonated by anyone who is in possession of the compromised key.

This type of mistake could be prevented by certificate authorities: if public keys from revoked certificates were blacklisted, new requests with the same public key would be rejected. This type of automated check does not seem to be in use by most CAs; however, Netcraft's Site Reports and browser extensions can be used to determine whether a website has signed its replacement certificate with the same private key:

Thai Government websites infested with malware

Nearly 100 Thai Government websites were hacked and used to serve malware last month. More than 500 distinct attacks were launched from these websites, representing about 85% of all government-hosted malware in the world.

Seven of the hacked sites belong to Thai police forces, such as the Narathiwat Provincial Police website at, where hackers have appended a large chunk of malicious VBScript to the page shown below. This script attempts to write malware from a hexadecimal string to a file named svchost.exe on the local file system, and then tries to automatically run the malware contained within the freshly planted executable file.

This page on the Narathiwat Provincial Police website exposes visitors to drive-by malware.

The filename used in this attack has been deliberately chosen to make it look as though the malware is a legitimate Windows component when it appears in a list of running processes. The genuine svchost.exe file, which normally resides in the Windows\System32 folder, is used as a generic host process name for services that run from DLL files.

Part of the malign VBScript appended to the bottom of the HTML document.

Thai military websites were also compromised during April. For example, the Thai Navy website at was involved in a phishing attack which targeted VISA cardholders last week. A page surreptitiously planted on the Navy's server was used to redirect victims to a different website hosted in Malaysia, which attempted to steal card details. The Malaysian website has since been taken down, but the redirection page on the Thai Navy website is still present today:

$ curl -D -
HTTP/1.1 302 Found
Date: Tue, 06 May 2014 08:58:06 GMT
Server: Apache
X-Powered-By: PHP/5.1.6
Content-Length: 0
Connection: close
Content-Type: text/html; charset=TIS-620

All of the hacked Thai Government websites use the second-level domain, which is eligible to be registered only by government entities in Thailand. The .th top-level domain is administered by T.H.NIC Co.,Ltd. (THNIC), which provides its domain registration services under a policy managed by the Thai Network Information Center Foundation, and allows domain names to be purchased through THNIC Authorized Resellers.

.th is also the fourth phishiest top-level domain. Netcraft currently blocks 310 phishing sites under this TLD, which is rather significant given that there are fewer than 100,000 .th sites in total.

Government sites typically confer a greater level of trust than other types of websites can, but in Thailand, many are evidently used to host phishing sites and conduct drive-by malware attacks. Cleaning up these attacks is unlikely to be Thailand's number one priority at the moment — the country has been in a state of paralysis since government elections were obstructed by protesters, and last month, there were concerns that the situation could escalate into civil war.

Chinese government websites ( hosted the second largest number of instances of malware last month, accounting for more than a tenth of all government-hosted malware. Between them, Thailand and China alone hosted 95% of all government-hosted malware during April. For comparison, during the same month, no malware attacks were reported on US or UK government websites (.gov and

SHA-2: Very cryptographic. So secure. Such growth. Wow.

Use of the SHA-2 cryptographic signature algorithm has received a significant boost in the wake of the Heartbleed Bug.

More than half a million SSL certificates were potentially compromised as a result of the Heartbleed vulnerability — affected certificates require urgent re-issuance and revocation. The good news is that many of the new certificates have been signed with the SHA-2 algorithm instead of the less secure SHA-1 algorithm, which has helped the total number of certificates signed with SHA-2 increase by more than 50% over the past month.

Practical attacks against the SHA-1 algorithm are now within reach of government agencies, giving them the opportunity to construct a pair of different SSL certificates with the same SHA-1 digest. Ultimately, this could enable an attacker to impersonate secure websites using a variant of the attack that worked against MD5 in 2008. This attack is, however, made more difficult by path constraints and the inclusion of unpredictable data into the certificate before signing it.

Even before the Heartbleed bug was announced, the migration to SHA-2 was inevitable, if not rapid. The long-term shift to SHA-2 is being fuelled by Microsoft's SHA-1 deprecation policy: Windows will stop accepting certificates signed using SHA-1 from 2017. It is in the interest of certificate authorities to begin the migration as soon as possible, otherwise long-term certificates could become useless partway through their lifetime.

In response to the potential dangers, the National Institute of Standards and Technology (NIST) issued a special publication which disallowed the use of SHA-1 after December 2013. Embarrassingly, NIST ignored its own recommendation and deployed a SHA-1 certificate on its own secure website at in January 2014.

NIST was not alone in being slow to heed its recommendations: more than 92% of all SSL certificates issued in January were signed with SHA-1. However, the number of certificates using SHA-1 has noticeably declined in the past couple of months. This shift has undoubtedly been assisted by the publication of the Heartbleed Bug, prompting website administrators to deploy new SSL certificates long before their existing certificates were due to expire.

Nearly 200,000 valid third-party certificates are now signed with SHA-2. Despite showing impressive growth, certificates signed with SHA-2 account for 6.6% of all valid third-party certificates currently in use on the web; but this is still a significant jump from last month's share of 4.3%, and is likely to continue at a strong rate.

SHA-1 vs. SHA-2 (May 2014)

The latest version of the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates [PDF] states that SHA-1 may still be used in subscriber certificates until SHA-256 (part of the SHA-2 family) is supported by a substantial portion of relying-parties worldwide. Arguably, this time has long passed — even Windows XP, which is no longer supported by Microsoft, has been able to accept certificates signed with SHA-256, SHA-384 and SHA-512 since the release of Service Pack 3 in 2008.

Phishers find Microsoft Azure 30-day trial irresistible!

Fraudsters have taken to Microsoft Azure to deploy phishing sites, taking advantage of Microsoft's free 30-day trial.

Free hosting!

In order to get a phishing site hosted at Azure, the fraudster has several options: steal the credentials for a Microsoft account, compromise a virtual machine running at Azure, or use Microsoft’s free trial which provides $200 of credit. Given the number of subdomains registered explicitly for phishing, it is unlikely that many fraudsters are exploiting legitimate customers’ virtual machines.

Free subdomains!

Microsoft Azure offers free subdomains to users: for its Azure Web Sites service and for Cloud Apps and virtual machines. Almost twice as many phishing sites used rather than, perhaps reflecting the ease-of-use of Azure Web Sites. The remainder of the phishing sites are accessed using their IP addresses or custom domains.

An Apple phishing site on (Site Report).

Many of the subdomains are clearly registered with the intention of phishing; the table below includes some of the most egregious examples targeting well-known institutions.

www22online-americanexpress.azurewebsites.netAmerican Express

Free SSL certificate!

Microsoft Azure Web Sites also offers fraudsters the ability to use an SSL certificate. All subdomains of are automatically accessible via HTTPS using a * SSL certificate. The Apple phishing site featured below includes mixed content, indicating it was probably not designed with SSL in mind despite its subdomain: itune-billing2update-ssl-apple. Phishing sites that make proper use of the wildcard SSL certificate may be able to instil more trust than those that do not.

An SSL certificate on (Site Report).

SSL certificate is irrevocable!

The Baseline Requirements that forms part of Mozilla's CA policy suggests that the SSL certificate must be revoked within 24 hours: "The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: [..] [t]he CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name". However, Microsoft itself issued the SSL certificate from its sub-CA of Verizon Business and has chosen not to revoke it. Moreover, the SSL certificate does not include an OCSP responder URL and is not served with a stapled response (which is also in violation of the Baseline Requirements) and consequently the SSL certificate is irrevocable in some major browsers, particularly Firefox.

Free email addresses!

Fraudsters are also using Microsoft-provided free email addresses (at,, and to receive and store stolen phishing credentials. Fraudsters commonly use phishing kits to quickly deploy phishing sites — before deployment, the fraudster configures the phishing kit with his email address. If a victim is tricked by the phishing site into providing his credentials, they are sent back to the fraudster's email address.

Free anonymising proxy!

One fraudster used Azure to proxy his internet traffic when accessing the phishing site, but was exposed when he used the same email address in the phishing kit as he used on his Facebook profile. The fraudster left the log file that records visits to the phishing site accessible to the public. The first two entries in the log, which preceded all other accesses by several hours, were from Microsoft Azure IP addresses. It is likely these correspond to the fraudster checking his phishing site was ready to be sent out to would-be victims.

1  -  2014-3-27 @ 02:56:03
2  -  2014-3-27 @ 02:57:16
3  109.XXXXXXXXX  -  2014-3-27 @ 11:22:26
4  212.XXXXXXXXX  -  2014-3-27 @ 11:39:47
5  62.XXXXXXXXXXX  -  2014-3-27 @ 11:39:57
6  72.XXXXXXXX  -  2014-3-27 @ 11:40:02
7  64.XXXXXXXXXX  -  2014-3-27 @ 11:40:04
8  37.XXXXXXXXXX  -  2014-3-27 @ 11:40:20
9  194.XXXXXXXXXX  -  2014-3-27 @ 11:47:18
10 194.XXXXXXXXXX  -  2014-3-27 @ 11:47:20
11 89.XXXXXXXXX  -  2014-3-27 @ 11:49:50
12 65.XXXXXXXXXX  -  2014-3-27 @ 11:49:54
13 92.XXXXXXXXX  -  2014-3-27 @ 11:49:56
14 37.XXXXXXXXXX  -  2014-3-27 @ 11:51:20
15 94.XXXXXXXXXX  -  2014-3-27 @ 11:51:24
16 62.XXXXXXXXXXX  -  2014-3-27 @ 11:51:26

The sting

However, Microsoft may yet have a trick up its sleeve: customers must provide a phone number and credit card details in order to register for the trial. Whilst the credit card details could have been stolen in a previous phishing attack, physical access to a phone is required in order to register an account. This may prove to be the fraudsters' downfall — in serious cases, information gathered from the fraudsters mobile phone could be used as evidence subject to the phone company's cooperation and local police involvement.

Netcraft's Domain Registration Risk service can be used to pre-empt fraud by highlighting domains or subdomains that are deceptively similar to legitimate websites run by banks and other institutions that are commonly targeted by fraudsters.

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; 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; 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 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 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 domain, rather than by phone or via the Autotrader website. The affected listings have since been removed from the Autotrader website, but the 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 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 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 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.