World Bank hacked by PayPal phishers

Hackers have broken into a website operated by the World Bank Group, which was subsequently exploited to host a convincing PayPal phishing site. The fraudulent content deployed on the site was able to benefit from the presence of a valid Extended Validation SSL certificate.

Extended Validation certificates can only be issued to organisations that have gone through a stringent set of verification steps, as required by the CA/Browser Forum. To recognise the high level of assurance offered by an EV certificate, most browser software will display the organisation's name in a prominent green box next to the address bar.

A PayPal phishing site, using an Extended Validation SSL certificate issued to the World Bank Group.

A PayPal phishing site, using an Extended Validation SSL certificate issued to the World Bank Group.

The EV vetting process effectively guarantees that the domain used in this attack is operated by the organisation specified in the certificate, which in this case is the World Bank Group. Implicatively, any visitor to this site is likely to trust the content it displays.

But of course, this guarantee goes out the window if the site has been compromised by an attacker. That's exactly what happened on Tuesday, when fraudsters deployed a PayPal phishing site into a directory on, allowing the fraudulent content to be served with an EV certificate issued to The World Bank Group.

The Climate-Smart Planning Platform is an initiative led by The World Bank, which makes it easier for developing-country practitioners to locate and access the tools, data and knowledge they need for climate-smart planning. Given its noble goals, it seems a shame that its website has been affected by this fraudulent activity.

The day after the attack, the website became temporarily unavailable (displaying only a Red Hat Enterprise Linux test page), before later coming back online with the fraudulent content removed. But today, it became evident that the site is still vulnerable to attack, as its homepage has now been defaced by a group called "Virus iraq".

A World Bank Group website hacked by "Virus iraq".

A World Bank Group website hacked by "Virus iraq" (19 November, 2015).

This is not the only time The World Bank's reputation has been tainted by the work of fraudsters – its name is also often used in 419 scams.

Tuesday's phishing attack started off by asking the victim to enter his or her PayPal email address and password. These credentials were submitted to a logcheck.php script on the server, which carried out some validation to prevent bogus data clogging up the phisher's haul.

The phishing site rejects invalid email addresses.

The phishing site rejects invalid email addresses.

After logging these stolen credentials, the phishing site claims it is temporarily unable to load the user's account. The victim is prompted to confirm their "informations" in order to access their account.

The next page asks for several details that would help the fraudster carry out identity theft. These details include the victim's name, date of birth, address and phone number. After these have been submitted, the victim is prompted to confirm payment card details by entering his full card number, expiry date and CSC (CVV) number.

The previous page also has a checkbox to specify whether or not the victim's card uses Verified by Visa or MasterCard SecureCode. If this box is checked, the next page will prompt the user to enter his 3-D Secure password, thus allowing the attacker to make fraudulent purchases on sites that are are protected by these additional layers of security.

Stealing the victim's 3-D Secure password.

Stealing the victim's 3-D Secure password.

After this final password has been stolen, the victim is redirected to the genuine PayPal website, leaving the attacker with the ability to make fraudulent purchases using either the victim's PayPal account or credit card.

At the time of writing, the Climate-Smart Planning Platform website remains defaced, but the phishing content has been removed.

November 2015 Web Server Survey

In the November 2015 survey we received responses from 902,997,800 sites and 5,539,129 web-facing computers. This reflects a monthly gain of 24.7 million sites, and 47,200 computers.

This month's website growth was dominated by Apache, which gained nearly 31 million sites – more than eight times as many as nginx, which had the second largest growth amongst the top three. Helped by a loss of 22 million Microsoft-powered websites, Apache's market share has increased to 37%, with its lead over Microsoft more than doubling to 9.9 percentage points.

This sizeable shift in market shares can be mostly attributed to 17 million websites whose domain names became due for renewal. This caused them to be moved from IIS servers to a set of domain holding pages hosted on Apache servers.

Despite Apache also having the greatest growth in web-facing computers this month, with an increase of 23,405 computers, its market share grew by just 0.03 percentage points. In contrast, nginx's similar growth of 21,004 computers increased its market share by 0.27 percentage points.

The number of web-facing computers using each vendor's software serves as a more stable metric, due in part to the cost of provisioning machines. Conversely, website counts are more prone to large fluctuations, as a single computer can serve countless websites at little incremental cost.

Demonstrating this disconnect, Tengine – an nginx fork developed by Alibaba – made a significant contribution to the overall growth in hostnames despite being used on only 5,100 web-facing computers. While the number of sites using this server grew by nearly 30%, rising to 42 million, the number of active sites using Tengine actually fell by 5%.

nginx continues to increase its presence amongst the top million sites. It now powers an additional 2,708 of the top sites, with Apache, Microsoft and Google each losing out to make room. nginx also showed the largest active sites growth in November, growing by 1.6 million (+6.2%) to reach a total of 27.9 million.

Since the launch of Yunjiasu ("fast cloud") in December 2014, more than 2.5 million sites (and 108,000 active sites) are now being served by a modified version of nginx called yunjiasu-nginx, making it the 10th most commonly used web server software by hostnames. Most of this growth has taken place in the last few months, with the total number of sites using this server growing by more than 5x since August.

Yunjiasu is operated by Chinese search engine giant Baidu, in collaboration with CloudFlare, who are responsible for the similar cloudflare-nginx server that is currently used by more than 5 million sites. Baidu's Yunjiasu offers the same features and functionality as CloudFlare (CDN, DNS, DDoS protection, etc.), but it is optimised for performance and regulatory controls within China.

By combining Baidu's network of 17 mainland China data centers with CloudFlare's 47 data centers outside of China, it is possible to start addressing some of the performance issues that have been dampening the appeal of Chinese hosting companies. For example, the largest hosting company in China, Aliyun, only allows its customers to host websites within China, and although it provides its own CDN service, all of the nodes are also within China. Websites that are hosted in China, and available across the combined CloudFlare/Baidu network, will benefit from much greater availability and faster load times from outside of China. Symmetrically, websites that are hosted outside of China will load faster and become much more available within China.

One of the first customers to be served across Baidu's network was TechCrunch, whose local Chinese edition ( was previously only available about 50% of the time within mainland China. CloudFlare claims that it now achieves nearly 100% availability, with an average page load time of 2.5 seconds rather than 17. CloudFlare customers must explicitly opt in to enjoy the performance benefits of the China network: To overcome technical, economic and regulatory issues, Baidu operates all services within China, while CloudFlare operates all of those outside, and by default, no CloudFlare customer traffic will pass through the China network.

Total number of websites

Web server market share

DeveloperOctober 2015PercentNovember 2015PercentChange
Continue reading

Most Reliable Hosting Company Sites in October 2015

Rank Performance Graph OS Outage
DNS Connect First
1 Inc Linux 0:00:00 0.000 0.255 0.007 0.019 0.019
2 Swishmail FreeBSD 0:00:00 0.000 0.153 0.062 0.123 0.166
3 XILO Communications Ltd. Linux 0:00:00 0.000 0.224 0.063 0.126 0.126
4 Datapipe Linux 0:00:00 0.004 0.156 0.012 0.025 0.032
5 Qube Managed Services Linux 0:00:00 0.004 0.148 0.043 0.088 0.088
6 EveryCity SmartOS 0:00:00 0.004 0.092 0.066 0.133 0.133
7 Anexia Linux 0:00:00 0.004 0.187 0.085 0.171 0.172
8 Hivelocity Hosting Linux 0:00:00 0.004 0.185 0.091 0.181 0.181
9 Bigstep Linux 0:00:00 0.013 0.160 0.060 0.122 0.122
10 Memset Linux 0:00:00 0.013 0.157 0.063 0.160 0.246

See full table

For the third month in a row, GoDaddy has had the most reliable hosting company site. It responded to every availability request made by Netcraft throughout October, with an average connection time of just 7 milliseconds. This is the sixth time this year that GoDaddy has featured in the top ten.

On 29 October, GoDaddy announced a new 'best-in-class' partner offer with AdAgility for customers of its GoDaddy Pro programme. This additional feature allows web designers and developers to take greater control over the advertising content on their sites.

Swishmail has risen to second place for reliability this month. This is now its third appearance in the top ten since January, with the last appearance—in July—placing it tenth. Like GoDaddy, Swishmail responded to all of the availability requests made by Netcraft throughout October; however, the average connection time sat higher at 62 milliseconds.

XILO Communications Ltd. saw a return to the top three most reliable hosting companies this month for the first time since January. Like GoDaddy and Swishmail, 100% of the availability requests made by Netcraft received a response. With an average connection time of 63 milliseconds, this makes it the eighth time this year that XILO Communications Ltd. has made it into the top ten.

Yet again, the table this month is dominated by Linux, which is used by eight of the top ten sites. EveryCity uses the SmartOS community fork of OpenSolaris, while Swishmail uses the FreeBSD operating system. This is now the fourth month in a row where Microsoft Windows has been completely absent from the top ten.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

Nigerian government serving up fresh phish

The Financial Reporting Council of Nigeria is currently serving a webmail phishing site from its own government domain.

The phishing content is based on a ready-to-go phishing kit that is distributed as a zip file. It contains easily-customisable PHP scripts and images designed to trick victims into surrendering either their Yahoo, Gmail, Hotmail or AOL passwords.

Gmail phishing content served from a Nigerian government website.

Gmail phishing content served from a Nigerian government website.

In this case, the kit has been deployed within an images directory on a Nigerian government website at, which suggests that the site may have been compromised by a remote attacker. The same phishing kit has also been used to deploy phishing sites on several other websites over the past nine months.

After a victim enters his or her email credentials into the phishing site, both the username and password are transmitted via email directly to the fraudster. These emails also contain the victim's IP address, and a third-party web service is used to deduce which country the victim is in.

After stealing the victim's email credentials, the phishing site inexplicably redirects the browser to the Saatchi Art investment website at This does not appear to be in any way connected to the fraudulent activity.

One of the PHP scripts found within the phishing kit.

One of the PHP scripts found within the phishing kit.

Unlike conventional phishing attacks against banks, attacks that aim to harvest email credentials typically have no immediate financial return; but access to a single victim's email account can often facilitate unauthorised access to several other accounts. With minimal effort, the fraudster can easily discover which websites the victim uses, and then submit password reset requests to those websites. As a bonus, the compromised email account can also be abused to send phishing emails to additional victims, as well as providing a source of valid email addresses.

The majority of Nigeria's government websites, including the one operated by the Financial Reporting Council, are hosted in the United States. It is not apparent how the phishing content has ended up on, although one possible route of compromise could be the unsupported Joomla! CMS software installed on the server. It is still using Joomla! 2.5.28, which reached End of Life status at the end of 2014, meaning that it no longer receives security updates or bug fixes.

However, the Joomla! Security Centre does not document any publicly-known vulnerabilities that affect version 2.5.28. Nonetheless, the use of unsupported software on a public-facing website often catches the attention of hackers, as it is generally indicative of poor security practices elsewhere, and thus attracts further scrutiny. Unless the server was compromised via an undocumented 0-day vulnerability in Joomla!, it may well have been compromised via a different route.

U.S. military cyber security fails to make the grade

The United States Department of Defense is still issuing SHA-1 signed certificates for use by military agencies, despite this practice being banned by NIST for security reasons nearly two years ago. These certificates are used to protect sensitive communication across the public internet, keeping the transmitted information secret from eavesdroppers and impersonators. The security level provided by these DoD certificates is now below the standard Google considers acceptable for consumer use on the web.

The Missile Defense Agency, the eventual successor to the "Star Wars" programme, uses one of these SHA-1 certificates on a Juniper Networks remote access device. The SHA-1 certificate was issued by the Department of Defense in February 2015, long after NIST declared this practice to be unacceptable.

The Missile Defense Agency operates a remote access service which uses a SHA-1 signed certificate, making it vulnerable to impersonation and man-in-the-middle attacks.

The Missile Defense Agency operates a remote access service which uses a SHA-1 signed certificate issued earlier this year. This makes the site vulnerable to impersonation and man-in-the-middle attacks that would facilitate unauthorised access to data.

The National Institute of Standards & Technology (NIST) is charged with "developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets", though its requirements "shall not apply to national security systems". Whilst these Department of Defense systems may or may not be considered national security systems, it is difficult to see why they would be subject to requirements any less stringent than those recommended by NIST.

The SHA-1 algorithm was first published in 1995 and is no longer considered secure. NIST's decision to disallow SHA-1 signature generation after 2013 was originally due to concerns surrounding the cryptographic strength of the algorithm. Back then, it was thought quite likely that future advancements in computing technology and the discovery of new attacks would allow attackers to find SHA-1 hash collisions, and thus be able to impersonate any secure website with a seemingly valid SSL certificate. This prediction appears to have come true, with the latest research suggesting that the cost of using cloud computing resources to find a SHA-1 hash collision is now in the region of $75k, or perhaps even only a week's use of the largest botnets.

The majority of SHA-1 signed SSL certificates issued for use on publicly-accessible websites within the past few months, and that are valid beyond the start of 2017, were issued to hostnames under the .mil sponsored top-level domain. This sTLD is used by agencies, services and divisions of the United States Department of Defense.

A U.S. Navy .mil website, which uses a SHA-1 signed certificate issued earlier this year.

A U.S. Navy .mil website, which also uses a SHA-1 signed certificate issued earlier this year.

Many other SHA-1 certificates used by .mil websites are valid beyond the start of 2017, which means that Google Chrome already regards them as affirmatively insecure, crossing out the padlock icon:


The security of some of these sites is further undermined by their use of TLS 1.0 connections, even though most users' browsers are likely to support later versions. TLS 1.0 is now considered weak and obsolete, with some standards bodies such as the PCI SSC mandating that it should no longer be used in new applications, and that existing applications must migrate to TLS 1.1 or later by June 2016.

Obsolete TLS 1.0 connection used by a military remote access service.

Obsolete TLS 1.0 connection used by a military remote access service.

But disabling support for TLS 1.0 is not always feasible, particularly as some older browsers such as Internet Explorer 8 do not support TLS 1.1 and 1.2. If it is essential for a server to retain support for TLS 1.0 (in addition to later versions), then TLS Fallback SCSV must be used to prevent downgrade attacks against clients that support TLS 1.1 or later. This will ensure that modern browsers will always use acceptably secure versions of TLS, while only the older clients can possibly use the weak, obsolete TLS 1.0 cipher suites.

Several other U.S. military remote access services only support the obsolete TLS 1.0 protocol, including two used by the Defense Logistics Agency. Some other military sites, including one of the Navy's VPN services do support TLS 1.2, but with obsolete cipher suites. These particular sites all use SHA-1 signed certificates that do not expire until 2017, and so are regarded as "affirmatively insecure" by Chrome.

DoD PKI infrastructure

The Department of Defence PKI infrastructure relies on two root certificate authorities (DoD Root CA 2 and DoD Root CA 3), but these are not included in all browsers by default.

Windows and Linux users must explicitly install the DoD root certificates in order for the subscriber certificates to be validated and trusted by their browsers. But interestingly, the DoD roots are trusted on Apple platforms by default; this means that the DoD has the necessary third-party attestation for inclusion in the Apple Root Certificate Program, even though many of the subscriber certificates fail to conform to the Baseline Requirements for the issuance and management of publicly-trusted certificates.

The U.S. Government has faced numerous hurdles in being recognised as a publicly-trusted certificate authority. In 2009, the Federal Public Key Infrastructure Management Authority (US FPKI) requested for its Federal Common Policy Framework Certificate Authority (Common Policy CA) root certificate to be added to Firefox and other Mozilla products. Only subscriber certificates for .gov and .mil domains would have been trusted under this root, but the request was eventually put On Hold in May 2015. It was decided that US FPKI should be treated as a Super-CA, whose subordinate CAs must apply for inclusions themselves.

One of the arguments for accepting the US government as a publicly-trusted certificate authority was that it would avoid the need to purchase commercial certificates and thus save taxpayer dollars. One viable alternative might have been to use the free Let's Encrypt certificate authority, which became trusted by all major browsers this week. However, the cross-signed Let's Encrypt Authority X1 intermediate certificate uses the X509v3 Name Constraints field to explicitly disallow its use by .mil domains. No other top-level domains are precluded from using Let's Encrypt.

Many .mil sites recommend using the InstallRoot tool to simplify the installation and management of the DoD root certificates on Windows machines. This tool also installs several intermediate certificates, which the Department of Defense uses to directly sign the subscriber certificates.


As an example, the subscriber certificate issued to was signed on 19 March 2015 by the DOD CA-27 intermediate, which is signed by the DoD Root CA 2 trusted root. This chain of trust allows the browser to verify that is a legitimate site operated by a Department of Defense agency, and that the connection is not being subjected to a man-in-the-middle attack.


These intermediate certificates are also signed with the arguably weak SHA-1 algorithm. Whilst not the most likely way in which SHA-1 will initially fail — a chosen-prefix attack such as the one used on MD5 in the Flame malware is more likely — if any of these intermediate certificates were to be targeted to find a collision, it would be possible for an attacker to generate valid subscriber certificates for any domain. This would allow the attacker to convincingly impersonate U.S. military sites and carry out man-in-the-middle attacks against browsers that trust the DoD root certificates.

The DOD CA-27 intermediate certificate that was used to issue the subscriber certificate for is valid until September 2017 and has a SHA-1 signature.

The DOD CA-27 intermediate certificate that was used to issue the subscriber certificate for is valid until September 2017 and has a SHA-1 signature.

Chrome also warns users when intermediate certificates are signed with SHA-1.

Chrome also warns users when intermediate certificates are signed with SHA-1.

Although the DoD PKI infrastructure is not trusted by all browsers, it is nonetheless surprising to see it flouting some of the well-founded rules and recommendations that apply to publicly trusted certificates as well as recommendations made by NIST. Many of these guidelines are backed by valid security concerns – in particular, using SHA-1 for signature generation is now considered ill-advised, as any well-funded attacker can plausibly compromise the affected certificates.

The risk to the Department of Defense is further heightened by enemy goverments being the most likely sources of attack. The projected cost of attacking SHA-1 is unlikely to be prohibitive, and some governments may already be in a position to find a hash collision faster than the most organised criminals.

One million SSL certificates still using “insecure” SHA-1 algorithm

Nearly a million SSL certificates found in Netcraft's October SSL Survey were signed with the potentially vulnerable SHA-1 hashing algorithm, and some certificate authorities are continuing to issue more. Google Chrome already regards these certificates as insecure, resulting in more warning signals than if the sites had been served over a completely unencrypted HTTP connection.

The latest research, dubbed the SHAppening, shows that these warnings are well founded, projecting that a full SHA-1 collision could be found within 49-78 days on a 512-GPU cluster. Renting the equivalent processing time on Amazon's EC2 cloud computing service would cost only $75k-$120k, which is an order of magnitude less than earlier estimates. The researchers point out that this represents an important alarm signal, and that the industry's plans to move away from SHA-1 by 2017 might not be fast enough.

The researchers consider that is now feasible [pdf] for a well funded attacker to impersonate an SSL site that uses a publicly trusted SHA-1 certificate. Worse still, while browsers still accept SHA-1 signatures, SSL sites remain at risk even after migrating to SHA-2: if an attacker were to compromise an intermediate CA certificate signed with SHA-1, he could generate valid certificates for arbitrary domains.

The SHA-2 and SHA-3 family of cryptographic hash algorithms are now the only ones approved by the National Institute of Standards and Technology (NIST) for digital signature generation. Although the SHA-2 family includes SHA-224, only the stronger SHA-256, SHA-384 and SHA-512 algorithms are allowed by the CA/Browser Forum's Baseline Requirements for the issuance and management of publicly-trusted certificates.

These newer algorithms do not exhibit the mathematical weaknesses of SHA-1, and also generate longer digests than the 160-bits computed by SHA-1. Almost all new SHA-2 subscriber certificates use SHA-256 (99.99%), while only a handful use SHA-384 and SHA-512. Most of the latter are issued by DigiCert.

The rise of SHA-2

Migration to SHA-2 slowly gathered pace when the National Institute of Standards and Technology (NIST) banned the use of SHA-1 for new signature generation after the end of December 2013, but the rate of growth increased in the wake of the 2014 HeartBleed bug. This bug resulted in around half a million certificates being potentially compromised, requiring urgent reissuance and revocation. By this time, many certificate authorities were already using SHA-256 for new certificates, which in turn caused a significant boost in the number of SHA-2 certificates in use on the web.

SHA-1 vs SHA-2 (source: Netcraft SSL Survey October 2015)

SHA-1 vs SHA-2 (source: Netcraft SSL Survey October 2015)

SHA-2 eventually overtook SHA-1 in May 2015, but there are still nearly a million certificates currently using SHA-1.

The use of SHA-1 in new certificates is expected to halt by the close of this year, as from 2016, the CA/Browser Forum Baseline Requirements will forbid the issuance of any new subscriber certificates or subordinate certificates that use the SHA-1 algorithm.

However, with less than three months to go, Symantec proposed a motion (endorsed by Entrust, Microsoft and Trend Micro) to allow the issuance of SHA-1 signed certificates throughout 2016. The proposed changes to the Baseline Requirements would have catered for "a very small number of very large enterprise customers" who are unable to migrate to SHA-2 before the end of this year. But with the new cost projections making the risk of a real-world attack higher than previously believed, Symantec and the endorsers subsequently withdrew the ballot on 12 October.

Even if this ballot were accepted, many certificate authorities have already decided to avoid using SHA-1 because of the way some browsers will treat these certificates. For example, if an existing SHA-1 certificate is due to expire during 2016, Google Chrome currently flags this up as a weak security configuration and warns the user that their connection may not be private. Certificates that are valid until 2017 or later are treated as affirmatively insecure, with the "https" protocol crossed out.

Weak and insecure certificates

Despite being regarded as weak or insecure by one of the most commonly used browsers, over 120,000 of the SHA-1 certificates currently in use on the web were issued during 2015, and 3,900 of these have expiry dates beyond the start of 2017. The owners of these certificates will undoubtedly need to replace them months — or in some cases, years — before they are due to expire.

For example, Deloitte is still using a SHA-1 signed certificate that was issued in February 2015 and valid until 2020. Google Chrome already regards this certificate as insecure:


This SHA-1 certificate was issued by A-Trust Gesellschaft für Sicherheitssysteme im elektronischen Datenverkehr GmbH, who operate the A-Trust-nQual-03 root certificate that is trusted by all mainstream browsers.

In February 2014, when Netcraft first published a look at SHA-2 migration, more than 256,000 SHA-1 signed certificates would have been valid beyond the start of 2017. Despite the browser vendors' deprecation plans, this total is roughly the same today.

Buggy browsers treating some SHA-2 certificates as insecure

Some certificate authorities were hit by an unexpected pitfall after migrating to SHA-2, after failing to use new names for their SHA-2 signed intermediate certificates. SSLMate, an SSL certificate vendor, published two examples of how Google Chrome could erroneously suggest that a site was affirmatively insecure for serving a SHA-1 certificate, even when the full certificate chain actually used the SHA-2 hashing algorithm. This undesirable behaviour was caused by caching in the cryptographic libraries used by Chrome (CryptoAPI on Windows, and NSS on Linux).

When a CA migrates to SHA-2, it can either reuse an existing intermediate certificate by re-signing the existing public key with SHA-2, or it can generate a new one with a new public key and subject name. If the existing certificate is reused, some Windows browsers will end up ignoring the chain provided by the server and instead use the old SHA-1 intermediate certificate if it has been cached previously. This will cause Chrome to believe that the connection to the site is affirmatively insecure.

SSLMate observed that StartCom was still issuing SHA-2 certificates that were signed by a SHA-1 intermediate, despite CA/Browser Forum Ballot 118 stating that CAs should not do this. Netcraft's SSL Survey also shows the same mistakes being made by other certificate authorities, including WoSign, Entrust and Unizeto amongst others. All of these certificates may be regarded as insecure by the Chrome browser.

The second example involved a bug in older versions of NSS on Linux, which could cause Chrome to use a cross-signed root even if a shorter and newer chain exists. If the cached cross-signed certificate uses SHA-1, Chrome will consider the chain to be weak, even though the server may have sent a chain that used SHA-2 throughout.