Following on from Part 1 of my Votebot Anatomy 101 series of blog entries.

Some of the software that can be used in order to perform a Votebot attack is in my opinion quite expensive at around $100 a pop, I don’t have $100 to spare, and I certainly don’t want to line the pockets of the people who make the software, but from researching demo’s, videos, information on the web and my own knowledge of web technologies I will attempt to explain how a person might perform an attack and how the software facilitates this.

YouTube currently does very little to stop you from rating a video more than once in a given period of time. When rating a video a cookie is stored on your web browser with a list of videos you have rated (I believe this is also the same for when viewing a video), I’m not sure if this only stores the last video you rated or all videos you have rated in that session, the cookie is encrypted so the information contained is not easily viewable. If this cookie is deleted, or you rate a different video or your session times out and then come back you are then able to vote on that video again. (Whether the repeat ratings get counted I’m not sure of, but it would make sense that they are due to the massive number of ratings some people get during an attack. Even if the repeat ratings are not counted, it’s possible that with enough Sockpuppet accounts the same result can be accomplished.) It is possible however that YouTube may do some sort of throttling on ratings if there is a large number coming from one IP address in a short period of time, or at least, I hope they do.

From what I can gather, the majority if not all the software being used to perform a Votebot attack essentially acts the same way as a web browser but automatically performs the actions needed to add ratings to a video the way you would if you were doing it manually, only the software is able to skip certain steps, like viewing the video, which is why most of the time someone who has been attacked will see a disproportionate number of ratings to the number of views (for the more technically minded, the necessary POST parameters are sent directly to the URL used by YouTube’s AJAX scripts when the rating is clicked).

When a Votebot user decides to start an attack in its most basic form, they find a video they don’t like, copy the URL to that video and paste it into the software, set how many ratings they want to add to that video and the star rating they want for each rating added (depending on the software you can set a minimum and a maximum rating to randomly add a rating equal to/between those two values), then click a button and leave it running whilst it does its thing.

Of course, it’s not quite that simple, a certain amount of preparation is required. Such as obtaining a large number of Sockpuppet accounts. For the more affluent Votebot user, a list of Sockpuppet account user names and passwords can be obtained for a price. Alternatively, some of the software used for Votebot attacks make it quite easy to create new YouTube accounts, by performing most of the registration process automatically and only needing the Votebot user to enter the Captcha information, making the process quite a bit quicker. A couple of hours of labour could result in hundreds of new accounts.

I’ve been asked why YouTube can’t just track the IP address of the person doing the Votebot attack. Sometimes it can be that easy, if the person using the software hasn’t set it up properly. However, from what I can tell with information gleaned from some YouTube Insight reports these ratings can be sent from multiple IP addresses and thus potentially from all over the world, as well as from a different YouTube Sockpuppet account each time, which makes it very difficult for YouTube to trace it to one specific person. This works by using a list of anonymous proxy servers or systems such as the Tor anonymous proxy network. The animation below illustrates what happens when a Votebot attack occurs when using one of these methods, it only shows 10 ratings being sent, but imagine if there are thousands of proxies and it spanned over hours of the Votebot running:

In this illustration we can see where the Votebot user is, but after the web request hits the proxy it has been anonymised and so the originator is pretty much untraceable. So, from YouTube’s perspective, these would all appear to be legitimate ratings from legitimate users, particularly on Tor where peoples actual computers are used as proxies rather than a server in a datacentre somewhere. This also counts for the Sockpuppet account creation and any other manipulation of YouTube that these software applications are capable of. Also, some software is capable of multi-threading which allows asynchronous requests making it possible to send multiple ratings at once.

Although all the locations in the above animation are spread around the world, this doesn’t necessarily have to be the case, someone may have a proxy list that is limited to one country. The reason for this might be for speed as sending web requests around the world can be slow.

If YouTube were able to distinguish an attack from legitimate ratings, it would be difficult for them to restore the rating to what it was prior to the attack because of the sheer amount of data involved. My expectation is that not only is the data for the ratings stored against the video, but also in some sort of data warehouse used to Insight (I say this because I’m pretty sure that the two systems are separate, at least from a database perspective). That kind of data can be dependant on other data and simply removing it would cause inconsistencies or even breaking the system.

That’s it for Part 2, in Part 3 I will approach possible solutions to help prevent Votebot users from performing these attacks. If I am missing something, or have said something blatently wrong, please let me know and I will endeavour to explain or correct as necessary.