Inside the LiveJournal Worm
On Wednesday morning, LiveJournal was hit by a Flash worm. It was brought to my attention by Dan Goodin over at the Register, and I discussed it briefly with him as he wrote an article about it. Because I've been looking at Flash in depth lately (more on that coming soon), I decided to take a deeper look at the attack. I was able to track down the HTML side of the malware, but couldn't find a copy of the malicious SWF. An email to the LiveJournal staff fixed that, and they were kind enough to also include their own analysis of the attack. Their earlier post generally covers it, but I'll go into a bit more detail here.
It's really a fairly simple worm. As noted by the LiveJournal staff, the payload did much less than it could have.
The real source of the vulnerability was an overly permissive crossdomain.xml file on www.livejournal.com. This is a well-known, but surprisingly common issue- Jeremiah Grossman came up with some basic statistics for this issue in May of 2008- Some 18% of websites (from a very limited, but high-value set of sites) have crossdomain policies that I would consider "permissive." Coincidentally, I have more research on that coming up soon, but for the moment, I'll just say that only a year and a half later, the numbers are considerably worse.
At any rate, LiveJournal's crossdomain policy allowed Flash objects from their lj-toys.com sandbox domain more access than it should have, and allowed this worm to perform requests across domains. From there, it is pretty simple- embed malicious objects in a post, and have those objects make requests to www.livejournal.com, propogating to the profile of any user that views them. The exact steps that the worm takes are as follows:
The requests to bit.ly are interesting. Each time the malware is run, it sends a request to bit.ly. Just before infecting another account, it sends a request to another bit.ly link. The results of these requests are discarded, so I believe that they are only made to provide tracking data for the malware author via bit.ly's "info" page for each link. Based on the information from those pages, I estimate that the payloads were executed 9,700 times, and around 3,300 accounts were infected (accounting for a handful of "false clicks" from myself, the malware author, and others). The data on the bit.ly page doesn't provide enough granularity to generate a useful profile of the attack's timing, so I've contacted bit.ly staff to see what further information can be provided. While they are being helpful, I'm not sure I'll be able to get much useful data (I sure wouldn't give it to me).
What lessons can we learn from this? For a user, Flash can be dangerous. It should be disabled by default. Is this news? No. But this is a very clear sign that the attackers know it as well, and it is being exploited. We, on the good guys' side, should be paying attention. For the administrators of a website, there are a few lessons. First, the crossdomain.xml policy is a major failure point, and many sites are vulnerable. Know when you are allowing access. Second, embeddable content can be dangerous. While LiveJournal's system for embedding content is actually quite good, there are really too many things that can be done with active content like Flash to allow it without seriously considering the consequences.
On the plus side, a few things were really done right. Within minutes of receiving reports of strange account activity, LiveJournal staff determined that active content was the culprit and disabled it throughout the site. A crude whitelist of trusted sources (such as YouTube) were enabled soon thereafter, and within a few hours, the faulty crossdomain.xml file was found and fixed.
That fast of a reaction is really impressive, and the corrective measures were pretty much spot on. What's more, LiveJournal decided to be transparent about the whole issue, releasing informative alerts to their users and working with them to fix compromised accounts. Tupshin Harper, director of Engineering and Operations, was particularly helpful to me in analyzing the attack and providing useful data. My hat is off to them- if more people reacted to breaches this way, the web security community would be in a lot better position to deal with attacks.
A few questions are still left unanswered- primarily about the attacker and his motives. The data that was logged by the malware really wasn't particularly sensitive- an email address and a username, basically. I suppose it could be useful for future phishing and spamming attacks, but given the wealth of other presumably-useful information available in a LiveJournal profile, I'm not sure that this was the goal. The code in the SWF isn't particularly refined, so I think that "Proof of Concept" is the most likely explanation. It's also worth noting that the SWF's code is in English, and while psychological profiling isn't really my strong suit, I get the impression this was intended to be neither subtle nor malicious. The servers that received user data to were all cPanel mass-hosting servers, running vulnerable instances of phpBB, Joomla, and other commonly-attacked software. One of the servers is located in Washington, one in Hungary, and one in the Ukraine. I've requested information from those hosting companies, but don't really expect a response. It is also interesting that the "logging" scripts do not actually exist on any of those servers (nor could they, being ASP scripts and the servers running PHP), but the data is sent as GET variables. If the attacker intended to retrieve that data, he would need to compromise either the FTP account or the cPanel account in question to get it from the access logs- a reasonable assumption, but not (by me at least) a provable one.
I'll leave it as an exercise to LiveJournal, bit.ly, and the hosting companies involved to locate the "patient zero" LiveJournal account and, presumably, the attacker. I have no doubt that the data required to locate him is there, but getting it all into one place will probably prove tricky.
It's really a fairly simple worm. As noted by the LiveJournal staff, the payload did much less than it could have.
The real source of the vulnerability was an overly permissive crossdomain.xml file on www.livejournal.com. This is a well-known, but surprisingly common issue- Jeremiah Grossman came up with some basic statistics for this issue in May of 2008- Some 18% of websites (from a very limited, but high-value set of sites) have crossdomain policies that I would consider "permissive." Coincidentally, I have more research on that coming up soon, but for the moment, I'll just say that only a year and a half later, the numbers are considerably worse.
At any rate, LiveJournal's crossdomain policy allowed Flash objects from their lj-toys.com sandbox domain more access than it should have, and allowed this worm to perform requests across domains. From there, it is pretty simple- embed malicious objects in a post, and have those objects make requests to www.livejournal.com, propogating to the profile of any user that views them. The exact steps that the worm takes are as follows:
- Perform a blind request to bit.ly (more on this in a moment)
- Check whether a user is logged in by requesting and parsing http://www.livejournal.com/manage/profile/
- Extract username and email address from that page
- Extract last post ID from http://www.livejournal.com/editjournal.bml
- Request the contents of that last post
- Check whether the post is already infected
- Perform another blind request to bit.ly
- Infect the post, appending the SWF payload to the body
- Perform requests to one of three outside servers (chosen at random), submitting the following as GET variables: username, email address, and the data from the last post
The requests to bit.ly are interesting. Each time the malware is run, it sends a request to bit.ly. Just before infecting another account, it sends a request to another bit.ly link. The results of these requests are discarded, so I believe that they are only made to provide tracking data for the malware author via bit.ly's "info" page for each link. Based on the information from those pages, I estimate that the payloads were executed 9,700 times, and around 3,300 accounts were infected (accounting for a handful of "false clicks" from myself, the malware author, and others). The data on the bit.ly page doesn't provide enough granularity to generate a useful profile of the attack's timing, so I've contacted bit.ly staff to see what further information can be provided. While they are being helpful, I'm not sure I'll be able to get much useful data (I sure wouldn't give it to me).
What lessons can we learn from this? For a user, Flash can be dangerous. It should be disabled by default. Is this news? No. But this is a very clear sign that the attackers know it as well, and it is being exploited. We, on the good guys' side, should be paying attention. For the administrators of a website, there are a few lessons. First, the crossdomain.xml policy is a major failure point, and many sites are vulnerable. Know when you are allowing access. Second, embeddable content can be dangerous. While LiveJournal's system for embedding content is actually quite good, there are really too many things that can be done with active content like Flash to allow it without seriously considering the consequences.
On the plus side, a few things were really done right. Within minutes of receiving reports of strange account activity, LiveJournal staff determined that active content was the culprit and disabled it throughout the site. A crude whitelist of trusted sources (such as YouTube) were enabled soon thereafter, and within a few hours, the faulty crossdomain.xml file was found and fixed.
That fast of a reaction is really impressive, and the corrective measures were pretty much spot on. What's more, LiveJournal decided to be transparent about the whole issue, releasing informative alerts to their users and working with them to fix compromised accounts. Tupshin Harper, director of Engineering and Operations, was particularly helpful to me in analyzing the attack and providing useful data. My hat is off to them- if more people reacted to breaches this way, the web security community would be in a lot better position to deal with attacks.
A few questions are still left unanswered- primarily about the attacker and his motives. The data that was logged by the malware really wasn't particularly sensitive- an email address and a username, basically. I suppose it could be useful for future phishing and spamming attacks, but given the wealth of other presumably-useful information available in a LiveJournal profile, I'm not sure that this was the goal. The code in the SWF isn't particularly refined, so I think that "Proof of Concept" is the most likely explanation. It's also worth noting that the SWF's code is in English, and while psychological profiling isn't really my strong suit, I get the impression this was intended to be neither subtle nor malicious. The servers that received user data to were all cPanel mass-hosting servers, running vulnerable instances of phpBB, Joomla, and other commonly-attacked software. One of the servers is located in Washington, one in Hungary, and one in the Ukraine. I've requested information from those hosting companies, but don't really expect a response. It is also interesting that the "logging" scripts do not actually exist on any of those servers (nor could they, being ASP scripts and the servers running PHP), but the data is sent as GET variables. If the attacker intended to retrieve that data, he would need to compromise either the FTP account or the cPanel account in question to get it from the access logs- a reasonable assumption, but not (by me at least) a provable one.
I'll leave it as an exercise to LiveJournal, bit.ly, and the hosting companies involved to locate the "patient zero" LiveJournal account and, presumably, the attacker. I have no doubt that the data required to locate him is there, but getting it all into one place will probably prove tricky.
Labels: Flash, LiveJournal, Web Applications, Worms
posted by mckt at
7:12 AM
0 Comments:
Post a Comment
<< Home