Google’s April Fool’s prank inadvertently broke their security

As part of its traditional series of April Fool's day jokes, Google used its own .google gTLD to launch a backwards version of its home page from the domain on 1st April.

However, this year's joke inadvertently undermined an important security feature on Google's real homepage, which made it vulnerable to user interface redressing attacks such as click-jacking. This vulnerability would have allowed a remote attacker to change a user's search settings, including turning off SafeSearch filters.

The backwards content displayed on

The backwards content displayed on on 1 April 2015

The issue stemmed from the way used an iframe to display backwards content from This would not normally be possible, as uses the X-Frame-Options HTTP response header to prevent other websites from displaying itself within an iframe. But for the purpose of the April Fool's joke, Google stepped around this problem by passing the parameter "igu=2" to, which not only told it to display the content backwards, but also instructed the server to omit the X-Frame-Options header entirely. uses an iframe to display a backwards search page from Also not the reversed text in the HTML comment, revealing that it is an April Fool's day joke. used an iframe to display a backwards search page from Also note the reversed text in the HTML comment.

A remote attacker could also have leveraged this "feature" to display the Google Search Settings page in an iframe on an external domain, and trick his victims into unwittingly changing those settings. A carefully constructed clickjacking attack could have gone unnoticed by each victim until it was too late and the settings had already been changed.

To highlight the different responses, the following was an ordinary response from Google's Search Settings page at Note the presence of the X-Frame-Options header:

HTTP/2.0 200 OK
Alternate-Protocol: 443:quic,p=0.5
Cache-Control: private
Content-Encoding: gzip
Content-Length: 35486
Content-Type: text/html; charset=UTF-8
Date: Wed, 01 Apr 2015 09:54:14 GMT
Expires: Wed, 01 Apr 2015 09:54:14 GMT
Server: gws
Set-Cookie: [redacted]
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Firefox-Spdy: h2-15

Conversely, with the igu=2 parameter appended, the X-Frame-Options header was omitted from the response, allowing the page to be displayed in a frame on an attacker's own website:

HTTP/2.0 200 OK
Alternate-Protocol: 443:quic,p=0.5
Cache-Control: private
Content-Encoding: gzip
Content-Length: 33936
Content-Type: text/html; charset=UTF-8
Date: Wed, 01 Apr 2015 09:58:30 GMT
Expires: Wed, 01 Apr 2015 09:58:30 GMT
Server: gws
Set-Cookie: [redacted]
X-XSS-Protection: 1; mode=block
X-Firefox-Spdy: h2-15
Google's Search Settings being successfully displayed within an iframe on a Netcraft domain

Google's Search Settings being successfully displayed within an iframe on a Netcraft domain on 1 April 2015 (this content is not served backwards).

Changes made to the above settings via the iframe would persist across the user's session when they subsequently used in a normal window. Netcraft reported this issue to Google and it has since been resolved — the method described in this article can no longer be used to display the settings page within an iframe on an external domain.

Critical Windows vulnerability affects at least 70 million websites

The race is on to patch nearly a million Windows web servers, following the publication of code that can identify the presence of a serious vulnerability announced by Microsoft on Tuesday.

The critical vulnerability lies within Microsoft's HTTP protocol stack, known as HTTP.sys. The maximum security impact, according to Microsoft Security Bulletin MS15-034, is remote code execution — by sending a specially crafted HTTP request to a vulnerable server, a remote attacker can execute arbitrary code on that server.

An ongoing scan for this vulnerability suggests that the test performed by the published code is inconclusive, as it might erroneously give the all-clear to a server that returns non-static content, even if it is in fact vulnerable.

However, Netcraft's latest Web Server Survey shows more than 70 million websites could be vulnerable, including Microsoft IIS servers that sit behind non-Windows load balancers. The total number of servers involved in hosting these sites stands at around 900,000, which is more than a sixth of all web-facing computers in the world.

The affected versions of Windows includes Windows Server 2008 R2, 2012 and 2012 R2. Windows 7, 8 and 8.1 are also vulnerable, but are not commonly used to host websites. Microsoft's security bulletin does not include Windows Server 2003 in the list of affected versions, so the 130 million sites that run IIS 6.0 on this older operating system would appear to be safe (at least from this particular issue).

Given the swift publication of code that could potentially be developed into a practical exploit, it is essential that all Windows server administrators apply the necessary security updates as a matter of urgency.

Microsoft has already released a security update for this vulnerability, so don't delay, apply today!

Web security company inadvertently aids HMRC phishing attack

Web security company M86 Security Labs, which is now part of TrustWave SpiderLabs, is inadvertently helping fraudsters to carry out phishing attacks against HM Revenue & Customs.

The text within this HMRC phishing email is actually represented by a PNG image, which is loaded directly from the M86 Security Labs website.

The text within this HMRC phishing email is actually represented by a PNG image, which is loaded directly from the M86 Security Labs website.

The spoof emails involved in the ongoing attack look practically the same as many previous HMRC phishing emails — and that's because the content within the email body is being served directly from the M86 Security Labs website. The emails simply display a PNG screenshot of an email that was featured in a 2010 blog post by M86 Security Labs, which warned potential victims about an HMRC phishing attack.

Ironically, the screenshot featured in that blog post is now being used as a key component of the current attacks against taxpayers.

The HTML source of the email body.

The HTML source of the email body, which displays the 24kb image from the M86 blog post.

The image as it was intended to be shown on the M86 Security Labs blog.

The image as it was intended to be shown on the M86 Security Labs blog.

Clicking anywhere on the image in the phishing email takes the victim to an HMRC phishing site hosted in Turkey. This initially prompts the victim to enter their email address, full name and date of birth, before a subsequent page asks for even more information, including the victim's postal address and card details.


Fake HMRC tax refunds remain a popular ruse. Netcraft blocked 1,150 HMRC phishing sites last month alone, and notably discovered one hosted under the trusted domain in 2009.

Steam Community phishing attacks continue unabated

Phishers are still using look-alike domain names to steal Steam credentials from unsuspecting victims, which suggests that this approach is proving rather successful for the criminals. These types of attack are particularly effective if carried out within Steam's own browser, which lacks the protective features seen in most mainstream browser software.

Since Netcraft first highlighted this issue in June last year, nearly a third of all phishing attacks against Steam users continue to make use of look-alike domains. Some of these domain names, such as "", look practically identical to the real domain, particularly when displayed in the address bar of the built-in Steam browser:

This is not

This is not

Look-alike domains play a particularly important role in Steam phishing attacks, as victims are often tricked into visiting these phishing sites by fraudsters sending messages through Steam's own chat client or by enticing them to visit links in forum posts. These spearphishing attacks are obviously more likely to succeed if a victim believes the link is going to take him to the genuine Steam Community website.

First seen more than a year ago, the look-alike domain is still being used for Steam phishing attacks today. After stealing a victim's credentials, it redirects the browser to the genuine Steam Community website.

First seen more than a year ago, the look-alike domain is still being used for Steam phishing attacks today. After stealing a victim's credentials, it redirects the browser to the genuine Steam Community website.

It is very unusual for such a high proportion of a target's phishing attacks to make use of custom paid-for domain names. The vast majority of phishing attacks against other targets, such as banks, are typically hosted on existing compromised websites (where the domain name obviously cannot be changed), or make use of specially crafted subdomains on free hosting platforms.

Many of the other attacks against Steam users fall into the latter category, attempting to mimic the Steam brand by using less-convincing subdomains that are cheaper or free to obtain. Examples of these have included, and

Netcraft has blocked a total of 2,000 unique Steam phishing URLs in the past three months alone. Interestingly, more than 600 of these URLs were used by attacks carried out on Christmas day. This is often thought to be a good time for these types of attack, as many technical support and customer services representatives are generally unavailable during this period. This gives the fraudsters additional time to monetize stolen accounts, as it is likely to be a few days before anyone can respond to a victim's compromised account enquiries.

Steam Trading makes it possible to monetize stolen Steam accounts, and provides an obvious incentive to go phishing on Steam. This in turn explains why many users have opted to increase the security of their accounts by enabling Steam Guard, which is essentially a two-factor authentication mechanism. Even if the phisher manages to steal a victim's Steam username and password, he will not be able to log into the account without also submitting a special access code.

The special access code is sent to the victim via email, so in order to fully compromise the Steam account, the fraudster must also compromise the victim's email account, trick the victim into disabling Steam Guard, or trick him into submitting the access code on behalf of the fraudster. Many of the previous attacks enticed victims to download and run a SteamGuard.exe executable, which was actually malware designed to steal a special authentication file from the victim's computer. This allowed the Steam Guard protection to be bypassed whilst also paving the way for instant trading by eliminating the new-device time delay protection which would have applied if only the access code was stolen.

2% of the domains used in these attacks make use of the .ru top-level domain (, for example) rather than the more intuitive .com. This choice of TLD is perhaps no coincidence, as some of the fake Steam Guard binaries point to a website called SteamComplex, which also uses a .ru top-level domain.

Hosted on the CloudFlare content distribution network, is written in Russian and appears to be selling the Steam malware used in these attacks. Many of the Steam phishing attacks, such as the one shown in the screenshot above, are also clearly aimed at Russian speakers.

Is Steam doing enough to protect its users?

The ongoing recurrence of these attacks suggests that Steam might not taking the appropriate action to deal with these phishing sites, or if it is, its actions are ineffectual. For example, the look-alike domain has been serving the same Russian phishing content for around a month. It is hosted at a place which is usually responsive to takedown requests, which strongly indicates that no effort has been made to take it down.

Additionally, when victims are redirected from a known phishing site to the real Steam site, the location of the phishing site is revealed in the HTTP Referer header (shown below). This would allow the Steam Community website to recognise that the user's credentials may have just been phished, but it does not take the opportunity to display any warnings in the victim's browser.

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: [removed]
Connection: keep-alive

Finally, while all mainstream browsers deny access to known phishing sites like the ones shown above, Steam's own built-in browser does not. This lack of blocking, coupled with the easily-spoofed address bar, makes the Steam browser remarkably vulnerable to these attacks.

The "" phishing site is blocked natively within Internet Explorer. The domain in the address bar is also displayed more clearly, allowing sharp-eyed users to identify it as fake.

The "" phishing site is blocked natively within Internet Explorer. The domain in the address bar is also displayed more clearly, allowing sharp-eyed users to identify it as fake.

In mitigation, some users have noticed that the Steam chat client has started removing some of these malicious links in recent days, which will hopefully limit the effectiveness of the chat-based attack vectors.

A malicious link removed from a Steam chat message (highlighted).

A malicious link removed from a Steam chat message (highlighted).

Netcraft's phishing site feed is used by all mainstream browsers. For more information about this and our phishing site takedown service, please contact us at

Student Loans Company advice makes phishing easier

Anticipating a surge in phishing attacks over the festive period, the Student Loans Company warned students in Britain to be on the lookout for suspicious emails. Unfortunately, some of its anti-phishing advice could have backfired, potentially increasing the risk of students falling for phishing attacks.

Warning students to be on the lookout for fraudulent emails attempting to impersonate the SLC, it told The Telegraph and Money Saving Expert that any official correspondence would come from the email address However, this advice is rather dangerous because the domain has not been configured to prevent spoof emails being sent from this address.

In particular, does not have a Sender Policy Framework record. SPF rules can be used to describe who can send email on its behalf, and the lack of any policy means there are no restrictions on who can send emails appearing to come from

If students infer from the SLC's advice that all emails from will be legitimate, then fraudsters will be able to carry out much more convincing phishing attacks simply by spoofing emails from this address.

The domain also lacks a DMARC record, which means the SLC cannot choose what happens to forged emails that appear to come from the domain. If correctly configured, such emails could not only be blocked by some email providers, but SLC would also be able to view the contents of forged emails and receive statistics to see how many are being sent.

Preventing forged emails is an important part of mitigating phishing attacks, as many attacks are initiated via email. A typical phishing email will play on the victim's sense of urgency — for example, by warning the student that his next payment may be lost or delayed if he does not update his records at the fraudster's "secure" website that masquerades as a real SLC website.

Once the victim has been tricked into visiting the phishing site, he will be prompted to enter a multitude of information which can be used to steal the loan money as soon as it arrives in his bank account. Most student loan phishing sites blocked by Netcraft usually ask for far more information than a conventional online banking phishing attack would do, capturing not just the victim's bank account details and card number, but also details about the student's university course and term time address.

Frozen phish

Despite the SLC warning of an increase in phishing attacks, it is fortunate that the fraudsters instead put an unexpected freeze on their phishing activity over the Christmas holidays. In fact, not a single student loan phishing site has been blocked by Netcraft since before Christmas day.

During 2014, Netcraft blocked more than 180 phishing URLs that impersonated the Student Loans Company or the Student Finance England service (which is run by the SLC), while SLC's fraud team took down around 150 phishing sites. Over the past three years, it claims to have prevented almost £3 million being stolen.


The calm before the storm that didn't happen: Most student loan phishing attacks occurred at the start of the academic year (September), and all of those carried out in December took place before Christmas day. Despite the second loan instalments being sent out this week, no attacks have taken place since.

New students make particularly attractive targets for fraudsters, as many will have no previous experience at managing their own finances. Research by the British Bankers' Association suggests that one in six of those aged 18 to 25 could be vulnerable to money transfer scams; a higher proportion than any other age group.

Student loans in the UK typically consist of a tuition fee loan – which can be up to £9,000 per year and is paid directly to a student's university or college – plus a maintenance loan of up to £7,751, which is paid into the student's own bank account, making the latter component an obvious target for phishing fraudsters.

Organisations concerned about email impersonation attacks can use Netcraft's Fraud Detection service, which processes DMARC (Domain-based Message Authentication, Reporting and Conformance) reports on your behalf. These reports are sent by ISPs and e-mail receivers when they see any emails which claim to be from one of your own domains. A web interface shows the status of all of your own domains, any configuration changes required, and highlights unprotected domains being used by fraudsters attacking your customers. Netcraft can also provide real time alerts of phishing sites targeting your company, and our takedown service can be used to remove phishing sites.

Moonpig breach highlights need for app and API testing

A severe vulnerability in the API used by Moonpig's Android app has highlighted the need for organisations to apply greater scrutiny to the security of their apps and endpoints. Through its apps and website, the custom greetings card company sends out more than 12 million cards every year and turned over £53 million last year.

By enumerating an easily predictable sequence of user ID numbers, anyone could retrieve various information about millions of Moonpig customers, including names, addresses, and some credit card details. Because there was no authentication mechanism for the API, an attacker could also have placed orders on other customers' accounts.

Unlike with traditional web applications, much of what goes on beneath the glossy facade of an app is hidden from the user — but with the right tools and the right knowledge, it can be trivial to identify and exploit any vulnerabilities that might affect it. The Moonpig vulnerability exemplifies this, as the problem was not only easy to spot, but could be exploited simply by pasting a modified URL into a standard web browser.

The Moonpig vulnerability stemmed from the fact that the API trusted data sent from the app, without considering that it could have been altered or fabricated by a malicious party. This type of vulnerability fundamentally compromises the security of the application and the data it handles, and would likely be quickly identified in a third-party security test of the API.

The danger posed by this vulnerability was compounded by Moonpig's failure to react promptly — Moonpig purportedly knew about this issue 17 months ago after it was reported by one of its own customers. However, Moonpig failed to shut down or fix the vulnerable service until after the vulnerability was publicly disclosed last night.

Moonpig issued the following statement on its website today:

You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today's report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.

Netcraft offers Mobile App Security Testing services and traditional Web Application Security Testing, both of which include testing of relevant APIs and other endpoints that may be commonly overlooked. Contact us at to discuss your requirements.