A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider’s transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections – 17 USC § 512, from the Cornell University Law School

No business is an island. There’s no company that does not, to some extent, rely on other businesses. Business models assume that vendors will be able to assure a steady flow of goods, that retailers will sell goods and pay as contractually bound, that shippers will actually ship goods, etc. Our legal system is filled with assurances to that effect. And this is important, because it gives companies confidence to make such agreements. Knowing that business partners can in fact be bound and trusted to perform their duties, companies can more readily act to grow and increase their revenues. The key component here is confidence – a certainty that once a contract is signed, it will be followed.

That’s what makes the MegaUpload case rather disturbing. There’s no doubt that MegaUpload was hosting infringing content. However, the content was not all infringing – but all of it was taken down. Right now there is a case and the hosting company, Carpathia, is seeking court action which would allow it to release the existing data back to MegaUpload users.

However, in a way, the damage has already been done. Whatever the outcome of the case itself, one message has been sent clearly: your data can be held hostage by others’ data. That’s sure to have a chilling effect on the hosting industry for years to come.

As you’ve doubtless heard, Sony’s PlayStation Network has been down for several days now. The exact cause of this outage, being apparently affected by hackers of some stripe, is doubtless worth investigating. However, since those details haven’t been fully divulged yet, it’s best to wait on that front.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

Earlier today, news began to spread about an exploited certification authority (CA) spotted in the wild. The Tor project blog has an excellent write-up on how they detected the presence of patches blocking particular SSL certificates and worked backwards to determine that a Comodo issuer had been compromised. The folks at Tor suppose (rightly) that if people who monitor the patches for Firefox and Chrome hadn’t noticed, this entire incident might have been swept under the rug. Since that time, Comodo has come clean with an incident report which describes in detail the certificates that were issued and even states

 All of the above leads us to one conclusion only:- that this was likely to be a state-driven attack.

I am not as convinced – I think it might have been referenced more to try to deflect interest and speculation away from their own poor management. Also, I would think that a state attack would be more involved than a simple username and password.

Yes, Comodo notes in a separate blog post that the compromise was related to the theft of a username and password of a registration authority (RA) account. I was shocked to find out that their registration authority users are able to log in with a username and password, and not requiring a more secure method of login (for example, public key infrastructure (PKI) login with a smart card). I took a look at the Comodo Certification Practice Statement (CPS) and found that “Trusted roles” (section 3.10.1) should in fact require it. The CPS states (for Trusted personnel) “Identification is via a username, with authentication requiring a password and digital certificate.”

Of course my first issue is with the semantics of the statement.  Presenting a digital certificate is not authenticating anything because digital certificates are public information; one must prove the possession of the private key corresponding to the digital certificate to be authenticated.

My second issue is that it is not clear in the CPS whether an RA would actually be a “Trusted role” or not. In section 3.9.3 they indicate the following:

All personnel in trusted positions handle all information in strict confidence. Personnel of RA/LRAs especially must comply with the requirements of the English law on the protection of personal data.

To me, this reads that personnel of RA/LRAs are “personnel in trusted positions” and therefore should qualify for the “Trusted role” in their CPS, which would have required certificate-based login. Unfortunately, I cannot find any more definitive statements in the CPS that would put the RA into or out of the “Trusted role” as defined.

Ultimately, I hope this compromise will help Comodo improve their practices and update their policies. Most organizations that run a PKI (whether internal or external) know that RAs should always be considered a trusted role in a PKI. The RA’s role is to direct the actions of the CA, the entity that issues the certificates and certificate status information. These certificates, in turn, allow us to trust transactions between parties (such as SSL sessions). If the RA is not trusted, then nothing in the PKI should be.

As you might have heard, the IPcalypse is nigh. Okay, maybe you haven’t heard. The IPcalypse refers to the sale of the last IPv4 addresses on the open market. We’re projected to run out within the next few days. How will this affect you?

Odds are it won’t. Not in the short term, at any rate. Imagine if the post office announced that they’d run out of street addresses. All of the existing houses would be fine, and still be able to receive mail. New houses wouldn’t get addresses, though, and would be unable to send or receive mail. Running out of IPv4 addresses is like that.

Of course, it’s somewhat more complicated. Whereas you can still build a house without a postal address, still live there, still have people come over – well, imagine if you need an address to access the road. Without an IP address, a computer is cut off from the internet. It can neither send nor receive data; it’s just a standalone device.

But there remain options. Plenty of them, in fact.

(more…)

A new problem has been uncovered that allows an attacker to obtain encrypted session cookies or other encrypted/protected data stored on any version of ASP.NET from Windows XP to Windows 7 and 2008 R2.  When properly exploited, the attacker gets full administrative rights to the application and gets access to files such as the web.config file which often stores sensitive information and passwords.  From ComputerWorld:

Hackers can exploit the vulnerability by force-feeding cipher text to an ASP.Net application and noting the error messages it returns. By repeating the process numerous times and analyzing the errors, criminals can learn enough to correctly guess the encryption key and thus decrypt the entire cipher text.

It will take some time for Microsoft to patch this problem across all platforms.  It is possible to update your application to be immune to this attack, and I recommend patching your application as soon as possible.  From Scott Guthrie of Microsoft:

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page – regardless of the error encountered on the server…

Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need to make sure that all errors are configured to return the same error page.  This requires you to explicitly set the “defaultRedirect” attribute on the <customErrors> section and ensure that no per-status codes are set.

This link has detailed instructions on how to protect against this attack in each platform. Happy patching.

Les Jordan from Microsoft recently wrote a blog post entitled Identity Management: a key to seamless CTMS and EDC. In it, he presents some of the solutions Microsoft is introducing in the identity management space, currently under the name of Microsoft Geneva including the Geneva Framework, and the Microsoft Identity Federation Gateway.

The idea is fairly simple. Many (most?) large enterprises already manage their users and systems using Active Directory.  Geneva allows publishing the components of your Active Directory required for doing identity federation on the Internet.  The publishing is performed in a standards-compliant way (using WS-* and SAML 2.0) and allows it to be used for claims between enterprises.

…the issue of Identity Management, Username and Password proliferation, and cross-company collaboration is an issue that has hindered true (and secure) data availability and collaboration in the Life Sciences industry.  Perhaps now we can get the Identity Management issue behind us and move on.

Whether or not Geneva becomes the one standard way to allow interoperable identity management across multiple enterprises in the life sciences space, it is clearly going to lower barriers between organizations and increase our trustworthiness in digital identities.

Adobe has created a survey on their Security Matters blog with a survey for digital signature users to complete.

If you have (and use) an electronic signature credential, and are interested in helping Adobe craft the next generation of Adobe Acrobat, Reader, and LiveCycle products and signature features, we are offering you the ability to participate in an Electronic Signature Survey.

Might be worth filling out, if you want to have a chance to influence the next round of Adobe products, such as Acrobat.

Hot on the heels of a Flash Player critical vulnerability, Adobe has released a security bulletin outlining a critical vulnerability in all Adobe Reader and Acrobat versions prior to version 8.1.3.

Critical vulnerabilities have been identified in Adobe Reader and Acrobat 8.1.2 and earlier versions. These vulnerabilities would cause the application to crash and could potentially allow an attacker to take control of the affected system.

Acrobat and Reader version 9 is not vulnerable to these particular flaws.  A few interesting things to note here. No patch for Acrobat/Reader 7 and earlier has been released. Additionally, the update is available only by moving to a new version of Acrobat/Reader, either version 8.1.3 or 9. This may cause significant pain and stress among organizations that have standardized on Acrobat or Reader, especially in FDA validated systems.  This is because Adobe has not made it possible to just apply a security update patch to the affected software.  Instead, organizations must deploy a new version, which may contain additional changes including a changed user interface, changed behavior, and changed compatibility.  Therefore, I expect some organizations may choose to live with the risk rather than move into a new version, and have to re-document and re-validate processes according to an updated version of Acrobat or Reader.

Adobe has released an advisory about a series of critical vulnerabilities in flash player 9.0.124.0 and earlier.  The fix is to install the just-released flash player 10.0.12.36.  The interesting thing is that the architecture of some security related things has changed wholeheartedly with player 10 – so things that used to work with 9, may stop working with 10.

Potential vulnerabilities have been identified in Adobe Flash Player 9.0.124.0 and earlier that could allow an attacker who successfully exploits these potential vulnerabilities to bypass Flash Player security controls. Adobe recommends users update to the most current version of Flash Player available for their platform. Due to the possibility that these security enhancements and changes may impact existing content, customers are advised to review this Adobe Developer Center article to determine if their content will be impacted, and to begin implementing necessary changes immediately to help ensure a seamless transition.

The bulletin is here, and the updated player is here.  Happy patching!

From DarkReading.com:

With all the talk about hackers launching attacks from legitimate Websites, you’d think that the major security vendors’ sites, at least, would be vulnerability-free.

Not so, according to a report issued yesterday by a security watchdog site.
The site, XSSed, states that it has verified some 30 cross-site scripting vulnerabilities spread across the Websites of three of the industry’s best-known security vendors: McAfee, Symantec, and VeriSign. The vulnerabilities could make it possible for attackers to launch phishing campaigns from these sites or even distribute malware to the companies’ customers, according to XSSed.

Cross-site scripting vulnerabilities aren’t a new type of threat, and they aren’t particularly difficult to defend against. It seems a little crazy that the companies that many people depend on to help them get a handle on security don’t practice the things that they preach. Or then again, maybe they don’t even preach them:

This isn’t the first time that XSS vulnerabilities have been exposed on sites such as McAfee’s and Symantec’s, notes Jeremiah Grossman, CTO of WhiteHat Security. Back in January, XSSed reported that some 60 sites that had received the “hacker safe” label from McAfee’s ScanAlert service were vulnerable to XSS attacks. (Emphasis added)

I disagree with Grossman’s conclusion, however, that the XSS vulnerabilities on these security companies’ web sites aren’t something to worry about. His argument is that, while these are security companies, they primarily focus on anti-virus and anti-malware software. However, when these companies start handing out “Hacker Safe!” badges to other web sites (which, in my opinion, is like throwing rocks at a beehive), they put themselves in an arena in which things like simple XSS vulnerabilities cannot be overlooked. I believe that the “more important” sites that are mentioned, such as bank and e-commerce web sites, are really unlikely to have their security problems taken care of before the people that are supposed to “know security” do.