Wednesday, May 13, 2009

Lessons Learned from Time's Most Influencial Poll Abuse: Part 1


Submitted by Ryan Barnett 5/13/2009

In a text book case of web applications being abused due to insufficient anti-automation defenses, the Time Magazine's Internet poll of the most influential 100 people was bombarded with various methods to manipulate the results.  The WASC Web Hacking Incident Database provides a great overview of the various tactics that Moot supporters used to influence the poll results.  In this installment, we are going to focus on the CSRF attack vectors employed by Moot's supporters.

Cross-site Request Forgery (CSRF) attacks
The supporters of Moot did some analysis and identified a voting URL that the flash application submitted its data to -
http://www.timepolls.com/contentpolls/Vote.do?pollName=time100_2009&id=1883924&rating=1
They then created an auto-voting application to act as a man-in-the-middle interface to the Time poll.  The auto-voter URL looked like this -

http://fun.qinip.com/gen.php?id=1883924&rating=1&amount=1

The arguments specified the ID of the person on the poll, what rating or place out of 100 the voter wanted them in and how many votes they were submitting.  With this information, the attackers could abuse the amount argument to vote more than one time:

http://fun.qinip.com/gen.php?id=1883924&rating=1&amount=200

When accessing this URL, the application responds with the following message:

Down voting : 1883924 to 1 % influence 200 times per page load.

As you can see, each time this URL was accessed, it was equivalent to 200 individual normal requests.

They decided to use this URL in an automated CSRF campaign by submitting this data as a hidden SPAM link across hundreds of thousands of sites.  The end result would be that when clients accessed the pages with this SPAM link on it, it would force the client to submit the Time poll CSRF data behind the scenes.  The clients were therefore unknowingly voting for Moot.

Lessons Learned - Implement a CSRF Token
Time eventually identified the manipulations and attempted to implement an authentication token in the URL.  The token was an MD5 hash of the URL + Salt value.  While a first glance at this may seem like an improvement, it fact it didn't provide much protection.  The salt value was embedded inside of the flash voting application and Moot's supporters were able to extract out the value and calculate the proper MD5 key value.  They were then quickly able to update their CSRF URLs to include the appropriate data -

http://www.timepolls.com/hppolls/votejson.do?callback=processPoll
&id=335&choice=1&key=a4f7d95082b03e99586729c5de257e7b

Lessons Learned - Implement a *good* CSRF Token
When implementing a CSRF token, it is important to make the value unique for each individual user so that I can not be reused or easily guessable.  In this case, the key token value was only factoring in the URL and the salt so the resulting hash would be the same for all users.

There were a few other very interesting aspects to these Time poll attacks and I will cover them in future blog posts.

Identifying CSRF Attack Payloads Embedded in IMG Tags
One of the URLs used by the Moot supporters in their SPAM URL posting campaign is here -


If you inspect the source of the page, you will see the following -

This technique of CSRF uses the IMG html tag to trick the browser into submitting the attack payload.  What is interesting with the technique, from a detection perpsective, is that when some browsers make this request, the Accept Request Header tells the web server that is excpecting an image file.   For example, FireFox sends this request -

GET /hppolls/votejson.do?callback=processPoll&id=335&choice=1&key=a4f7d95082b03e99586729c5de257e7b HTTP/1.1
Host: www.timepolls.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://fun.qinip.com/

This information could be used in an anomaly scoring scenario to help to identify these types of basic CSRF injections.  Proper acknowledgement of identifying this phenomenon goes to Rsnake as we discussed this concept at a previous SANS conference.  These types of detection "golden nuggets" are part of Rsnake's upcoming security book entitled "Detecting Malice" which is scheduled for release later this summer by FeistyDuck publishing (www.feistyduck.com). 

1 comment:

Anonymous said...

Good one Ryan. I like the part about the Accept-Header.

Cheers,

Christian