LJ security holes

The recent change to LJ’s URL formats seems to be part of an attempt to defend against one or more attacks which allow the attacker to steal another LJ user’s credentials, gaining the ability to impersonate that user. The theft occurs when the victim visits a page on LiveJournal which contains some malicious Javascript inserted by the attacker (more technical details below for those that care).

What’s been happening?

Slashdot linked to an article with some more details on the attacks. This article includes details supplied by the Bantown group (who live at bantown.com, a site you probably want to visit using lynx). Bantown have use these attacks to pwn LiveJournal quite comprehensively: the comments on the news entry contained comments from tens of different users with the same demand from Bantown. It’s likely that these users all had their credentials stolen by Bantown.

I found a comment quoting an explanation of the vulnerability in an entry on lj_dev, but that entry has now been deleted. The quoted explanation is about a vulnerability which only applies to browsers based on Mozilla (so, Mozilla, Firefox and Netscape). The Bantowners claim that this is not the vulnerability they were using, as they have a vulnerability which affects all browsers. LJ recently patched a vulnerability which would do the job for all browsers, but it’s possible there are other, similar, vulnerabilities in LJ’s code. Or it’s possible that the Bantown people are lying.

Is it fixed?

LJ went down for a while on Friday afternoon, and seems to have invalidated all existing cookies. However, bradfitz is keeping quieter than I’d like about whether the risks still exist and about what workarounds users can use while LJ’s crack programmers are working on a fix. bradfitz‘s use of “soon” suggests that the URL change was part of further changes. These further changes aren’t in place as I write this, which I think means that it’s still possible to use whatever attack the Bantowners have been using to steal credentials, although it’s not possible for an attacker to use an old set of credentials from logins before this afternoon.

Edited: LJ has now fixed this, so it’s safe to turn Javascript on again.

What can we do about it?

For now, I’m running with No Script turned on, and using that to disable Javascript for all but trusted sites, of which LJ obviously isn’t one. LJ’s lack of communication about the risks to user data, and about possible workarounds, displays a worrying incompetence, as I’ve said elsewhere.

The Science Part

LJ uses cookies, small pieces of data stored by your web browser, as your credentials. When you log in to LJ, you get a cookie. From then on, your browser presents the cookie whenever it requests a page from LJ. LJ trusts you because you have the cookie, and lets you do things that only you should be able to do. The cookie can persist just until you close your browser, or longer if you’ve ticked the “remember me” option when you log in.

The attacks on LJ are cross-site scripting or XSS attacks. A Javascript running on a particular page can access the cookies for that page. Currently, any Javascript running on an LJ page can see your cookie, because the same cookie applies to the entire site. If an attacker can cause their own Javascript to run on a page supplied by LJ, they can steal that cookie and send it to a remote server that they own.

How might the attacker get their script onto LJ’s pages? Well, LJ lets you submit HTML as entries, comments, and as your own styles, and then displays it on its pages. LJ attempts to sanitise the HTML you supply it, but if it doesn’t do this correctly, the attacker has a way in. They can put their Javascript on the page, and visiting that page would then send your cookie to their server. Also, browsers based on Mozilla (such as Netscape and Firefox) allow stylesheet authors to embed Javascript in a CSS stylesheet, so the way LJ lets users reference their own external stylesheet is another security hole (although as I said above, it’s possibly not the one that the Bantown people are using).

There’s some more discussion of how this works (in amongst a lot of sarcasm) in this thread on jameth‘s journal.

10 Comments on "LJ security holes"


    1. …which is what LJ should have told everyone to do when this first came to light. It’s not like they were losing anything by doing this: if we believe the Bantown people, they were already using the flaw to gather cookies, and had been for a while.

      Reply

    2. Wouldn’t binding your login to your IP safeguard against this? If you’re using broadband it’s not likely that your IP changes much.

      Reply

      1. It’d safeguard against someone taking your cookie and using it at a later date (which seems to be what the Bantown people have been doing). It wouldn’t safeguard against someone using their ability to do Javascript stuff with the cookie, I suppose: presumably they could pop-under a window which would start deleting all your entries, for example.

        Reply

  1. I’m kind of confused When you said to visit their site using lynx was a good idea I assumed they had all sorts of obnoxious graphics and other things like that. But it seems to be just text based. Has it been changed? Or am I missing something?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *