(This entry is from the preface to the new book Exploiting Online Games that I co-authored with Greg Hoglund. The book is available in stores on Friday.)

Online games, including World of Warcraft, EverQuest, Second Life, and online poker, have taken the computer world by storm. Gaming has always been (and remains) among the prime drivers of PC technology, with deep penetration into the consumer market. In the last ten years, computer games have grown just as quickly as the Internet and can now be found in tens of millions of homes.

The Internet is experiencing plenty of adolescent growing pains along with its phenomenal growth. These pains are experienced mostly in terms of problematic and pervasive computer security issues. Online games, especially massively multiplayer online role-playing games (or MMORPGs for short), suffer from these security problems directly.

MMORPGs are made of very sophisticated software built around a massively distributed client-server architecture. Because these games push the limits of software technology, especially when it comes to state and time (not to mention the real-time interaction of hundreds of thousands of users), they are particularly interesting as a case study in software security. In fact, MMORPGs are a harbinger of technical software security issues to come.

Modern software of all kinds (not just game software) is evolving to be massively distributed, with servers interacting with and providing services for thousands of users at once. The move to Web Services and Service Oriented Architectures built using technologies like AJAX and Ruby follows hard on the heels of online games. What we learn here today is bound to be widely applicable tomorrow in every kind of software.

Adding to the urgency of the security problem is the fact that online games are big business. The most popular MMORPG in the world, World of Warcraft by Blizzard Entertainment, has over 8 million users, each of whom pay $14 per month for the privilege of playing. Analysts estimate the gaming market will reach $12 billion by 2009.

Inside the virtual worlds created by MMORPGs, simple data structures come to have value, mostly a reflection of the time gamers spend playing the game. Players accumulate and trade virtual wealth (or play money). Many of these virtual economies have per capita GDPs greater than most small nations. Not surprisingly, direct connections between the virtual economies of games and the real economy exist all over the place. Until recently, it was possible to buy in-game play money with real dollars on eBay; now many other well-developed middle markets exist. And the reverse is possible, too. This has led to the emergence of a class of players more interested in wringing virtual wealth out of the game than playing the game itself.

Wherever money is at stake, criminals gather and linger. Cheating happens. In the case of MMORPGs, cheaters have real economic incentive to break the security of the game in order to accumulate virtual items and experience points for their characters. Many of these items and even the characters themselves are then sold off to the highest bidder.

Sophisticated hackers have been working the fertile fields of MMORPGs for years, some of them making a living directly from gaming (or cheating at gaming). This book describes explicitly and in a technical way the kinds of attacks and techniques used by hackers who target games.

Why Are We Doing This?

As you can imagine, game companies take a dim view of cheating in their games. If cheating becomes rampant in a game, unsatisfied noncheating players will simply move on to another. Game developers have taken a number of steps to improve security in their games, some of them controversial (monitoring game players’ PCs behind the scenes), others legalistic (imposing strict software license agreements and terms of use), and some of them trivial to break (using symmetric cryptography but including the secret key in the game client code). Our hope is that by understanding the kinds of attacks and hacking techniques described in this book, game developers will do a better job with online game security.

We think our topic is important for several reasons: First, real money is at stake; second, many players are completely unaware of what is going on; and third, online game software security has many critical lessons that we can directly apply to other, more important software. Plus, it’s fun and controversial.

For example, some game companies have been known to use stealthy techniques most often seen in rootkits to monitor gamers’ PCs. They have also been known to resort to strong-arm tactics to suppress hackers, even those not attempting in any way to be malicious or to make money. Will manufacturers of other software or digital content adopt these techniques for themselves?

Not only are the technical issues captivating, the legal issues surrounding online games and their creative software license terms are also a harbinger of things to come. The legal battles between game companies, academics, and users are by no means over—in fact, they have just begun.

In the end, the topic of online game security poses a number of interesting questions, the most pressing one being this: How do you balance gamers’ privacy rights against game developers’ desires to prevent their games from being hacked?

Where Do We Draw the Line?

For the record, we do not condone cheating, malicious hacking, or any other game-related shenanigans. We are most interested in deeply understanding and discussing what’s going on in online game security. As practical security experts, we believe that only by gaining direct technical understanding of what happens when games are exploited can we begin to build systems that can withstand real attacks. Because in this situation money is at stake, you can be sure that attacks and exploits today are both concerted and organized.

We think it is acceptable and necessary to understand both how games really work and how they fail. The only way to do this is to study them carefully. We pull no punches technically in this book, showing you how online game clients fail from a security perspective in living detail. We also explicitly describe techniques that can be used to exploit online games. We don’t do this to create an army of online game hackers—that army is already brimming in numbers, and those already enlisted in it are unlikely to learn much from this book. We do this so that the good guys will know what they are really up against. Our main objective is to describe the kinds of weapons the existing active army of game attackers has.

In our research for this book, we have broken no laws. We expect our readers likewise not to break the law using the techniques we describe.

What’s In the book?

Like most books, this book starts out at a high level and becomes progressively more technical as it goes on.

Chapter 1, Why Games?, poses and answers some simple questions. How big are online games? How many people play? Why would anyone want to exploit them? What motivation is there to cheat in an online game? The answers to these questions will likely surprise you. Believe it or not, 10 million people play online games, billions of dollars are at stake, and some people even cheat for a living. We also provide a gentle introduction to game architecture in Chapter 1, describing the classic client-server model that most games use.

Things get more technical beginning in Chapter 2, Game Hacking 101, where we describe the very basics of game hacking. The chapter is organized around describing six basic techniques: (1) building a bot, (2) using the user interface, (3) operating a proxy, (4) manipulating memory, (5) drawing on a debugger, and (6) finding the future. We pay special attention to the topic of bots since most game exploits exist to create and operate them. Late in the chapter, we even show a very simple bot that we built so you can see exactly what bot software looks like. We then describe controversial moves taken by one game maker to thwart cheating—installing rootkit-like spyware on a gamer’s PC to keep track of what’s going on. We hold this approach in low opinion and have written a program to help you know what’s going on with these monitoring programs on your own machine. We believe game makers would be better off spending their resources to build games that were less broken than to build monitoring technology.

The next two chapters take a break from technical material to cover money and the law. In particular, Chapter 3, Money, helps us understand why some players might want to cheat. The recent book Play Money by Julian Dibbell (Basic Books, 2006) describes one (pathetic) man’s foray into professional game farming, something that a number of people actively pursue. There is enough money in play here that entire enterprises have grown up around providing middleman services for gamers, buying and selling virtual items in a marketplace. The biggest and most interesting company, Internet Gaming Entertainment, known as IGE to most people, deserves and gets a treatment of its own in this chapter.

Chapter 4, Enter the Lawyers, is about the law. Game companies (and indeed a whole host of other software makers) have created a licensing jungle in the form of end user license agreements (EULAs) and terms of use (TOU) documents. Though we are not lawyers, and by no means should you rely on our advice, we provide a brief description of U.S. copyright law and the Digital Millennium Copyright Act (DMCA). Then we go through an entertaining (and somewhat scary) parade of EULAs gone bad—from Sony’s rootkit debacle to viruses protected by EULAs. We end up with a discussion of your rights as a software user and gamer.

Technical aspects of online game security begin to pick back up in Chapter 5, Infested with Bugs. We spend this chapter talking about the kinds of vulnerabilities found in many games, explaining how attackers usethem to build working exploits. We pay particular attention to bugs involving time and state, which, as we alluded to earlier, are the kinds of bugs we can expect to see much more of as other software evolves to become more like game software.

Chapter 6, Hacking Game Clients, really digs in and gets technical. As we move more deeply into games, we are forced to use a game or two as a particular target. We don’t do this to single out any one game; instead, we do this to make our examples salient and technical. We have chosen to concentrate on World of Warcraft (WoW), a game produced by Blizzard Entertainment, mostly because it is the number one online game in the world. The kinds of techniques we demonstrate using WoW as an example can be applied by analogy to almost any online game (and to modern Web 2.0 software, for that matter). Chapter 6 begins with a discussion of the attacker’s toolkit (many of the tools we describe are standard software testing tools). We then organize our discussion of game hacking techniques into four equally important areas: (1) getting over the game by using its user interface directly, (2) getting inside the game by manipulating memory, (3) getting under the game by interposing on services like video drivers, and (4) getting way outside the game by intercepting and manipulating network traffic. Chapter 6 is in some sense the heart of the book, introducing a large number of techniques commonly used by game attackers.

Chapter 6 has lots of data in it, probably too much. Sometimes it is easier to understand these kinds of techniques by seeing how they are put into practice. Toward that end, in Chapter 7, Building a Bot, we put together all of the lessons of Chapter 6. Chapter 7 is technical, with plenty of example code showing how the ideas in Chapter 6 work in concert to exploit a game.

Chapter 8, Reversing, is even more technical, focusing its attention on reverse engineering techniques that many attackers use to exploit software. Though the techniques we describe in this chapter are intense, they are by no means new. As we describe in our book Exploiting Software (Addison-Wesley, 2004), disassemblers and decompilers are used in computer security every day, both by good guys and by bad guys.

The final technical topic in our book is presented in Chapter 9, Advanced Game Hacking Fu. This chapter discusses what is known in the trade as total conversions and game mods. We describe the process by which some people take apart game data files in order to build their own games or combine different aspects of games in interesting ways. Though some game companies try hard to quash all discussion of total conversion, it happens anyway. We describe how.

Of course, our purpose in this book is to help those who build games understand how to do a better job with security. Chapter 10, Software Security Über Alles, provides a flyover of the new field of software security. Game developers would do well to adopt some of the best practices in common use in the financial vertical today. We also describe a set of questions that everyday gamers can ask their game companies about security. Our fervent hope is that this book will lead to more secure software—both in the game community and beyond.

The Software Security Series

This book is part of the Addison-Wesley Software Security Series of software security books for professional software developers. The series includes the following titles:

• Exploiting Online Games: Cheating Massively Distributed Systems
• Secure Programming with Static Analysis
• Software Security: Building Security In
• Rootkits: Subverting the Windows Kernel
• Exploiting Software: How to Break Code
• Building Secure Software: How to Avoid Security Problems the Right Way

More books in this series are planned for the future. Contact Addison-Wesley or Gary McGraw for more information. Also see the Web site.

This is the foreword that I wrote for Brian Chess and Jacob West’s excellent new book Secure Programming with Static Analysis. I recommend this book for all software security practitioners. Developers, in particular, will find the book extremely helpful. For more on other books in the software security series, see http://www.buildingsecurityin.com.

On the first day of class, mechanical engineers learn a critical lesson—pay attention and learn this stuff or the bridge you build could fall down. This lesson is most powerfully illustrated by a video of the Tacoma Narrows Bridge shaking itself to death. Figure 0-1 shows a 600-foot section of the bridge falling into the water in 1940. By contrast, on the first day of software engineering class, budding developers are taught that they can build anything that they can dream of. They usually start with “hello world.”

Figure 0-1: A 600-foot section of the Tacoma Narrows bridge crashes into Puget Sound as the bridge twists and torques itself to death. Mechanical engineers are warned early on that this can happen if they don’t practice good engineering.

An overly-optimistic approach to software development has certainly led to the creation of some mind-boggling stuff, but it has likewise allowed us to paint ourselves into the corner from a security perspective. Simply put, we neglected to think about what would happen to our software if it were intentionally and maliciously attacked.

Much of today’s software is so fragile that it barely functions properly when its environment is pristine and predictable. If the environment that our fragile software runs in turns out to be pugnacious and pernicious (as much of the Internet environment turns out to be) software fails spectacularly, splashing into the metaphorical Puget Sound.

The biggest problem in computer security today is that most systems aren’t constructed with security in mind. Reactive network technologies such as firewalls can help alleviate obvious script kiddie attacks on servers, but they do nothing to address the real security problem—bad software. If we want to solve the computer security problem, we need to do more to build secure software.

Software security is the practice of building software to be secure and function properly under malicious attack. This book is about one of software security’s most important practices—code review with a static analysis tool.

As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. Microsoft has carried out a noteworthy effort under its Trustworthy Computing Initiative. Many Cigital customers are in the midst of enterprise scale software security initiatives. Most approaches in practice today encompass training for developers, testers, and architects; analysis and auditing of software artifacts; and security engineering. There’s no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years.

In my book Software Security, I introduce a set of seven best practices called touchpoints. Putting software security into practice requires making some changes to the way most organizations build software. The good news is that these changes don’t need to be fundamental, earth shattering, or cost prohibitive. In fact, adopting a straightforward set of engineering best practices, designed in such a way that security can be interleaved into existing development processes, is often all it takes.

Figure 0-2 specifies the software security touchpoints and shows how software practitioners can apply them to the various software artifacts produced during software development. This means understanding how to work security engineering into requirements, architecture, design, coding, testing, validation, measurement, and maintenance.

Figure 0-2: The software security touchpoints as introduced and fleshed out in Software Security: Building Security In.

Some touchpoints are by their very nature more powerful than others. Adopting the most powerful ones first is only prudent. The top two touchpoints are Code review with a static analysis tool, and Architectural risk analysis. This book is all about the first.

All software projects produce at least one artifact—code. This fact moves code review to the number one slot on our list. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Several tools vendors now address this space, including Fortify Software the company that Brian and Jacob work for.

Implementation bugs are both numerous and common (just like real bugs in the Virginia countryside) and include nasty creatures like the notorious buffer overflow, which owes its existence to the use (or misuse) of vulnerable APIs (e.g., gets(), strcpy(), and so on in C). Code review processes, both manual and (even more important) automated with a static analysis tool, attempt to identify security bugs prior to the software’s release.

Of course, no single technique is a silver bullet. Code review is a necessary but not sufficient practice for achieving secure software. Security bugs (especially in C and C++) are a real problem, but architectural flaws are just as big a problem. Doing code review alone is an extremely useful activity, but given that this kind of review can only identify bugs, the best a code review can uncover is around 50% of the security problems. Architectural problems are very difficult (and mostly impossible) to find by staring at code. This is especially true for modern systems made of hundreds of thousands of lines of code. A comprehensive approach to software security involves holistically combining both code review and architectural analysis.

By its very nature, code review requires knowledge of code. An infosec practitioner with little experience writing and compiling software is going to be of little use during a code review. The code review step is best left in the hands of the members of the development organization, especially if they are armed with a modern source code analysis tool. With the exception of information security people who are highly experienced in programming languages and code-level vulnerability resolution, there is no natural fit for network security expertise during the code review phase. This may come as a great surprise to those organizations currently attempting to impose software security on their enterprises through the infosec division. Even though the idea of security enforcement is solid, making enforcement at the code level successful when it comes to code review requires real hands-on experience with code.

The problem is that most developers have little idea what bugs to look for, or what to do about bugs if they do happen find them. That’s where this book, Secure Programming with Static Analysis, comes in. The book that you have in your hands is the most advanced work on static analysis and code review for security ever released. It teaches you not only what the bugs are (what I sometimes call the “bug parade” approach to software security), but how to find them with modern static analysis tools, and more importantly what to do to correct them. By putting the lessons in this book into practice, you can go a long way toward helping to solve the software security problem.

You can purchase a copy of Secure Programming with Static Analysis from Amazon.

Technorati Tags: touchpoints, software security, static anlaysis, Brian Chess, Jacob West