1. EA Games website hacked to steal Apple IDs

    An EA Games server has been compromised by hackers and is now hosting a phishing site which targets Apple ID account holders.

    The compromised server is used by two websites in the ea.com domain, and is ordinarily used to host a calendar based on WebCalendar 1.2.0. This version was released in September 2008 and contains several security vulnerabilities which have been addressed in subsequent releases. For example, CVE-2012-5385 details a vulnerability which allows an unauthenticated attacker to modify settings and possibly execute arbitrary code. It is likely that one of these vulnerabilities was used to compromise the server, as the phishing content is located in the same directory as the WebCalendar application.

    The phishing site attempts to trick a victim into submitting his Apple ID and password. It then presents a second form which asks the victim to verify his full name, card number, expiration date, verification code, date of birth, phone number, mother's maiden name, plus other details that would be useful to a fraudster. After submitting these details, the victim is redirected to the legitimate Apple ID website at https://appleid.apple.com/cgi-bin/WebObjects/MyAppleId.woa/

    The compromised server is hosted within EA's own network. Compromised internet-visible servers are often used as "stepping stones" to attack internal servers and access data which would otherwise be invisible to the internet, although there is no obvious outward facing evidence to suggest that this has happened.

    In this case, the hacker has managed to install and execute arbitrary PHP scripts on the EA server, so it is likely that he can at least also view the contents of the calendar and some of the source code and other data present on the server. The mere presence of old software can often provide sufficient incentive for a hacker to target one system over another, and to spend more time looking for additional vulnerabilities or trying to probe deeper into the internal network.

    As well as hosting phishing sites, EA Games is also the target of phishing attacks which try to steal credentials from users of its Origin digital distribution platform. For example, the following site — which has been online for more than a week — is attempting to steal email addresses, passwords and security question answers.

    EA's Origin servers also came under attack earlier this year, causing connectivity and login problems in various EA games. A tweet by @DerpTrolling appeared to claim responsibility for the outages, while also suggesting that it was a distributed denial of service attack which caused the problems.

    ("Gaben" is a reference to Gabe Newell, managing director of Valve Corporation, which owns the competing Steam digital distribution platform)

    Netcraft has blocked access to all phishing sites mentioned in this article, and informed EA yesterday that their server has been compromised. However, the vulnerable server — and the phishing content — is still online at the time of publication.

    The Audited by Netcraft service provides a means of regularly testing internet infrastructure for old and vulnerable software, faulty configurations, weak encryption and other issues which would fail to meet the PCI DSS standard. 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.

    Posted by Paul Mutton on 19th March, 2014 in Security

  2. Fake SSL certificates deployed across the internet

    Netcraft has found dozens of fake SSL certificates impersonating banks, ecommerce sites, ISPs and social networks. Some of these certificates may be used to carry out man-in-the-middle attacks against the affected companies and their customers. Successful attacks would allow criminals to decrypt legitimate online banking traffic before re-encrypting it and forwarding it to the bank. This would leave both parties unaware that the attacker may have captured the customer's authentication credentials, or manipulated the amount or recipient of a money transfer.

    The fake certificates bear common names (CNs) which match the hostnames of their targets (e.g. www.facebook.com). As the certificates are not signed by trusted certificate authorities, none will be regarded as valid by mainstream web browser software; however, an increasing amount of online banking traffic now originates from apps and other non-browser software which may fail to adequately check the validity of SSL certificates.

    Fake certificates alone are not enough to allow an attacker to carry out a man-in-the-middle attack. He would also need to be in a position to eavesdrop the network traffic flowing between the victim's mobile device and the servers it communicates with. In practice, this means that an attacker would need to share a network and internet connection with the victim, or would need to have access to some system on the internet between the victim and the server. Setting up a rogue wireless access point is one of the easiest ways for an individual to carry out such attacks, as the attacker can easily monitor all network traffic as well as influence the results of DNS lookups (for example, making www.examplebank.com resolve to an IP address under his control).

    Researchers from Stanford University and The University of Texas at Austin found broken SSL certificate validation in Amazon's EC2 Java library, Amazon's and PayPal's merchant SDKs, integrated shopping carts such as osCommerce and ZenCart, and AdMob code used by mobile websites. A lack of certificate checks within the popular Steam gaming platform also allowed consumer PayPal payments to be undetectably intercepted for at least 3 months before eventually being fixed.

    Online banking apps for mobile devices are tempting targets for man-in-the-middle attacks, as SSL certificate validation is far from trivial, and mobile applications often fall short of the standard of validation performed by web browsers. 40% of iOS-based banking apps tested by IO Active are vulnerable to such attacks because they fail to validate the authenticity of SSL certificates presented by the server. 41% of selected Android apps were found to be vulnerable in manual tests by Leibniz University of Hannover and Philipps University of Marburg in Germany. Both apps and browsers may also be vulnerable if a user can be tricked into installing rogue root certificates through social engineering or malware attacks, although this kind of attack is far from trivial on an iPhone.

    The following fake certificate for facebook.com is served from a web server in Ukraine. There are clearly fraudulent intentions behind this certificate, as browsing to the site presents a Facebook phishing site; however, the official Facebook app is safe from such attacks, as it properly validates SSL certificates and also uses certificate pinning to ensure that it is protected against fraudulently issued certificates.

    Similarly, this wildcard certificate for *.google.com could suggest an attempted attack against a multitude of Google services. The fake certificate is served from a machine in Romania, which also hosts dozens of websites with .ro and .com top level domains. It claims to have been issued by America Online Root Certification Authority 42, closely mimicking the legitimate AOL trusted root certificates which are installed in all browsers, but the fake certificate lacks a verifiable certificate chain. Some browsers' default settings will not allow a user to bypass the resultant error message.

    Not all fake certificates have fraudulent intentions, though. The KyoCast mod uses a similar wildcard certificate for *.google.com, allowing rooted Chromecast devices to intentionally send certain traffic to KyoCast servers instead of Google's. The fake certificate is issued by "Kyocast Root CA". Using the Subject Alternative Name extension, the certificate specifies a list of other hostnames for which the certificate should be considered valid:

    Russia's second largest bank was seemingly targeted by the following certificate – note that the issuer details have also been forged, possibly in an attempt to exploit superficial validation of the certificate chain.

    A similar technique is used in this certificate which impersonates a large Russian payment services provider. SecureTrust is part of Trustwave, a small but bona fide certificate authority.

    GoDaddy's POP mail server is impersonated in the following certificate. In this case, the opportunities could be criminal (capturing mail credentials, issuing password resets, stealing sensitive data) or even state spying, although it is unexpected to see such a certificate being offered via a website. Although the actual intentions are unknown, it is worth noting that many mail clients allow certificate errors to be ignored either temporarily or permanently, and some users may be accustomed to dismissing such warnings.

    Apple iTunes is currently the most popular phishing target after PayPal. In this example, the fake certificate has an issuer common name of "VeriSign Class 3 Secure Server CA - G2", which mimics legitimate common names in valid certificates; however, there is no certificate chain linking it back to VeriSign's root (so it is a forgery rather than a mis-issued certificate).

    It is not always criminals who use fake certificates to intercept communications. As a final example, the following fake certificate for youtube.com was served from a machine in Pakistan, where there is a history of blocking access to YouTube. This certificate is probably part of an attempt to prevent citizens from watching videos on YouTube, as the website serves "This content is banned in Pakistan" when visited.

    Netcraft's Mobile App Security Testing service provides a detailed security analysis of phone or tablet based apps. A key feature of this service is manual testing by experienced security professionals, which typically uncovers many more issues than automated tests alone. The service is designed to rigorously push the defences of not only the app itself, but also the servers it interacts with. It is suitable for commissioning, third party assurance, post-attack analysis, audit and regulatory purposes where independence and quality of service are important requirements.

    Posted by Paul Mutton on 12th February, 2014 in Security

  3. 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.

    Posted by Paul Mutton on 12th February, 2014 in Performance, Security

  4. 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.

    Posted by Paul Mutton on 7th February, 2014 in Around the Net, Security

  5. 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.

    Posted by Paul Mutton on 4th February, 2014 in Dogfood, Security

  6. 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

    Posted by Jason Robins on 14th November, 2013 in Netcraft Services, Other, Security

Page 2 of 5412345102030...Last »