Use the following film clip video WOW hack at your own risk (not tested), best use a test account:

Federico Biancuzzi, 2007-12-20 found at securityfocus.com

Soon after that I became very interested in knowing why it was that amazingly good architects, developers, and languages people (such as the inventors of Java) were in the dark when it came to security. Looking around, it became clear that there was not much work published about software security, so I wrote Building Secure Software with John Viega in 2000.

“ To date, I don't believe online game security has grappled with the software security problem the way it should. I'm confident that our book will change that. We've already been contacted by a number of game companies interested in doing a better job with software security. ”

That book touched off a paradigm shift in computer security. Since then I've published a number of books helping to steer that field's evolution, including Exploiting Software (with Greg Hoglund) and Software Security.

As you might imagine, my new book Exploiting Online Games has plenty to say about software security. From my perspective as a scientist the most interesting thing about online game security is that the kinds of problems and issues we describe and discuss in the book are a harbinger of software security issues to come as the world embraces service-oriented architecture (SOA) and Web 2.0 designs.

How did you get interested in online games?

Greg Hoglund, my co-author, conned me into it. Greg had been working in online game security for several years before we started collaborating on the book. He gave an advanced talk about cheating in online games in 2006 at Black Hat, describing rootkit-based techniques that thwart detection. Once Greg showed me what he was doing, it was clear that there was plenty to write about. The topic is incredibly cool because it involves the intersection of the law, money, and technology.

The more I dug into online game security, the more interesting WOW and things became. There are multiple threads intersecting in our book: hackers who cheat in online games and are not detected can make tons of money selling virtual items in the middle market; the law says next to nothing about cheating in online games, so doing so is really not illegal; the kinds of technological attacks and exploits that hackers are using to cheat in online games are an interesting bellwether; software is evolving to look very much like massively distributed online games look today with thick clients and myriad time and state related security problems. The book has a chapter on the law, a chapter on money, and lots of explicit discussion of very interesting software security problems. It's also a no-holds-barred, hands-on kind of book with lots of code and ideas you can sink your teeth into.

Ultimate World of Warcraft cheats guide

Of course game developers care deeply about security! Nothing makes a game developer angrier than people who cheat and most game developers set out to thwart that kind of thing when they design their games. In the book we include a FAQ about game hacking, written by a game developer named Matt Pritchard, who tried to explain the attacker's perspective to the uninitiated.

When it comes to developers the biggest problem in software security is that many still believe that security is all about functionality. For example, they think that sprinkling on some "magic crypto fairy dust" will solve the security problem. But the kinds of attacks we describe in our book are not based on traditional network-based attacks, remote buffer overflows, or SQL injection. Instead, they are based on taking control of the local game process on your own PC and having it do things on your behalf. Some of the most interesting attacks against online games involve building "bots" that can automatically play the game for you. The bot program runs on your PC along with the game client. The challenge is to have that happen in an undetectable fashion. (Incidentally, this is why games have so much relevance when it comes to future attacks on other distributed systems.)

Game developers will learn plenty about the attacker's perspective and real attacks by reading our book. In the end, that will make for much better software security and games that are much harder to cheat in. My bet is that this book will help to spark more interest in software security in general.

Given the huge number of users and variables, the states of the system are held on users' computers, not on servers. How can they check what is going on then? It sounds like an approach destined to fail, no?

Trying to keep track of all possible state transitions in a sophisticated multi-user game is computationally infeasible, even without regard to client-server issues. Any game with a small number of states -- think checkers -- is amenable to the "perfect play" problem, making it boring. No human can ever hope to beat the best computer program checkers players, for example. Ironically, in order to be interesting, a game needs to have huge gobs of state!

Add to this the problem of exposing lots of that state on gazillions of PCs that are not to be trusted, and you can see the magnitude of the problem.

Fortunately, tracking state and observing what's going on in the virtual world does not have to amount to watching every molecule. One technique that I think would be helpful is coming up with a way to track state information handed to an untrustworthy PC in a "low resolution" mode, focusing more attention on areas where interesting or "otherwise anomalous" things happen. You can find those areas by computing the "low resolution" vector periodically and thinking about how it is changing over time. In any case, it is clear that allowing a fat client outside to directly muck with state information is not going to work.

Do the security features in Windows Vista -- such as limits on HD playback and signed drivers -- help in fighting cheaters?

I doubt it. So far the Vista features have not done much to thwart hacking and software exploits. A trusted hardware solution might work, but does not seem to have much uptake from a sociological perspective.

Game companies have done some client observation to try to detect cheaters and ban them from the game. Many of their efforts have focused on monitoring a gamer's PC by installing spyware. World of Warcarft's "Warden" is a case in point. From a security architecture perspective, it's obvious that installing a monitor on the attacker's PC will not work. An attacker needs only to attack the monitoring program in the same way that he or she goes after the game program. If you control the PC as the attacker, you control the PC.

I believe solutions will need to rely on better design of server-side code. Trying to protect the client itself, which is by definition outside the trust boundary, seems to me to be a much harder problem. The best you can hope for in that situation is an arms race that you will eventually lose.

How would you design an anti-cheating system?

I would avoid putting anti-cheating technology on the client, for hopefully obvious reasons. Earlier in this discussion I sketched out the idea of a lo-res view of state accessed and/or controlled by the client that can be used as fodder for an anomaly detection system that runs on the server side. I would start with a server-side focus.

I would also like to see more attention paid to basic software security issues -- bug and flaw removal and attacker-perspective based testing. I think that is bound to happen, given the kind of exposure online game security is getting now.

What differences do you see between MMORPGs and distributed systems used for business?

The biggest difference is one of size -- MMORGPs are much larger than any distributed system for business that I am aware of. Consider that World of Warcraft has 9,000,000 subscribers, all of who can connect at once if they want to. Now, that's a massive system.

With regard to architecture, there seems to be a trend towards fat clients of the sort that MMORPGs already use. If you consider Microsoft's Silverlight launch (a plug-in product meant to compete with Adobe's Flash), there is real evidence that thin clients are getting thicker as plug-in functionality spreads. That kind of trend makes me believe that the Web browser is not likely to end up as the "client of choice" in future systems. SOA may end up being more about fat clients than about Web-based clients.

From a security perspective, in some business verticals, such as the financial (sector), software security is much better understood and practiced than it is in the gaming industry. That may bode well for the security of future massively distributed systems for business. As financial institutions adopt massively distributed architectures, as MMORPGs already have, perhaps better software security will happen as a side effect.

In any case, massively distributed systems of all kinds are changing the security landscape in interesting ways.

Is there anything that system designers/architects should learn or copy from multiplayer games?

From a security perspective the main thing to learn is an important lesson about trust boundaries, state, and time. The larger these systems get the more the trust boundaries become complicated -- which machines, client software, components, etc. are to be trusted and which are not?

At this point in online game security history there are more things not to copy than to copy. For example, the idea of building a monitor for a game client that itself runs on the client PC is very silly and should not be copied. Or, when setting up a cryptographic pipe, giving a copy of the symmetric key to your potential attacker is dumb. Online games currently do both of those things.

There are plenty of technology lessons that can be learned from online games, such as how to load balance in a massive client-server system, but not really any great security lessons.

Is there any suggestion you could make to the users of these games? For example, running the games in a virtualized environment?

Absolutely! We have a checklist in the book, for things that all gamers can do to be more secure. You can find the 14 point checklist in chapter 10. One of the things on the list is: Make sure you're comfortable with any spyware the game installed to monitor your PC during gaming sessions.

Another is: Do not run the game as administrator or root.

Beyond cheating, did you see any attempt to break into your system?

So far, malicious hackers have not directly targeted game clients running on other peoples' machines for exploit. Nor have malicious code writers written viruses or worms to go after game clients. It's only a matter of time, though.

Some Trojan Web sites have done what they can do to collect gamers' authentication information so they can loot their characters (and) accounts. In Brazil, a criminal gang even kidnapped a star MMORPG player in order to take away his character, and its associated virtual wealth.

The really interesting thing about online game security is that the attackers are in most cases after software running on their own machine, not software running on somebody else's box. That's a real change. Interestingly, the laws we have developed in computer security don't have much to say about cheating in a game or hacking software on your own PC.

I am not sure if there is a big approval of the full-disclosure culture in the gaming world (considering some "discussions" happened with researchers like Luigi Auriemma )or reported bugs that are not fixed at all. From your experience, how do game developers react to submissions of security vulnerabilities?

I am not sure either. From the experiences of my co-author Greg Hoglund, when it came to outing the Warden (the anti-cheating spyware installed by Blizzard to monitor World of Warcraft), it seems apparent that the idea of full disclosure and working with security researchers is not something game manufacturers are used to. Game developers seem to inhabit their own little world.

By and large the people who are looking for exploits in games are less interested in making a name for themselves (by, say, publishing an exploit) and more interested in making money. There are multiple ways to make money given a bug in a game, from cheating for yourself and your own character, to selling the exploit to others. The upshot is that market dynamics in game security are different. It's funny because an open market for non-game exploits is nascent, with the auction site WabiSabiLabi apparently leading the way. Online game exploits already have a mature market with real demand and a clear path to making money.

Blackhats can earn real money through online games exploits, but what about whitehats? For example, with "business" software, whitehats can use their knowledge of new bugs to protect their clients, so I see a good reason for both sides to do bug hunting. But what interest should whitehats have in spotting bugs in games?

The most interesting whitehats do more than just hunt bugs! They do things like teach developers how to do a better job with software security. Of course, just as in other software disciplines, some number of bugs exist in current systems and they need to be uncovered and removed. There is no reason that whitehats can't join game companies in that effort.

To date, I don't believe online game security has grappled with the software security problem the way it should. I'm confident that our book will change that. We've already been contacted by a number of game companies interested in doing a better job with software security.

As a discipline, software security is fairly young. We've made great progress in the last decade and I am looking forward to more. Online games make an ideal case study for software security because they show what we should expect when the next generation of software hits desktops.