Hotpoint service sites hacked

Hotpoint's UK service website has been hacked. Instead of allowing customers to activate warranties, book services or find an engineer, the site is currently putting its customers at risk by redirecting them to a variety of dubious websites.

Some visitors were presented with a fake Java update page, which downloaded malware.

Some Hotpoint visitors are being redirected to a fake Java update page, which downloads malware.

The hacker has accomplished this feat by appending malicious JavaScript code to several of the scripts hosted on the Hotpoint service site. It was not readily apparent how the hacker gained write-access to these files, but the WordPress content management system that the site runs on is notorious for being compromised if both it and its plugins are not kept up to date.

The hack has also affected Hotpoint's Irish service website, which is hosted on the same IP address as the UK one.

The malicious code appended by the attacker. This appears at the end of an otherwise-legitimate script which asks the user whether they want to accept cookies from the site

The malicious code appended by the attacker. This appears at the end of an otherwise-legitimate script which asks the customer whether they want to accept cookies from the site.

The appended code is obfuscated to make its purpose less apparent, perhaps in the hope that nobody would dare to delete it. De-obfuscating the code reveals that it is responsible for loading a larger obfuscated script from an external site.

The externally hosted malicious script pretends to be an innocuous jQuery file; but scrolling down reveals its true content, which is obfuscated.

The externally hosted malicious script pretends to be an innocuous jQuery file; but scrolling down reveals its true content, which is obfuscated.

Presumably, this external site is operated by the hacker, in which case he has the opportunity to change the content of his malicious payload at will. Any visitor to the Hotpoint service site could consequently be at risk of much more serious attacks, such as drive-by malware or phishing.

Hotpoint service customers are also being redirected to scam survey sites like this one.

Many bank holiday shoppers who buy Hotpoint white goods are likely to fall victim to this attack, as the paperwork included with new appliances directs new customers to the site to activate their 10 year parts guarantee.

Thanks Tim

New customers are directed to the hacked site.

Existing customers desperate to find out about certain models of dangerous tumble dryers are also likely to be snared by the JavaScript attack.

Generally, the Easter bank holiday weekend is a good time for hackers to strike UK websites, as many people will be on holiday on both Good Friday and the following Monday. The longer the attacker can keep his redirection code in place, the more revenue he can reap.

Of course, there could be wider-reaching repercussions to this attack – if an attacker has been able to modify scripts on Hotpoint's website, then he could also have been in a position to view any data stored or transmitted by the site.

Let’s Encrypt and Comodo issue thousands of certificates for phishing

Certificate Authorities are still issuing tens of thousands of certificates for domain names obviously intended for use in phishing and fraud. Fraudsters are mostly using just two CAs — Let's Encrypt and Comodo domain-validated certificates accounted for 96% of phishing sites with a valid TLS certificate found in the first quarter of 2017.

Netcraft has blocked phishing attacks on more than 47,500 sites with a valid TLS certificate between 1st January and 31st March 2017. On 19,700 of these, Netcraft blocked the whole site rather than a specific subdirectory. 61% of the sites that were entirely blocked were using certificates issued by Let's Encrypt, and 36% by Comodo.

While some CAs, browser vendors, and commentators have argued that fraud prevention is not and should not be the role of certificate authorities, the scale of foreseeable misuse that can be combated automatically warrants further consideration of this policy. Without change, issuance of certificates for sites such as and that are obviously intended for misuse will continue unabated.

Certificates issued by publicly-trusted CAs that have been used on phishing sites

Certificates issued by publicly-trusted CAs that have been used on phishing sites. An interactive, updating version of this graph can be found on Netcraft's Phishiest Certificate Authorities page.

Mozilla Firefox's telemetry reports that approximately 55% of all page loads are over HTTPS. The movement to a secure web is crucial to defend against the risks posed by unencrypted traffic, and easy access to trusted certificates is a key factor in the recent growth. However, this easy access also offers opportunities for fraudsters to capitalise on the perception of HTTPS as trustworthy as demonstrated by the number of certificates issued for clearly deceptive domain names.

Looking at a small sample of these blocked phishing sites with valid TLS certificates that have high Deceptive Domain Scores:

Hostname Certificate Authority Target Deceptive Domain Score Let's Encrypt Apple
9.25 Let's Encrypt PayPal
9.13 Symantec Airbnb
8.99 Comodo Chase
10.00 GoDaddy PayPal
9.13 GlobalSign Apple
9.30 Let's Encrypt American Express
7.99 Comodo Dropbox
9.70 Let's Encrypt Wells Fargo
10.00 Comodo Bank of America
9.40 Let's Encrypt La Banque Postale
7.10 Let's Encrypt USAA

In each of these examples above — and in the other statistics referenced above — the certificate authority had sight of the whole hostname that was blocked. These examples did not rely on wildcard certificates to carry out their deception. In particular, some of these examples (such as demonstrate that the certificate authority was better placed to prevent misuse than the domain registrar (who would have seen upon registration).

Let's Encrypt and Comodo are attractive to fraudsters as both offer automated, domain-validated certificates at no cost to end users. Let's Encrypt's ACME protocol allows for free automated issuance, while Comodo offers no-cost certificates via its trial certificates, cPanel AutoSSL, and its Cloudflare partnership.

While Let's Encrypt's policy on phishing and malware is to check the Safe Browsing API, this does not provide effective pre-issuance blocking. It does not match the reality of automated certificate deployment, where the certificate is likely to be issued and installed before the phishing content has been uploaded, detected, and blocked. Let's Encrypt also has a limited list of domain names for which they block issuance which has triggered forum posts by users unable to obtain a certificate for the blocked name. All of the Let's Encrypt certificates that Netcraft found on phishing sites were issued despite the Safe Browsing check and the additional name-based blocking.

Phishing site on

Phishing site on (Deceptive Domain Score is 9.46).

The use of TLS by these phishing sites is particularly dangerous, as websites that use TLS are marketed as being trustworthy and operated by legitimate organisations. Consumers have been trained to look for padlocks, security indicators, and https:// in the address bar in their browser before submitting sensitive information, such as passwords and credit card numbers, to websites.

However, a displayed padlock or "Secure" indicator alone does not imply that a site using TLS can be trusted, or is operated by a legitimate organisation. The distinction between the connection being "Secure" and the safety of providing sensitive information to the HTTPS site may be challenging to interpret for those unfamiliar with the technical underpinnings of TLS.

"Secure" vs. "Private" in Google Chrome

"Secure" vs. "Private" in Google Chrome.

Demonstrating the difficulty of explaining this technical distinction, Google Chrome indicates that an HTTPS connection is using a valid TLS certificate by displaying the word "Secure" in the address bar. While the word "secure" refers to the encrypted connection's protection against eavesdroppers, this is explained in the drop-down with the word "private". The distinction between these two words is subtle, yet potentially significant for user understanding. However, it is important to note that Google has been at the forefront of research into how security indicators are perceived by internet users at large.

Mozilla Firefox's warning when selecting a password form field on a non-secure HTTP site

Mozilla Firefox's warning when selecting a password form field on a non-secure HTTP site.

Both Google Chrome and Mozilla Firefox have made recent changes to the display of password input forms on non-TLS sites — non-secure forms now trigger in-context warnings. These warnings are likely to increase the prevalence of TLS on phishing sites, with fraudsters deploying TLS to both gain the positive "Secure" indicator, and now to avoid negative indicators when collecting passwords.

Deceptive Domain Score service

Netcraft's Deceptive Domain Score service provides an automated mechanism for evaluating whether a given hostname or domain name is likely to be used to fraudulently impersonate an organisation. Crucially, this can be evaluated before issuing a certificate. Of these 19,700 hostnames with valid TLS certificates where Netcraft blocked the entire site, 72.5% scored more than 5.0 and 49% more than 7.0 (on a scale from 0.0 to 10.0).

Distribution of Deceptive Domain Score across blocked phishing sites with valid TLS certificates

Distribution of Deceptive Domain Score across blocked phishing sites with valid TLS certificates.

For comparison, a random sample of 10,000 hostnames taken from domain-validated certificates issued in February 2017 as found in Netcraft's April 2017 SSL survey, had an average score of 0.72, with 7% having a score over 5.0, and 4.4% a score over 7.0.

More information on Netcraft's Deceptive Domain Score service can be found on Netcraft's website.

Government websites pair up to host Apple ID phishing attack

Brazilian and Laotian government websites were found collaborating in an unusual Apple ID phishing attack today.

The Brazilian government education WordPress site at, and the Laotian government Department of Posts and Telecommunications site at — which runs Joomla — have evidently been compromised in this attempt to steal Apple ID credentials.

A subdirectory on houses this phishing content, which prompts victims to enter their Apple IDs and passwords.

A subdirectory on houses this phishing content, which prompts victims to enter their Apple IDs and passwords.

The most unusual thing about this particular incident is that both government sites are being used to carry out the same phishing attack: The spoof Apple ID login form is hosted on the Brazilian government site, while the Laotian government site hosts a script that redirects visitors to the spoof form on the Brazilian site.

In a separate spate of attacks, an Alibaba phishing site was also discovered on another Brazilian government site this week at, and a LinkedIn phishing site was found on the Pakistani government health information website at The Laotian government site was also used to host a redirect to another phishing attack against a Greek bank last month.

While it is common for phishing sites to be hosted on compromised web servers, it is often assumed that government websites would be more secure than average; but this is not always the case, as empirically demonstrated by this week's attacks, and also by previous attacks hosted on Malaysian, Nigerian and Thai government websites.

However, this is the first time Netcraft has seen two different governments' websites working together to take part in the same phishing attack.

Banking, news and pharmacy websites regarded “not secure” by Chrome and Firefox

Popular news websites, hotels, pharmacies, gaming sites, and many online banking sites are among millions of websites that are now explicitly flagged as "not secure" by some of the most commonly used browsers.

Current stable versions of Google Chrome and Mozilla Firefox now display a "not secure" warning in the URL bar if a webpage served over an unencrypted HTTP connection requests a user's password – even if the password is usually submitted to a secure (HTTPS) site. This is because an attacker could modify the non-secure HTTP form and cause the user's credentials to be sent elsewhere.

This security feature was first introduced in Firefox 51, which was released on 24 January, and then in Chrome 56, which was rolled out in the weeks following 25 January. Chrome also displays the warning on pages that contain fields for entering credit card numbers.

Banks failing to protect their customers

Surprisingly many banks have failed to react to the new browser behaviour. For example, Santander's Chilean website at can be accessed over an unencrypted HTTP connection, but it displays an online banking login form regardless.

Santander's Chilean website serves a login form over HTTP.

Chrome 56 declares Santander's Chilean website as "not secure". Its login form is served over an unencrypted HTTP connection, which can expose customers' login details to man-in-the-middle attackers.

The contents of the login form are submitted to a secure URL on, which uses an SSL certificate issued by GeoTrust. This secure connection is therefore protected against man-in-the-middle attacks, but crucially, this security is undermined by serving its login form over an unencrypted HTTP connection — a man-in-the-middle attacker can simply siphon the customer's credentials from this page before they are even submitted to the secure site.

A few other examples of banking websites that are now marked as "not secure" (and this is not an exhaustive list by any means) include Eagle Bank, Community Bank of Fitzgerald, Diamond Bank, Flora Bank & Trust and Bank of Hamilton.

Ironically, some of these examples display padlock icons on their online banking login forms, despite serving them over unencrypted HTTP connections. This gives a misleading impression of security, although the risks are now made apparent to any user of Firefox 52. displays a padlock on its login form, but Firefox 52 reveals the true situation. displays a padlock on its login form, but Firefox 52 reveals the true situation.

Pharmacy logins exposed

CVS pharmacy — the largest pharmacy chain in the United States, with a parent company that is #7 in the Fortune 500 — also displays its login form over an insecure connection. Interacting with this form in Firefox 52 will cause the "not secure" warning to be displayed much more prominently, beneath whichever field has focus. This is much harder to miss than just the crossed padlock icon in the address bar of Firefox 51.

Firefox 52 also objects to the login form on

Firefox 52 also objects to the login form on

A customer who signs in to CVS can manage their family's prescriptions online, so any security weakness that potentially exposes their login credentials could raise some regulatory eyebrows. To maintain the privacy and security of Electronic Protected Health Information (EPHI), the HIPAA Security Rule lays out a set of administrative, physical and technical safeguards. The latter is intended to protect communications being intercepted by anyone other than the intended recipient.

Why are browser vendors doing this?

The new behaviour is designed to help users recognise the risk of man-in-the-middle attacks on unencrypted traffic. If an attacker is in a position to be able to change the content of the page when it is served over an unencrypted HTTP connection, then he can easily steal sensitive information from the user – for example, by changing the URL that the form is submitted to, or by injecting JavaScript that silently transmits a copy of the credentials to a server under his control.

Such attacks are entirely plausible, especially with the prevalence of mobile computing. The attacker does not need to infiltrate an ISP or be part of a spy agency in order to view a victim's network traffic – he can simply turn up to a coffee shop and use his phone or laptop to offer a free Wi-Fi network that other customers are likely to use. This would allow him to view and alter the contents of any HTTP form without detection.

The warning feature was previously made available in development releases of both browsers. When it was added to Firefox 46 Developer Edition in January 2016, Mozilla stated that there were no plans to add it to general releases, since developers were ultimately the ones who need to make logins more secure on the sites they build.

Clicking on the padlock shows why the page is not secure.

Firefox 51 and later flag the Express news website as not secure.

While the warnings are now displayed to all users of Firefox and Chrome, they are still intended to encourage web designers to update their sites to ensure that sensitive information is always requested over HTTPS. Although the warnings are only shown in a limited set of circumstances, Chrome's warnings represent a step towards Google's long-term plan to flag all HTTP sites as "not secure".

The warnings are harder to miss in Firefox 52.

Firefox 52, which was released this week, makes its warnings much more obvious by displaying them inline whenever the user interacts with the offending form.

The new browser behaviour could encourage faster migration to HTTPS by naming and shaming offending websites to their own users. The warnings shown in Firefox 51 and Chrome 56 are rather subtle and could easily be overlooked or not understood by regular users, but the inline warnings now shown in Firefox 52 are easier to interpret and much harder to miss. Chrome 57 is expected to have a similar feature when it is released on March 14. Many websites are therefore expected to react to their "not secure" status in the coming days and weeks.

How many sites are now "not secure"?

Netcraft's Active Sites dataset contains millions of examples where websites serve password fields over unencrypted HTTP connections. All of these sites will be flagged as "not secure" in the latest stable versions of Firefox and Chrome.

Prior to the release of Firefox 51 and Chrome 56, the affected sites would not have caused any warnings to be shown in the URL bar, giving the impression that there were no problems. In contrast, an HTTPS website that uses an expired SSL certificate would display prominent, unmissable warnings, regardless of whether it serves any password fields – even though the connection would arguably be more secure than an unencrypted HTTP connection.

News sites

A wide variety of sites are affected by the new behaviour of Chrome and Firefox, including some of the most popular news websites. This is arguably a good thing, as being affected will encourage them to adopt better security measures.

Fox News visitors ( currently receive the warning when logging in. Although Fox News credentials are ordinarily submitted to a secure server at, the login form itself is served over an unencrypted HTTP connection, and so there is an opportunity for a man-in-the-middle attacker to steal any credentials entered on this page:

Fox News: One of the most popular news sites that has yet to resolve its "not secure" status.

Fox News: One of the most popular news sites that has yet to resolve its "not secure" status.

Some of the news websites that make use of Gigya for customer identity management are also flagged as not secure. This includes the Irish Examiner, the Independent, and the Express. Again, although Gigya's service only accepts credentials via a secure login URL similar to, the pages that send these credentials are not secure.

Gigya only accepts passwords over an HTTPS connection, but the Independent website serves its login form over HTTP. This is ripe for mischief.

Gigya only accepts passwords over an HTTPS connection, but the Independent website serves its login form over HTTP. This is ripe for mischief.


Chinese search engine Baidu is one of the most frequently visited HTTP sites that is now marked as "not secure" by Chrome and Firefox. Unlike Google, its homepage does not use HTTPS by default, and so a significant number of users are likely to see flagged as being "not secure" when they try to log in.

Baidu: Login credentials vulnerable to man-in-the-middle attacks.

Baidu: Login credentials vulnerable to man-in-the-middle attacks.

Not all Baidu users will be vulnerable, however, as any visit to its HTTPS site at will cause Baidu's HTTP Strict Transport Security policy to kick in. This will force the user's browser to use HTTPS for all subsequent visits for at least the next two days, thus ensuring that the login form will be served over a secure connection.

Unfortunately, Baidu's 2-day HSTS policy can only take effect after the user has visited the HTTPS site, rendering all new and infrequent users vulnerable to MITM attacks. This weakness could be resolved by adding to Chromium's HSTS preloaded list, which would cause most modern browsers to always use HTTPS, even if the site has never been visited before.

Other high-profile sites that are currently "not secure"

The FIFA website at is instantly flagged as being insecure, even before the login form is made visible to the user. Although this login form submits to a secure URL at, the form itself is of course vulnerable to man-in-the-middle attackers who could divert the user's credentials elsewhere.

Firefox 52 points out the insecurity in FIFA's dropdown login form at

Firefox 52 points out the insecurity in FIFA's dropdown login form at

Tagged and hi5 are popular social networking sites that are flagged as insecure despite having login forms that are served over secure HTTPS connections. This is because each secure login form is displayed inside an iframe that is displayed by an HTTP site. If the HTTP site were to be man-in-the-middled, the attacker could instead cause this frame to show a spoof login form instead of the intended secure content. is flagged as "not secure" because the parent of its secure login frame is served over HTTP. is flagged as "not secure" because the parent of its secure login frame is served over HTTP.

A few other high profile sites also flagged as "not secure" include those operated by the global lodging company Marriott, Scandinavia's largest airliner SAS, parcel delivery companies Parcelforce and DPD, online gaming sites Miniclip and Bigpoint, and some sites that use Salesforce (e.g.

What do the affected websites need to do?

Chrome and Firefox will only display the new warnings when they encounter password fields that are served over unencrypted HTTP connections, so the fix is quite straightforward: Make sure these pages are served over HTTPS (using a valid SSL certificate, of course).

While this course of action will make the warning messages disappear, it will not on its own eliminate all types of man-in-the-middle attacks. For instance, most HTTPS sites are vulnerable to trivial connection hijacking attacks that can be exploited whenever a user inadvertently tries to access the secure site over HTTP. This "SSL stripping" vulnerability can easily be resolved by implementing an appropriate HTTP Strict Transport Security (HSTS) policy, yet only a small percentage of HTTPS sites actually do this.

Further protection can be sought by using HSTS preloading, which ensures that a site's HSTS policy is distributed to supported browsers before the user's first visit. Going a step further, HTTP Public Key Pinning can prevent fraudsters using mis-issued SSL certificates to carry out man-in-the-middle attacks, but incredibly few sites have dared to use this feature – partly because it can backfire spectacularly if website administrators get it wrong.

It is also debatable whether the browsers' new warnings will help in all cases. A man-in-the-middle attacker who is able to change the contents of an HTTP login form may be able to prevent the warnings from being displayed, simply by using an ordinary text field instead, or perhaps by using Flash, JavaScript or a HTML5 Canvas to emulate the behaviour of a password field.

Users of Chrome 56 and Firefox 51 also might not notice the subtle "not secure" warnings displayed by these versions, and so an attacker who has man-in-the-middled a login form may still be able to carry out a viable attack as long as the login form continues to be served over HTTP.

However, Firefox 52 (and soon Chrome 57) will make the warnings much easier to notice, and this is likely to drive the security of the web in the right direction. Directly naming and shaming insecure websites to their own users is potentially one of most powerful ways of encouraging companies to make better use of HTTPS, which will ultimately make it harder for hackers to carry out man-in-the-middle attacks.

Hackers still exploiting eBay’s stored XSS vulnerabilities in 2017

Fraudsters are still exploiting eBay's persistent cross-site scripting vulnerabilities to steal account credentials, years after a series of similar attacks took place. Worse still, many of the listings that exploited these vulnerabilities remained on eBay's website for more than a month before they were eventually removed.

All of the attacks stem from the fact that eBay allowed fraudsters to include malicious JavaScript in auction descriptions. Previous attacks exploited this vulnerability to place malicious redirect code on high-value vehicle listings, with the intention of stealing login credentials from other eBay members, whose accounts could then be used to list even more fraudulent vehicle listings.

But fraudsters are now using malicious scripts on a wide variety of lower-value items, including legitimate listings that had already been posted from reputable eBay accounts. Fraudsters have seemingly compromised these accounts and appended additional information to many of the members' existing listings – and this is where the malicious JavaScript is placed.

As can be seen below, the cybercriminals even used listings of dental tools to extract credentials from their victims, bypassing eBay's toothless listing policies in a similar way to the attacks that took place a few years ago.

A compromised listing for a dental tool from a Chinese seller as it appeared in eBay search results.

A compromised listing for a dental tool from a Chinese seller as it appeared in eBay search results.

Clicking on the above listing took the user to the following page, which included malicious JavaScript that had been injected by the fraudster:

The malicious listing is displayed for only a split second

The malicious listing is displayed for only a split second

But the malicious code in this listing executes as soon as the page has loaded, which causes it to be displayed for only a split second. In the blink of an eye — and without any further interaction — the victim is redirected to a spoofed login form:

In the blink of an eye, the victim is redirected to a very-convincing spoof login form.

In the blink of an eye, the victim is redirected to a very-convincing spoof login form.

Victims are unlikely to expect a phishing form to appear as a result of clicking on an eBay search result, and so the efficacy of these attacks is likely to be far greater than the average phishing scam. Allowing listings to include arbitrary JavaScript not only facilitates this type of fraud, but also allows fraudsters to capitalize on the trust instilled by the eBay website.

In this particular example, the malicious code injected by the attacker was obfuscated to make its purpose less apparent – possibly to get around any text-based content filters implemented by eBay. The obfuscated script is used to load a much larger JavaScript payload from an external location at (this script, which was hosted by Easily, has since been removed).

Lightly-obfuscated malicious JavaScript as it appeared in an eBay listing

Lightly-obfuscated malicious JavaScript as it appeared in an eBay listing

The externally-hosted script redirected victims to a data URI, which is another trick sometimes used by cybercriminals: The Base64-encoded address makes it difficult for victims to report such attacks, as by this point, the page is ostensibly not hosted anywhere.

When the victim submits his username and password, the credentials are transmitted to a script at (which has also since been taken down). This PHP script receives the victim's credentials and then immediately redirects the victim to a page on the genuine eBay website, giving the impression that the listing that the victim originally attempted to visit is no longer available:

The victim is redirected to a non-existent listing after his credentials have been stolen.

The victim is redirected to a non-existent listing after his credentials have been stolen.

The victim may not realise it — as his browser never showed the address of any externally hosted websites — but at this point, his credentials will have already been stolen by the fraudster's PHP script.

The fraudsters behind these attacks can attempt to monetize these stolen credentials by selling them to other fraudsters, or use them to propagate malicious code into even more listings. In the dental tool example, malicious JavaScript was added to the listing on 8 December 2016, and remained there until late January 2017, giving the fraudster more than a month and a half to exploit the vulnerability.

The malicious script (not visible) was added on 8 December 2016, and eBay continued to serve it for a month and a half.

The malicious script (not visible) was added on 8 December 2016, and eBay continued to serve it for a month and a half.

The compromised seller account involved in the above attack had over a thousand of its listings infected with malicious JavaScript, many of which flew under eBay's radar for more than a month, despite having obvious malicious intentions. The only deterrent is eBay's JavaScript policy, which disallows the use of JavaScript redirects – but this is evidently not entirely effective, as it failed to prevent it being exploited for extended periods, and fraudsters will obviously not care about breaking policies that are not proactively enforced.

These latest listings were reported to Netcraft by "Jaco Bustero". Although this pseudonym is very similar to "Buster Jack" — who discovered a series of related scams in 2014 — they are, in fact, different people in the UK. Both hide behind pseudonyms because of valid concerns about their own safety – for instance, Buster Jack's efforts to combat vehicle fraud have earned him several death threats from the perpetrators of these crimes.

But fortunately, the end of script-based attacks may soon be in sight on eBay. In an effort to make its listings mobile-friendly, eBay plans to limit the use of active content (such as JavaScript) at some point in 2017, before eventually blocking it altogether. If this is implemented as a technical control (for example, by using iframes with Content Security Policy and sandbox restrictions), then such attacks should become impossible to carry out against modern browsers.

The most recent attacks have taken place over the past 12 months, after eBay had responded to 'previous reports' of JavaScript-based attacks, when it claimed not to have found any fraudulent activity stemming from these cross-site scripting vulnerabilities.

In some cases, it could be that eBay is simply unaware of the fraud it is facilitating. When one customer phoned eBay Trust & Safety to report these redirect attacks, the eBay handler was unable to see the redirection due to security settings on their internal systems. Consequently, reporting such vulnerabilities to eBay can prove frustrating, as well as fruitless: When Jaco posted a similar warning to the eBay Motors community forum, he claims his message was quickly deleted.

A year ago, we predicted that it would be difficult to prevent this type of fraud when listings are still able to include arbitrary JavaScript. With these recent attacks proving eBay's interim measures are still insufficient to prevent abuse, only technically-enforced controls on the execution of JavaScript will finally put a stop to this fraud.

The Chancellor of the Exchequer sets out plans for the UK Government to work with Netcraft

Secretary of Defense Chuck Hagel hosts on honor cordon for United Kingdom's Secretary of State for Defense Phillip Hammond at the Pentagon May 2, 2013 (Pic 3)

Philip Hammond, Chancellor of the Exchequer.

Netcraft is in the news today after the Chancellor of the Exchequer announced plans to work with us to develop better automatic defences to reduce the impact of cyber attacks affecting the UK.

There is coverage in the Independent which says "Mr Hammond will set out plans to work in partnership with firms such as internet security company Netcraft to develop better automatic defences", ARS Technica notes "Number 11 said it would work closely with industry partners such as Bath-based Netcraft" while TechCrunch observes "One company the government is highlighting here is Netcraft for “automated defence techniques to reduce the impact of cyber-attacks.”"

Her Majesty's Government's own announcement outlines Netcraft's role in the cyber security strategy:

The strategy sets out how government will strengthen its own defences as well as making sure industry takes the right steps to protect Critical National Infrastructure in sectors like energy and transport. We will do this through working in partnership with industry - including companies such as the innovative SME Netcraft - to use automated defence techniques to reduce the impact of cyber-attacks [...]. Previously a website serving web-inject malware would stay active for over a month- now it is less than two days. UK-based phishing sites would remain active for a day- now it is less than an hour. And phishing sites impersonating government’s own departments would have stayed active for two days - now it is less than 5 hours.