_________________________________
Did you know that over 94% of personal computers have hidden corrupt dangerous files with over 150 hidden errors and bugs on them?

Usually the deck or wheel is initialized from a static value. A card or wheel position is selected by obtaining the modulus of the total cards in the deck or possible positions in the wheel and a random number. (usually large, provided by well tested libraries) The result is used as an offset into the initial, static, game object. The problem occurs when the random number is not divisible evenly, resulting in a bias in favor of cards or wheel positions near the beginning.

An entire industry exists to search gaming systems for these types of problems. I think you have demonstrated it’s not very thorough. Perhaps some of these companies could benefit from our tools!

What’s interesting about online gaming is that so much money is spent having third parties audit software for fairness when it can be handled on the client side so easily. Consider a poker game:

Instead of having the server generate all the random numbers; it could allow the clients to each submit some random values which would be combined with the server generated random value. The server would immediately return hashes of all participants random values (individually) to every player. The server uses the values (eg. a hash of them all concatinated, so as to return a fixed sized integer) to initialize the game state. After the hand is completed the server notifies all participants of the actual random values used to set the game state. Each client could check the fairness of the deal by hashing the values and comparing them to what the server claimed to use. Fairness is ensured because entropy is contributed by all players, all players are given proof before the game begins, and all players are given proof that the deck was not stacked after the game is over.

Another variation could have the server encrypt the random value before the game, distribute it to all players, and then send all players the decryption key after the game is completed.

To poison DNS cache an attacker must spoof a response to a DNS request. The 16 bit transaction ID of the spoofed response packet must match the one in the request from the target nameserver. The chance of guessing the right value is not good: 1 in 2^16.

It is possible to have more than one chance however. Requests for many records can be forced. (aaa00001.example.com, aaa00002.example.com, … ) It’s a birthday attack. Sooner or later, the target’s transaction ID will match the attacker supplied value.

Controlling some random hostname such as aaa1892764.google.com would be of little value, but responses can contain additional records. Returning a record for ns1.google.com poisons that as well, and if you follow what I’m saying so far I don’t need to spell out the implications.

Here’s a metasploit module. I haven’t tested it, YMMV.
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Yeah, it takes a ton of knowledge and -i think- many days of preparation for the contest. So you can compare it to professional athletics of the computer security.

I think the only shift in this reality will come when software vendors will be held liable for their mistakes, not just bugs, but for mistakes that could have been prevented. A lot of them can be prevented with rigorous analysis, before shipping it.