More Fun With Online Contests

I realize now that the last time I wrote about this that I really was working much harder than I needed to be and that my ideas weren’t nearly nefarious enough. Running everything through proxies on my end works, but requires a silly amount of effort. What I really needed to do was to have everybody else make the requests for me. A distributed means, if you will.

So, with no further ado, I present the “Vote For Colt” iframe:

All you have to do is include that snippet in a website and include the below file and any time somebody visits said website they will place a vote for Colt.

How does it work? The exact same basic function as the shell script. It gets a valid voting URL and has the website visitor make an image request to trigger the vote.

All in all, this is a much better approach to the problem, and solves the traceability issue with a simple CSRF hack.

3 thoughts on “More Fun With Online Contests”

  1. Yes, but your still a sketchy person. Too thoughtless and destructive to be a hacker and to sloppy and rude to be a professional.

    Why do you want to fuck with this contest so bad? Nothing better to do?

  2. You DO realize you are pretty much ensuring that your buddy Colt will have his votes reduced at the end right? They sent out a letter stating that they are letting the cheating go forward and just removing fraudulent votes at the end.

    You really sure this method is not going to be able to be traced? It seems you may know less than you think. You previous article was full of assumptions and most were wrong. And I dont think you considered the fact that this is most likely hosted on a multiple servers throwing a bunch of stuff into the mix.

    Just stop already. Do something to make some money or help someone.

  3. "Nathan": some wouldn’t post your comments and respond, but I’m not afraid to call myself out on bad decisions I’ve made. So, on that note, my first decision to move Colt to the front page was a bad one. Because of my actions Colt has already been made ineligible in the contest. I screwed up (as we all do) and to make things right, I’m personally making sure that they receive the money that winning this contest would have provided. At this point, in terms of my responsibility to this contest and to Colt, I feel that is all that can be asked of me. I do ask that if you wish to continue this dialogue that you discontinue the personal attacks as they achieve nothing.

    So, since my first blog post, and knowing that Colt has been disqualified, my only interest has been purely academic. At no point have I ever nor will I ever claim to be an amazing hacker, simply just a guy who is aware of some ways that a system could possibly be gamed.

    My discussing my actions while the contest is still going on hopefully makes it clear that I’m not intending to tamper with the results any longer and am instead trying to draw attention to the ways in which results for online contests in general can be tampered with. In spite of this contest serving as an example, my writing here is no longer focused on this contest in particular and instead just hoping to create general awareness amongst the tiny number of developers who follow my blog.

    That reason, the academic reason, is why I wrote this followup post. While working on a curl script for another project of mine I recognized this as another vector for vote manipulation that I hadn’t noticed previously. Sure, this one could be mitigated by ensuring that the IP that gets the original unique token (and other cookie identifiers) is the one that uses it, but as I have not seen either the backend code or the audit logs I have no idea how effective *any* of this will be. For all I know there is no logging at all, or there could be issues with FIFO logging that will hide all actions older than some date or could result in an accidental self-DoS if the disks run out of space. All of those have happened in a poorly-run contest that I inherited in the past. This contest simply shows the same symptoms as that one did and so I’m quick to jump to conclusions. Everything that I have discussed as a potential attack to this point is something that needs to be considered by online contest developers. Whether or not it impacts this particular contest is a moot point as that is no longer my focus.

    And as a side note, this is the academic curiosity asking, I’m not sure how multiple servers would affect this approach? Even in the event that the generated unique token is only valid for that particular server in a load balanced environment (say 4-10 boxes), the image-driven request would still trigger a 10-25% success rate which is more than enough with a high quantity of requests. I’m also more than happy to be educated as to where I am wrong if you have more information.

Comments are closed.