GCHQ website falls after threats from Anonymous

GCHQ's website at www.gchq.gov.uk is exhibiting some noticeable performance issues today, suggesting that it could be suffering from a denial of service attack.

Last week, documents from whistle-blower Edward Snowden revealed that GCHQ carried out denial of service (DoS) attacks against communications systems used by the hacktivist group Anonymous during their own Operation Payback, which itself involved carrying out denial of service attacks against high profile websites such as MasterCard, Visa, Amazon, Moneybookers, and PostFinance.

This caused some furore amongst supporters of Operation Payback, some of whom were tried and convicted for carrying out denial of service attacks. Denial of service attacks are illegal in the UK under the Police and Justice Act 2006, yet the leaked slides suggest that GCHQ may have used such techniques against Anonymous, resulting in 80% of IRC users leaving within a month.


Part of a statement published by Anonymous on AnonNews.

Following these revelations, a statement on GCHQ's war against Anonymous was posted on the AnonNews website. The statement ends with a suggestion that some kind of retaliation could be expected: "Now that we truly know who it was who attacked us, Expect all of us."

Twitter accounts associated with Anonymous also fuelled suggestions that they could be responsible for GCHQ's website woes, with some referring to the #TheDayWeFightBack hashtag.

Curiously, a much larger amount of downtime has been observed from Netcraft's Romanian performance monitor since the leaked slides were made public. That could indicate much more extreme DDoS mitigation techniques are being applied to these requests, and this in turn suggests that if an attack is occurring, perhaps Romania is one of the countries from which the attacks are being launched.

The www.gchq.gov.uk website is served from a content delivery network run by Limelight Networks, who claim to be one of the world's largest, best performing, and most highly available content delivery networks. Although it remains hosted at the same location, the website changed its Server header from "WebServer" to "EdgePrism/4.1.2.0" earlier this week. Limelight Networks first unveiled EdgePrism in 2001, so any similarities to the name of the NSA's PRISM mass electronic surveillance program are presumably coincidental.

Are there really lots of vulnerable Apache web servers?

Apache has been the most common web server on the internet since April 1996, and is currently used by 38% of all websites. Most nefarious activity takes place on compromised servers, but just how many of these Apache servers are actually vulnerable?

The latest major release of the 2.4 stable branch is Apache 2.4.7, which was released in November 2013. However, very few websites claim to be using the stable branch of 2.4 releases, despite Apache encouraging users to upgrade from 2.2 and earlier versions.

Less than 1% of all Apache-powered websites feature an Apache/2.4.x server header, although amongst the top million websites, more than twice as many sites claim to be using Apache 2.4.x. Some of the busiest websites using the latest version of Apache (2.4.7) are associated with the Apache Software Foundation and run on the FreeBSD operating system, including httpd.apache.org, www.openoffice.org, wiki.apache.org, tomcat.apache.org and mail-archives.apache.org.

The most recent security vulnerabilities affecting Apache were addressed in version 2.4.5, which included fixes for the vulnerabilities described in CVE-2013-1896 and CVE-2013-2249. Depending which Apache modules are installed, and how they are used, earlier versions may be vulnerable to unauthorised disclosure of information and disruption of service. The previous release in the 2.4 branch (2.4.4), also addressed several cross-site scripting (XSS) vulnerabilities in various modules; such vulnerabilities can severely compromise a web application by facilitating remote session hijacking and the theft of user credentials. Nonetheless, millions of websites still appear to be using vulnerable versions of Apache, including versions which are no longer supported.


Top 15 versions of Apache in February 2014, where the full version string is announced in the Server HTTP response header.
Note that no versions of the Apache 2.4 branch appear within the top 15.
Apache 1.3.41 and 2.0.63 are both end-of-lined.

The Apache 2.0 branch was retired in July 2013 with the conclusive release of Apache 2.0.65. This release addressed a few security vulnerabilities, but no subsequent vulnerabilities will be addressed by official patches or subsequent releases in the 2.0 branch. Anyone still using this branch of releases should strongly consider updating to the latest version in the stable 2.4 or legacy 2.2 branches.

Nevertheless, 6.5 million websites claim to be using the end of life 2.0 branch of Apache, with the most common versions being 2.0.63 and 2.0.52. Only 12k sites are running the conclusive release of this branch (2.0.65). However, it is worth noting that just over half of all Apache-powered websites hide their version numbers, so it is not always possible to accurately determine which version is installed without carrying out additional tests. Hiding software version numbers is usually a deliberate act by a server administrator – Apache 2.4.7 will reveal its full version number by default when installed on Arch Linux, and installing the apache2 package on the latest version of Ubuntu Linux will also reveal "Apache 2.4.6 (Ubuntu)" as the default Server banner.

Due to hidden version numbers, the number of sites openly reporting to be running Apache 2.4.x could be regarded as a lower bound, but conversely, exhibiting a vulnerable version number does not necessarily mean that a server can be exploited by a remote attacker.

For example, the Red Hat Linux operating system uses a backporting approach to applying security fixes, which means that a vulnerability in Apache 2.2.3 can be patched without affecting the apparent version number of the software. From an external point of view, the server will still appear to be running Apache 2.2.3, but it might not be vulnerable to any security problems that would affect a fresh installation of Apache 2.2.3.

Red Hat 5 and 6 use Apache 2.2.3 and 2.2.15 respectively, which explains why these seemingly old versions remain so prominent today (2.2.3 was originally release in July 2006). Both are still supported by Red Hat, and providing the necessary backported patches have been applied, Red Hat Apache servers which exhibit these version numbers can be just as secure as the latest release of Apache. However, because the version numbers correspond to Apache versions which were released several years ago, it is not unusual for Red Hat powered websites to attract unfair criticism for appearing to run insecure versions of Apache.

Certain Apache vulnerabilities can also be eliminated by removing or simply not using the affected modules – a configuration which is also difficult to ascertain remotely. However, exhibiting an apparently-vulnerable version number can still have its downsides, even if there are no vulnerabilities to exploit – as well as attracting unwarranted criticism from observers who falsely believe that the server is insecure, it could also attract undesirable scrutiny from hackers who might stumble upon different vulnerabilities instead. These are both common reasons why server administrators sometimes opt to hide version information from a web server's headers. Sites which do this include wikipedia.org, www.bbc.co.uk, www.nytimes.com and www.paypal.com, all of which claim to be running Apache, but do not directly reveal which version.

A further 6.0 million websites are still using Apache 1.3.x, even though the final version in this branch was released four years ago. The release of Apache 1.3.42 in February 2010 marked the end of life for the 1.3 branch, although 2.4 million sites are still using the previous version, (1.3.41), which contains a denial of service and remote code execution vulnerability in in its mod_proxy module.

The busiest site still using Apache 1.3 is Weather Underground, which uses Apache 1.3.42. This currently has a Netcraft site rank of 177, which makes it even more popular than the busiest Apache 2.0.x website. It is served from a device which exhibits the characteristics of a Citrix NetScaler application delivery controller. Weather Underground also uses Apache 1.3.42 for the mobile version of its site at m.wund.com.

Amongst the million busiest websites, Linux is by far the most common operating system used to run Apache web server software. With near-ubiquitous support for PHP, such platforms make tempting targets for fraudsters. Most of the phishing sites analysed by Netcraft rely on PHP to process the content of web forms and send emails.

The Audited by Netcraft service provides a means of regularly testing internet infrastructure for similarly vulnerable web server software, faulty configurations, weak encryption and other issues which would fail to meet the PCI DSS standard. Netcraft's heuristic fingerprinting techniques can often use the behaviour of a web server to identify which version of Apache is installed, even if the server does not directly state which version is being used. These automated scans can be run as frequently as every day, and can be augmented by Netcraft's Web Application Security Testing service, which provides a much deeper manual analysis of a web application by an experienced security professional.

NIST continues using SHA-1 algorithm after banning it

The National Institute of Standards and Technology (NIST) is still using SSL certificates signed with the SHA-1 signature algorithm, despite issuing a Special Publication disallowing the use of this algorithm for digital signature generation after 2013.

"SHA-1 shall not be used for digital signature generation after December 31, 2013."
— NIST recommendation

The SSL certificate for www.nist.gov is signed using the SHA-1 hashing algorithm, and was issued by VeriSign on 23 January 2014, more than three weeks after NIST's own ban came into effect. Also issued this year, NIST's "Secure File Transfer Service" at xnfiles.nist.gov uses a SHA-1 certificate.

An attacker able to find SHA-1 collisions could carefully construct a pair of certificates with colliding SHA-1 hashes: one a conventional certificate to be signed by a trusted CA, the other a sub-CA certificate able to be used to sign arbitrary SSL certificates. By substituting the signature from the CA-signed certificate into the sub-CA certificate, certificate chains containing the attacker-controlled sub-CA certificate will pass browser verification checks. This attack is, however, made more difficult by path constraints and the inclusion of unpredictable data into the certificate before signing it.

The increasing practicality of finding SHA-1 hash collisions could make it possible for a well-funded attacker to impersonate any HTTPS website. With a practical attack against SHA-1 (using cloud computing resources) estimated to cost $2.77M in 2012, falling to $700k by 2015, it may attract government agencies.

The SSL certificate for www.nist.gov with the signature algorithm and issuance date highlighted.

Along with NIST itself, many US Government institutions have continued to generate new SSL certificates with SHA-1 signatures. Examples include the certificate for donogc.navy.mil, issued on 3 January 2014, and several United States Bankruptcy Court document filing systems (each state has its own site and uses its own SHA-1-signed SSL certificate). Despite receiving widespread criticism for a number of other security problems last year, the ObamaCare exchange at healthcare.gov also saw fit to deploy a new SSL certificate in January which uses the SHA-1 hashing algorithm.

NIST and the rest of the US government are far from alone, however, as more than 92% of all certificates issued this year use the SHA-1 hashing algorithm.

Although the recommendations from the National Institute of Standards and Technology have been prepared for US federal agencies, the cryptographic weaknesses of SHA-1 should concern anyone who relies on SHA-1 to generate or validate digital signatures. Microsoft shares these concerns and has announced plans to deprecate the use of SHA-1 in both SSL and code signing certificates by the end of 2016.

The NSA-designed SHA-2 family (which includes SHA-224, SHA-256, SHA-384 and SHA-512) now provides the only cryptographic hash functions approved by NIST for digital signature generation. Whilst SHA-2 shares some similarities with SHA-1, there are significant structural differences: SHA-2 does not share the SHA-1's mathematical weakness. All of the SHA-2 algorithms have much longer digests: SHA-1 only produces a 160-bit digest, whereas the most common digest length for SHA-2 is 256-bits.


Huge divide: SHA-256 uptake remains low, and is still only used by a handful of certificate authorities.
Other signature algorithms with negligible shares (e.g. MD5 and SHA-512) are not displayed.

In total, more than 98% of all SSL certificates in use on the Web are still using SHA-1 signatures. Netcraft's February 2014 SSL Survey found more than 256,000 of these certificates would otherwise be valid beyond the start of 2017 and, due to the planned deprecation of SHA-1, will need to be replaced before their natural expiry dates.

SHA-256 is the most commonly used signature algorithm from the SHA-2 family, but it is used by only 1.86% of the valid certificates in Netcraft's February 2014 SSL Survey; nonetheless, this share has more than doubled in the space of 4 months, suggesting that some certificate authorities are starting to take the issue seriously. So far in 2014, more than 61% of the new certificates signed with SHA-256 were issued by a single certificate authority, Go Daddy. SHA-512 is the only other SHA-2 family algorithm to be seen used in SSL certificates, albeit deployed on only 4 websites so far.

The CA/B Forum – which comprises of both certificate authorities and web browser vendors – put forward Ballot 111 last year, which motions to take advantage of the deprecation of SHA-1 by accelerating the forum's planned move to shorter maximum certificate lifetimes. The deprecation alone will mean that some five-year certificates that are valid today will not be usable for their entire lifetime.

In practice, it is likely to be Microsoft's plans to deprecate the use of SHA-1 signatures by the end of 2016 which will force the mass adoption of SHA-2 by certificate authorities, although allowing three years for this to happen might seem generous. The majority of end users are unlikely to be affected by the change, and most website administrators will probably have to renew their SSL certificates within this period anyway, but certificates which are reissued with SHA-1 signatures run the risk of being unsupported by other browsers in the future.

Cryptographic weaknesses in SHA-1 have been discussed for several years. A notable better-than-brute-force attack was announced nine years ago, demonstrating a SHA-1 hash collision that could be achieved within 269 calculations, as opposed to the 280 that would be required by a brute-force approach.

More recently, the best public cryptanalysis of SHA-1 estimated that a full collision can be achieved with a complexity of around 261, while a near-collision can be achieved in 257.5. These attacks have been implemented in the HashClash framework, which provides differential path construction attacks against SHA-1, as well as chosen prefix collisions against the even-weaker MD5 algorithm. The CA/B Forum recommends that all certificate serial numbers should exhibit at least 20 bits of entropy, which would mitigate chosen-prefix collision attacks for non collision resistant hash functions, although such measures are not thought to be necessary for SHA-2 at the current time.

Windows XP has supported SHA-256, SHA-384 and SHA-512 since the release of Service Pack 3 in 2008, and Windows Server 2003 can also support SHA-2 if the KB938397 hotfix has been installed. Deprecating SHA-1 could therefore also have some other indirect security benefits: anyone still using Windows XP before Service Pack 3 will be unable to make effective use of the web as SHA-2 certificates gain prominence.

The SHA-1 algorithm is also used in all versions of the TLS cryptographic protocol, and only the latest version (TLS 1.2) introduces SHA-256 as a replacement for the MD5/SHA-1 combination for both the pseudorandom function and the finished message hash. Microsoft's SHA-1 deprecation policy will only apply to applications which call the CertGetCertificateChain API to build and validate a certificate chain, so older browsers and hardware devices which do not yet support TLS 1.2 will be unaffected.

Update 5 Feb 2014: Following the publication of this article, NIST today replaced the SHA-1 certificate on www.nist.gov with a new one which uses SHA-256 as a signature algorithm. At the time of writing, the certificate used by xnfiles.nist.gov is still signed with SHA-1.

Incentives for Phishing Site Reporters

As of the 1st November 2013, the Netcraft Anti-Phishing community has helped to block over 6.9 million phishing attacks worldwide. We incentivise phishing reports from the community, and have now added a Netcraft USB Flash Drive to our list of incentives:

Prize When
Netcraft USB Flash Drive after 100 validated phishing reports
Netcraft Mug after 250
Netcraft Polo Shirt after 500
Targus Laptop Backpack after 1,000
iPad after 5,000

On reaching 5,000 validated reports you become eligible for a monthly competition to incentivise large reporters.

To report phishing sites to us, please use the form at http://toolbar.netcraft.com/report_url, or forward any phishing URLs or emails you receive to scam@netcraft.com.

The Netcraft Extension, which is available for Firefox, Google Chrome™ and Opera, serves as a giant neighbourhood watch scheme for the Internet. Members who encounter a phishing site can act to defend the larger community of users against the attack. Once the first recipients of a phishing mail have reported the attack URL, it is blocked for community members as they subsequently access the URL. Widely disseminated attacks simply mean that the phishing attack will be reported and blocked sooner.

Anti-Phishing Chrome Extension Netcraft Toolbar for Firefox Netcraft Toolbar for Opera

PHP.net blocked by Google: False positive or not?

Rasmus Lerdorf – the creator of PHP – is currently trying to get Google to stop blocking the whole php.net website after it was suspected of containing malware. In a tweet earlier this morning, Rasmus posted a screenshot and suggested that the block was caused by a false positive:

Google's Webmaster Tools flag the inclusion of the script at http://static.php.net/www.php.net/userprefs.js as suspicious, although this file currently appears benign. However, Google's Safe Browsing diagnostics for php.net do suggest that malware has been present on the site in the last 90 days:

"Of the 1513 pages we tested on the site over the past 90 days, 4 page(s) resulted in malicious software being downloaded and installed without user consent."

The block was added to add chunk 127721 in the Google Safe Browsing goog-malware-shavar list. At the time of writing, php.net is still blocked in Firefox and Chrome, both of which make use of Google's blocklist. Visiting php.net from a Google search results page or the bitly URL shortener causes an interstitial warning page to be displayed.

A seemingly benign, yet obfuscated, JavaScript file called functions.js was removed from the PHP website repository this morning. The developer behind this change speculated that the file "Could be the reason why Google is blocking us today.."

However, a short moment ago, a Hacker News user posted some obfuscated JavaScript that was found appended to a possibly cached version of the userprefs.js script, suggesting that the PHP.net website may have been compromised recently. The obfuscated JavaScript inserts an iframe into the webpage, which loads content from an external site known for distributing malware. Google Chrome blocks the inclusion of any content from known malware domains, although the injected content in this case no longer appears to be accessible.


Using Firebug to display the injection point of the iframe (iframe has been moved to a visible location)

Update [Monday 28th October]: The administrators of PHP.net have since confirmed that two web servers were compromised and at least one was serving malware. The affected servers have been taken offline and the SSL certificate in use has been revoked by Comodo. The PHP source packages and code repository were reportedly not compromised.

US Government aiding spying… against itself

Partly as a consequence of the US Government shutdown, there are presently more than two hundred .gov websites using expired SSL certificates. Although the shutdown is expected to be a short term measure, the widespread use of expired certificates on .gov sites may cause long term harm. The US Government is effectively training its citizens and employees to click through SSL warnings, and once the users of a website treat SSL error messages as normal, attackers may be able to perform otherwise difficult man-in-the-middle attacks.

The situation is exacerbated by the behaviour of some mainstream browsers which do not faithfully warn the user of the most serious problem in scenarios where two or more errors are present.

An SSL error message presented on EV-enabled www.usaspending.gov in Google Chrome.

When an SSL error occurs, some browsers only display a single error message, sometimes not the most serious, or even a generic error message for all types of SSL error. An attacker can exploit this vulnerable browser behaviour on SSL sites with expired certificates to perform an almost seamless man-in-the-middle attack. By signing his own expired SSL certificate for a US government website, the SSL error message displayed for the attacker's SSL certificate is indistinguishable (in some browsers) from the error message produced by the real SSL certificate belonging to the US Government. Citizens accustomed to seeing the "expired" error message will happily proceed with a connection using the attacker's expired (and untrusted) certificate, unwittingly communicating with the attacker instead of the US Government.

By testing an expired certificate signed by an expired untrusted issuer, Netcraft found that whilst some browsers are vulnerable, Internet Explorer is not as it correctly displays both error messages. Google Chrome on Windows and OS X displays the more serious error message but does not display a warning about the expiry. All other tested browsers displayed either a generic error message or did not mention that the issuing CA is not widely trusted. Generic error messages are dangerous if they hide the severity of the SSL error from the user: a change in the type of the SSL error (from expiry to an untrusted issuer) will not be noticed. The tested website contained in the screenshots below is not on a .gov domain, but demonstrates browser behaviour with an untrusted and expired CA certificate with an expired end-entity certificate.

Google Chrome displaying an error message for an expired SSL certificate issued by an untrusted CA. From left to right: Windows, Mac OS X, Linux, and Android.

Google Chrome's behaviour is not consistent across its supported platforms: on Windows and Mac OS X it displays the most serious SSL error message, namely that an untrusted issuer has signed this SSL certificate. On Linux and Android, however, Google Chrome displays an error message about the expired certificate and does not mention the untrusted issuer. By reading the error message and accepting the risks of trusting an expired certificate, a user may unwittingly trust an SSL certificate that was not issued by a widely trusted CA.

Internet Explorer and Opera displaying an error message for an expired SSL certificate issued by an untrusted CA.

On Windows, Internet Explorer correctly presented both applicable error messages. Opera presented the more serious error message though only after viewing an additional dialogue box. Once a user is accustomed to accepting Opera's generic error message, any other type of SSL error on the same website is unlikely to be noticed. Internet Explorer, Google Chrome, and Opera all use Microsoft's CryptoAPI on the Windows platform which may explain their similar behaviour.

Firefox displaying an error message for an expired SSL certificate issued by an untrusted CA.

Firefox, which displays a generic error message for most SSL errors, has further information hidden by default. For an expired certificate issued by an untrusted and expired CA, Firefox's error message refers only to expired certificates (both the CA and end-entity certificates) and does not make any mention of the issuer not being a widely-trusted CA. Hidden details mean that a user having seen the same error message on the .gov website may not notice a change in the category of the SSL error message.

Safari (on OS X and iOS) displaying an error message for an expired SSL certificate issued by an untrusted CA.

Safari on OS X, like both Firefox and Opera displays a generic error message. If the message is expanded, Safari displays an error message based on the expired certificate and will also highlight the lack of trust in the issuer. Safari on iOS 7 displays a generic error message, "Not trusted", for many types of SSL certificate error — it is difficult to tell what is wrong with the SSL certificate without examining the certificate in detail.

Even without the "training" from the US Government, the click-through rate of different SSL messages has been demonstrated to be very high. For Firefox, which doesn't display full error messages by default, Akhawe and Porter Felt found SSL error messages were bypassed in 85% of cases: 87% for untrusted issuer messages and 81% for expired certificate errors. Paradoxically, in Google Chrome expired certificate error messages were dismissed 57% of the time whereas error messages for an untrusted issuer (the more serious problem) were dismissed in 82% of studied cases.