Security researcher ioerror has discovered a suspected Certificate Authority compromise. This may allow an attacker to impersonate a high-value website by presenting a fraudulent SSL certificate which nonetheless satisfies a browser's validity checks:
"A Certification Authority appeared to be compromised in some capacity, and the attacker issued themselves valid HTTPS certificates for high-value web sites. With these certificates, the attacker could impersonate the identities of the victim web sites or other related systems, probably undetectably for the majority of users on the internet."
ioerror discovered the compromise last week, but responsibly offered to embargo his findings until the launch of Firefox 4. Mozilla yesterday announced that it had revoked these fraudulent certificates and updated Firefox 4.0, 3.6 and 3.5 to recognise the fraudulent certificates and block them automatically.
ioerror found 11 revoked certificates, which he believes could indicate a compromise at USERTRUST:
"This is evidence of a rather serious event and one that cannot be ignored. If I had to make a bet, I'd wager that an attacker was able to issue high value certificates, probably by compromising USERTRUST in some manner"
Furthermore, ioerror suggests that many users are probably still updating and therefore remain vulnerable to "the failure that is the CRL and OCSP method for revocation."
Mozilla revealed that addons.mozilla.org was one of the certificates acquired by the attacker, and ioerror called upon Comodo to disclose which other sites had been targeted.
Two years ago, a Comodo reseller erroneously issued an SSL certificate to an unverified party. Eddy Nigg demonstrably exploited a lack of validation by Certstar in order to obtain a legitimate domain-validated certificate for mozilla.com – a domain he did not own.
After confirming a security breach to its customers yesterday, Play.com today suggested that email marketing company Silverpop may have been responsible for the leak which resulted in spam being delivered to Play.com customers.
In a statement sent to Netcraft, John Perkins, CEO of Play.com, said:
"We believe this issue may be related to some irregular activity that was identified in December 2010 at our email service provider, Silverpop. Investigations at the time showed no evidence that any of our customer email addresses had been downloaded. We would like to assure all our customers that the only information communicated to our email service provider was email addresses. Play.com has taken all the necessary steps with Silverpop to ensure a security breach of this nature does not happen again."
Following the attacks in December 2010, Silverpop posted some details of its forensic investigation on its blog.
Several Play.com customers have speculated whether any other personal data may have been compromised, while the Sophos blog recommended that customers change their passwords. However, Play.com offered some reassurance by confirming that no other personal data has been compromised:
"We would also like to reassure our customers that all other personal information (i.e. credit cards, addresses, passwords, etc.) are kept in the very secure Play.com environment. Play.com has one of the most stringent internal standards of e-commerce security in the industry. This is audited and tested several times a year by leading internet security companies to ensure this high level of security is maintained. On behalf of Play.com, I would like to once again apologise to our customers for any inconvenience due to a potential increase in spam that may be caused by this issue."
In a separate statement, Silverpop confirmed to Netcraft that it had notified all customers impacted by the cyber attack in 2010 and worked with the FBI to help identify those responsible.
Following our previous article about an apparent email address leak at Play.com, the company has confirmed that a security breach has occurred.
In an email to its customers, Play.com stated that the breach occurred at a marketing company, resulting in customer names and email addresses being compromised:
"We are emailing all our customers to let you know that a company that handles part of our marketing communications has had a security breach. Unfortunately this has meant that some customer names and email addresses may have been compromised.
We take privacy and security very seriously and ensure all sensitive customer data is protected. Please be assured this issue has occurred outside of Play.com and no other personal customer information has been involved."
An information security manager at Play.com refused to tell Netcraft which marketing company was responsible for the breach.
Online retailer Play.com has been accused of leaking its customers' email addresses to spammers.
Many customers reported receiving a spam email yesterday, offering an Adobe Reader upgrade which requires registration and payment. Some of these emails were sent to unique email addresses that have only been used at play.com, suggesting that the spammer had access to private customer details.
Most complaints relate to an email with the subject line "Get more done, much faster, with Acrobat X PDF Reader. Upgrade Available Now":
One Play.com customer commented yesterday:
"I too received the email this morning. I use a unique email address for each website using the plus addressing feature of gmail; in this case the phishing attack was sent to email@example.com. This is pretty compelling evidence that play.com are at fault."
Another recipient of the spam was advised the following by Play.com:
"Please be advised that our database is maintained on a secure internal server that is not connected to the internet. No unauthorised access of any kind is available to the network."
Fortunately, most browser software has already blocked the spammer's website as a web forgery:
If the user chooses to ignore this warning, the site offers a download link for PDF Reader/Writer software:
The user is then taken to a third-party site, secureonline-form.com, which requires registration:
Finally, the user must pay for membership in order to obtain the software:
Play.com did not respond to Netcraft's request for comment before this article was published.
Earlier this morning, GitHub announced that it had changed its revision control website to use SSL only; however, a significant flaw in the implementation means that session cookies can still be captured by Firesheep and other network sniffing tools.
Firesheep brought session hijacking to the masses when it was released last month. Ironically, its own GitHub repository includes a github.js handler, which was designed to capture unencrypted session cookies from GitHub users. This allowed novice attackers to monitor shared network traffic (such as public WiFi) and hijack those sessions.
A day after its release, Firesheep's author stated that a basic expectation of privacy should not be a premium feature, referring to the fact that, at the time, you had to pay GitHub if you wanted to use full-session SSL. GitHub's move to SSL this morning should have eliminated the session hijacking vulnerability, rendering Firesheep useless; however, the session cookies used by the site are not always handled securely.
When a user logs in to GitHub, the server sets a
_gh_sessession cookie in the client browser. This cookie is not marked with the Secure flag, which means it will be transmitted unencrypted if the user subsequently visits http://github.com, even though that page immediately redirects the user to https://github.com. This means the site's users may still be vulnerable to sniffing tools such as Firesheep.
Netcraft successfully hijacked a session from the GitHub site by sniffing the cookies that were sent via unencrypted HTTP. Many legacy URLs will still point to the HTTP version of the site, so an attacker may not even need to entice a victim into visiting the HTTP site. Once a session has been hijacked, the attacker can freely create repositories, delete/add email addresses and change passwords, so it looks like the sidejack prevention that GitHub implemented a week ago (which did use a Secure cookie) has been undone.
Although GitHub's move to SSL has not yet been implemented securely, it is at least a step in the right direction for Firesheep's author, Eric Butler. When he released the tool on 24 October 2010, he said:
Websites have a responsibility to protect the people who depend on their services. They've been ignoring this responsibility for too long, and it's time for everyone to demand a more secure web. My hope is that Firesheep will help the users win.
GitHub announced the SSL-only change on Twitter this morning, and is expected to publish a blog post about it soon.
GitHub has since fixed the session cookie to be secure. Now that it can only be transmitted over encrypted connections, this makes the site invulnerable to Firesheep.
A years-old vulnerability has been brought into the limelight by an open source FireFox extension which makes it extremely easy to hijack sessions belonging to other Web users on shared networks.
Eric Butler's Firesheep tool makes it remarkably simple for novices to hijack sessions on several social networking sites. Firesheep monitors network traffic and detects when someone visits a website which transmits unencrypted session cookies. The victim's name and photo is displayed by the tool, and double-clicking on that person instantly logs you in as them.
Even though these session hijacking vulnerabilities have been possible for many years, the sheer user friendliness of this new tool is causing a storm of comments on Twitter. No specialist hacking knowledge is required to use the tool – all you need is to be on the same network as your victim. Sending unencrypted data over open WiFi networks has always posed a security risk, and the release of this new tool greatly increases the likelihood of exploitation.
Online banking services typically employ HTTPS throughout an entire session, keeping the session cookies encrypted and thus hidden from eavesdroppers. Due to the computational overheads of providing HTTPS connections, many other websites reserve this secure protocol only for transmitting login credentials, after which the user would continue to use the website over an unencrypted HTTP connection. This is the weakness which allows Firesheep to work, as it makes the session cookies vulnerable to eavesdropping. This type of vulnerability is commonly discovered during Netcraft's security tests, and Butler's new extension greatly simplifies the process of exploiting it on a range of popular sites.
In recent years, the computational overheads of HTTPS have become less significant due to the continual improvements in computer hardware, so more and more sites are beginning to adopt HTTPS for the entire lifetime of a user session. For instance, Google introduced an "always use HTTPS" option on their widely used Gmail service in 2008, before eventually making this the default setting at the start of 2010.
Butler announced Firesheep at the 12th ToorCon conference. The extension already allows session hijacking vulnerabilities to be exploited against 26 different sites, including Facebook, Flickr, Twitter and WordPress. Additional sites can be monitored simply by adding a new script to its existing list of handlers.