Over the last few months, many people have talked about using HTTPS with sites such as Facebook and Twitter. The technology came up often after the release of Firesheep, which allowed Wi-Fi users to hijack other users who used these sites without HTTPS.

Part of the technology behind HTTPS are certificates – small electronic files that help your browser ensure it’s connecting to a trusted site and protect the connection from eavesdropping or tampering. For instance, when you visit https://www.google.com, the Google server has a certificate that lets your browser know it’s connecting to Google and not an impostor.

But how does your browser know if the certificate is not also from an impostor? Each browser maintains a list of certificate authorities, or CAs – special servers whose main purpose is issuing certificates for all those HTTPS websites. These CAs may also vouch for other authorities, creating a hierarchy of trust. If you access a site whose certificate is not from one of these authorities or has been marked by one of them as revoked, you’ll get an error or warning about a certificate problem. Ideally, all of the authorities are all trustworthy and only issue certificates for reputable websites.

Unfortunately, the current reality is less than ideal, and attacks can happen. Yesterday, a blog post from the Tor Project detailed research showing that two major browsers had quietly added code which blocked a few specific certificates. These certificates were issued by an authority in a hierarchy controlled by Comodo, who released a statement today providing a bit more information on what happened.

According to Comodo, attackers were able to access the account of a user who helped manage one of the servers for issuing certificates. They then created their own certificates for verifying websites from Google, Yahoo, Skype, and others. These fraudulent certificates could be used to make a user’s browser think it was connecting to legitimate sites when actually communicating with a malicious site.

Comodo stated that many of the attacks appear to be from Iran, and has said they believe the attack to be state-driven, but many details are still unknown at this point, and the situation calls into question several aspects of Comodo’s security policies. In the meantime, you should make sure you’re using the latest version of a modern browser, such as Chrome or Firefox, and avoid connecting to untrusted networks. The fraudulent certificates that have already been identified will be blocked by an updated browser, and we’ll have to wait and see if more fallout results from the attack.

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.

If you’re interested in online security, you’ve probably heard about HBGary.

If you haven’t, here’s a brief rundown with a few links:
A security firm, HBGary (or, more accurately, HBGary’s subsidiary HBGary Federal) announced that they had discovered the names of some of the supposed ringleaders of the “hacktivist” organization Anonymous.
This “angered the hive” and – rather than the generally low-risk and unsophisticated DDOS attacks for which Anonymous is better known – Anonymous used a combination of social engineering, SQL Exploits, and password cracking to compromise one of HBGary’s servers. They leveraged that to get into multiple servers, ultimately gaining access to HBGary’s email and no few internal documents – including business plans and proposals to potential clients.
Anonymous then published the information they found – all of it. This embarrassed and scared off most, if all, of HBGary’s potential clients, ruined ongoing negotiations, and exposed activities which indicated questionable ethics and which might be illegal.
HBGary’s actions after this compromise might charitably be called “unfocussed” or possibly “unplanned”. “Foolish” or “Crazy” would possibly be more accurate. The HBGary CEO even engaged with some Anonymous members via IRC, to dubious results. Perhaps the best testament to this incident is the current state of HBGary Federal’s website.

Remarkably, there aren’t any new lessons to be learned here.
HBGary Federal’s first mistake was in taunting Anonymous: no matter how secure you think you are, you’re better off WITHOUT people trying to break down the gates.

The second mistake was in underestimating the enemy. Although Anonymous as a group has mostly engaged in DDOS attacks, they did so using a modified version of a professional load-testing tool: clearly some of their members have always had access to such tools and the ability to modify them. In other words, at least some of Anonymous are clearly highly capable.

The third mistake – or rather, set of mistakes – was likely the most common. HBGary’s infrastructure wasn’t properly secured. They were vulnerable to social engineering, and an important server could be compromised with an SQL injection exploit, and – worst of all – the attackers were able to use that one compromise to access nearly everything else. This is not a very good security posture, especially for a security firm.

Lastly, they didn’t have a recovery strategy. While this sort of compromise is one of the worst-case scenarios, it clearly behooves a company to plan for it, at least in a general fashion, and respond in an organized fashion which helps rebuild client trust and reduce the damage.

While these aren’t new lessons, it’s still worthwhile to look them over again: don’t encourage attacks, maintain a realistic awareness of the attackers you’re facing, harden your infrastructure, and have a recovery plan. Remember that it CAN happen to you, and act accordingly.

The discussion around the usual suspects of web application security (XSS, CSRF, injections, etc) hasn’t changed much in the last decade. Even high-profile website security incidents that get media attention often boil down to a clever application of one or more of these “basic” vulnerabilities. Part of the reason these techniques don’t seem to go out of style is a result of the speed at which the underlying technologies emerge.

In other words, as technology changes, the vulnerabilities enabled by that technology also change. With the quick rise (and rapid acceptance) of HTML5 as the next generation markup language, we are sure to see some interesting new ways that web apps can be bent and broken or otherwise convinced to do things they were not originally designed or developed to do. Indeed, HTML5 seems to be somewhat of a new frontier when it comes to web security. Like its predecessor, each browser rendering engine has its own way of interpreting and displaying HTML5 data. Developers seeking to fully secure their applications would need to account for users that may have HTML5-enabled browsers. Lack of familiarity on the developer’s part can result in unexpected vulnerabilities that are easily overlooked or difficult to detect.

The HTML5 Security Cheatsheet is a resource that shows some things to watch out for when you’re working with HTML5, and should be useful to both developers and regular users.

Also, it’s important to point out that not all unintended uses of a new technology are malicious in nature. Who knows– maybe some HTML5 hack will push future web innovation to new heights. At the very least, it could add some variety to the global discussion on web application security.

I received the following email on Monday morning:

You don’t know me.  I’m nobody.  My name is Steve.  I came across a database dump from Gawker.com earlier this evening.  It’s making its rounds around the internet.  Besides just the code dump from gawker.com among other sites, it also contains email addresses and passwords for over 1.3 million accounts.  I’m sending this email to the 200,000 or so people who’s passwords were included, in plain text, in this archive.  I have your password.  However, I have 0 interest in it.  Obviously i’m anonymous so how can you trust me – you can’t.  But trust me, if I had interest in your password, I wouldn’t be emailing you saying I have it. That’s just dumb.  The reason I’m telling you this is because people all over the world, who aren’t like me, who won’t notify you, have it.  They will use and abuse it.  Change your gawker.com credentials. Now.  MORE IMPORTANTLY, change passwords on other sites you visit that use the same one as your gawker.com/lifehacker.com/gizmodo.com login.

Well, it was believable enough… then, I read an article on Forbes and knew it wasn’t a scam. Argh. To their credit, Gawker has some informative posts on their breach and how to audit and update passwords.

As background: I use a password manager to manage my passwords, and it helps me use secure passwords wherever possible. However, I have a number of passwords which predate my use of a password manager, and for many sites I used the same password. Yes, it’s a bad security practice that we’ve talked about before, and even XKCD has weighed in.  The use of this same password didn’t bother me – it was my password for using on sites that I considered “low impact”. In other words, I didn’t feel like it was a big deal if that password was compromised.

Receiving that email, along with a notification from Google that my account had been locked out, was a wakeup call. Suddenly, it became a big deal to me.

So, I spent this evening going through my password manager’s records. I have 507 saved passwords.  I had nearly 150 with the same password.  I changed every one of them to a randomly generated password.  It took me over three hours to go through that process.  A tremendous hassle. Let me suggest from experience: change those passwords you use on many sites.  If you try to do them all at the same time, it will be a tiring and painful process.

One of the most common vulnerabilities in web applications is known as HTML injection or cross-site scripting, and one of the simplest ways of showing such a problem exists involves loading a JavaScript alert dialog. Those who understand the ramifications of such an issue know that it creates the potential for far more malicious activity, but the alert box is an easy demonstration that the application can be automatically manipulated.

Other vulnerability, though, may be more subtle and not as readily visualized. Take cross-site request forgery, for example. It’s easy to understand that there’s a problem when an application lets you manipulate the data of other users – the site should validate the account making requests before executing them. What may not be so obvious is that problems can still arise even when the application checks the account first. If no system exists for verifying that the account owner actually intended to perform a given action, it may be possible to hijack that user’s session and make requests without them knowing. The technical term for this behavior is cross-site request forgery.

(more…)

Back in January, Google announced they would pay between $500 and $1,337 for bugs in their Chromium web browser code, if the discoverer first reported it privately to them and followed certain conditions. Since then, the company has handed out quite a few bounties to security researchers who found problems.

Now, Google has expanded the program by offering similar bounties for vulnerabilities in their web-based applications. Hackers who find issues such as HTML injection or cross-site request forgery in important Google services can now report them and possibly qualify for rewards ranging from $500 to $3,133.70. As with the Chromium bounties, bug hunters have to follow a few rules and conditions, such as giving Google some time to fix the issue before public disclosure.

Given the success of the Chromium bounties, it’s likely this new experiment will be beneficial both for security researchers and Google’s users. It certainly adds an interesting new twist to the debate over how to handle outside bug discoveries – perhaps we’ll see more companies offering such compensation in the future.

You may have seen Ben’s post earlier this week on Firesheep. I am running a Mac and I use FileVault, as I recommend most people do in order to protect their sensitive files.  Unfortunately the current release of Firesheep does not support FileVault.  That didn’t stop me, here is what you need to get Firesheep running on Firefox 3.6.x on a Mac running FileVault from start to finish.

1. Download the Firesheep .xpi file here.
2. Drag the .xpi file into your Firefox browser window to install it, then quit Firefox.
3. Move the extension folder from your user account to the application folder.  The /Users/[youraccount]/Library/Application Support/Firefox/Profiles/[yourprofile]/extensions/firesheep@codebutler.com folder should be moved into the /Applications/Firefox.app/Contents/MacOS/extensions folder.
4. Relaunch Firefox, and you should be good to go.  If you receive an error related to “–fix-permissions”, make sure you moved the folder (and didn’t copy it), and if it still didn’t work try running once as root (sudo /Applications/Firefox.app/Contents/MacOS/firefox-bin).

Enjoy. Use responsibly. And encourage your local coffee shop owner to turn on WPA2 to limit its usefulness.

Once upon a time, the Web was filled with static pages of text, hyperlinks, and the occasional image. Security problems existed even back then, but the pages themselves were generally innocuous. As the years went by, however, the Web became a platform for all sorts of communications and services. In time, the mild-mannered web page became a delivery mechanism for large-scale, dynamic applications. Even mobile browsers now include engines for loading powerful object-oriented programs. As the capabilities of websites expanded, the problem of HTML injection, or cross-site scripting (XSS), became a significant threat. Check any recent research on web-based threats, and you’ll find that this type of vulnerability is widespread online. And if the past few weeks are any indication, we can expect more trouble in the future.

HTML injection itself is hardly a recent issue, but current trends make it more common and more dangerous. In particular, the rise of user-generated content and “mashups” has led to far more data being shared across security contexts in real-time. One example made headlines last week after a few Twitter users discovered they could manipulate the site’s system for parsing links within a post to add custom HTML. Several tweets crafted to exploit this issue spread virally, as an action as simple as moving your mouse could trigger code that would post the same tweet under the victim’s account. Twitter’s entire product relies on user-generated content, but a simple filtering problem led to the rapid spread of XSS worms. Fortunately, none of these cases appeared to be that malicious.

In the realm of mashups, many sites are adding code to integrate with Facebook, providing users a single sign-on experience. A few websites have access to “instant personalization,” a feature that lets the sites identify Facebook users when they first visit rather than after clicking a login button. Soon after Facebook announced this program, a security researcher discovered that one of the partners, restaurant review hub Yelp, had an HTML injection vulnerability. With the addition of Facebook’s code, Yelp’s hole could be exploited to let an attacker automatically identify Facebook users as well. More recently, two new partners were added to the program: Rotten Tomatoes and Scribd. Soon after the announcements, similar problems were found in each of these sites. Ironically, Rotten Tomatoes’ pages were generally secure against HTML injection, but a third-party widget loaded by the site introduced a vulnerability.

HTML injection on one site threatens information and actions available to users of that site. But with so many websites sharing data between users and other companies now, one vulnerability may allow access to multiple services. And the problems don’t stop with the browser – injected code can try exploiting other issues that lead to compromising a user’s operating system. Meanwhile, the spread of mashups shows no signs of slowing. In fact, this past week Facebook’s COO Sheryl Sandberg predicted that within a few years, nearly all websites will automatically adapt to a visitor’s interests. Yet that sort of functionality requires identifying a visitor’s interests somehow, and Facebook’s instant personalization is one example of how that’s possible.

Securing a Web with so much data getting passed around is not an easy task. Douglas Crockford, a leader in the JavaScript community, has recently advocated that browser makers stop work on HTML5 and instead focus on building a more secure framework for handling scripts. Yet it’s more likely we’ll see a universally personalized Web before we see such functionality become mainstream, meaning web developers need to keep paying close attention to possible HTML injection issues. Preventing such vulnerabilities in an application would require more than a simple blog post, but fortunately many resources exist online, and the team at Gemini is ready to help you secure your code. In the meantime, I hope that the buzz about Twitter’s worms and problems with instantly personalized sites help draw more attention to HTML injection as the Web continues to expand. Hopefully future developers will learn from these stories and reduce their frequency in the future.

Teensy is an interesting device.

Not much larger than a quarter, the technology behind it is comprised of a micro controller and other associated electronics (memory, I/O, etc). The result is a very functional, yet flexible, USB thingamabob that can let people program their own logic to run their own routines, commands, and instructions.

Teensy was recently used in a unique demonstration of some interesting security implications that arise from exploiting the USB-to-OS trust relationship. By programming Teensy to identify itself as a keyboard, someone could trigger it to send automated keystrokes at will (or set via timer).

But this has been possible for years. In fact, for this example in-particular, it’s probably desirable for users to not have to do any real configuring to get their keyboard or mouse to work. Perhaps the underlying issue is that many vulnerabilities are introduced when trying to balance convenience with security.

But the flip side might be that real change is coming from the other direction. As technology evolves, it gives attackers more tools with which to express their creativity. A few short years ago, programming logic into a USB device like this might have cost a few hundred dollars of equipment and a good amount of coding, just to do something simple.

Teensy is dirt cheap and there is a software library already written for it. This makes it easy to jump right in and start making stuff because the barrier to entry for this vector has been lowered by better technology. As a tool, a device like Teensy offers potential that is only limited to what the creative individual can fit into the on-board flash memory module. In a way, the bad guys get new toys, while the good guys just get more stuff to patch, secure, and protect against.

And that’s not… a teensy problem.