4Network Security April 2008

Virtual worlds, real exploits

Perceptions of security in virtual worldsWhile most computer users have been taught basic computer security skills, such as not opening attachments from untrusted sources and not following links in emails, these lessons become worthless when they immerse themselves in a virtual world. Just as when they surf the Web or check their email, while they are within the virtual world, they are using a program on their computer that is interacting with servers and other computers on the internet. Traditional computer exploits arrive in the form of an attachment or malicious web page, but in a virtual world an exploit can appear in almost any form; a whisper in their avatar’s ear, a sign in front of a building, a stunning vest worn by a player, or even the corner of something sticking out of the ground.

“Traditional computer exploits arrive in the form of an attachment or malicious web page, but in a virtual world an exploit can appear in almost any form”

Virtual worlds are online environ-ments where residents are avatars which represent the players in that world. These virtual worlds may be places to gather to socialise, or may be focused on the com-pletion of tasks as in a game. In the latter case, these worlds/games are often called massively multiplayer online roleplaying games (MMORG). These virtual worlds are designed to be immersive, interactive,

animated 3-D environments. Typically, players can design or customise their ava-tar’s appearance, and sometimes even the environment of the online world. Some virtual worlds are free, some require a monthly subscription, while others are free but require a subscription to unlock certain features.

There are many different virtual worlds online today. Examples include Webkinz, World of Warcraft, Eve Online, Second Life, Club Penguin, and the adult-oriented Red Light Center. From this list there are virtual worlds which cater to children as well as adults. Approximately 90 million teenagers play in an online world called Habbo, while 12 million adults participate in Second Life.1,2 Numerous, more specialised virtual worlds exist such as Empire of Sports and Virtual Laguna Beach.

Most of these virtual worlds function with the same basic architecture. Players download client programs to their

desktops. These client programs com-municate directly with servers owned by the company, via TCP or UDP. For example, when a player moves forward, this information is communicated with the server, which updates its internal representation of the world. Then, when any client queries the server for informa-tion concerning the world, this updated information is passed on, so that all clients realise that the player is now in a new spot. Likewise, if a player wishes to talk to another player, their request is sent to server(s) that forward one player’s comment to the other player.

Conceiving a virtual world attackThe idea of changing the virtual world experience is nothing new. The book Exploiting Online Games revealed many of the tricks involved in ‘cheating‘ in MMORPGs.3 One of the drawbacks of

Charlie Miller, principal analyst, Independent Security Evaluators,

You are walking along a vast landscape littered occasionally with billboards, houses, and other small buildings. You hear techno music blaring from a large warehouse and overhear some ladies chatting while using an ATM. You wander away from this town out into a barren land, trying to find the spot where you’ve agreed to meet the attractive stranger you met at the bar last night. Approaching the spot, all you can see is the corner of some object sticking out of the ground. As you lean over to inspect it, you realise, too late, that something bad is about to happen. Charlie Miller

Figure 1: Typical interactions between the clients and the virtual world take place through the central servers.

VIRTUAL WORLDS

April 2008 Network Security5

playing these games is having to play for many hours, usually repeating mundane tasks to advance. Hoglund and McGraw show ways to automate these processes using techniques borrowed from debug-gers and rootkits. Using these methods, it is possible to have the online charac-ters automatically travel on simple quests or strategically attract and kill monsters repeatedly. This is a great way for those who have programming skills but not very much time to advance to a point in the game where it is more fun.

Modifying your own game client for cheating purposes is one thing, but alter-ing how other player’s client works is another matter entirely. One of the things that make virtual worlds so appealing is the number of ways that users can inter-act with one another. Whether it’s by giv-ing objects to other players, chatting, or using voice, these are all ways for a player to force another player’s virtual world cli-ent to parse data and potentially exploit an underlying vulnerability.

A few months ago, I and another secu-rity researcher, Dino Dai Zovi, set out to write a proof of concept exploit for a vir-tual world to demonstrate this security risk. We chose Second Life because of the easy (and supported) ways to convert real money to the currency used in the virtual world, called Linden dollars. If we could steal another player’s Linden dollars, we would be able to cash them out for real money.

“We decided to work this vulnerability into a full remote Second Life exploit, since Apple traditionally takes a few weeks to patch these types of flaw”

As a professional bug hunter, I set out looking for a vulnerability in the Second Life game client, which happens to be open source, as well as any libraries it uses. But pre-empting our research, another researcher, Krystian Kloskowski, had already discovered and announced a vulnerability in Apple’s QuickTime Player.4 The Second Life client uses QuickTime as its media rendering engine. As part of the virtual world, it is possible to embed pictures, video files,

and sounds in objects created by players, and it is the QuickTime libraries that render this data. This bug was particu-larly easy to exploit since it was a stack overflow. We decided to work this vul-nerability into a full remote Second Life exploit, since Apple traditionally takes a few weeks to patch these types of flaw.

Building the Second Life exploitIt wasn’t long until we had a QuickTime remote exploit. We still had to somehow put this in the Second Life virtual world. As I mentioned, it is possible to embed media onto objects, so I entered the virtu-al world and created a small cube. I then associated a URL with the cube which pointed to the malicious QuickTime media file hosted on my server.

It is important to note that the way this transaction is conducted is contrary to the typical architecture of virtual worlds. In this case, when an avatar enters my piece of land, the Second Life server informs them there is media available for them at the URL I specified. Their client then goes directly to my server and requests the media from me, which I provide. This interaction does not take place through the Second Life servers, which gives the attacker the power to selectively choose when to deliver an innocent or malicious payload and also prevents Linden Lab, the creator of Second Life, from filtering the malicious payload.

Now, any avatar that wandered onto my land and had their client configured

to view multimedia would immediately be exploited by whatever payload we chose. With some effort, we were able to make the exploitation completely trans-parent to the user. That is to say, the vic-tim would still be able to wander around the virtual world and interact with it normally, with our payload executing silently in the background.

Fun with avatarsThe only missing ingredient at this point was exactly what to do once we had con-trol of the victim’s computer. Any attacker using this method could do what most attackers normally do. They could eas-ily install keyboard sniffers or rootkits, or turn the computer into a spam bot. However, in this situation, they have one more option, and that is to do exploit the fact they are executing code in the context of the Second Life client. They can not only completely control the victim’s com-puter, but also the victim’s avatar.

Avatar control includes controlling the physical movement of the avatar, making the avatar teleport, making it speak and yell whatever the attacker chooses, or mak-ing it give the attacker all of their Linden dollars. This lowers the barrier to criminal activity. A typical 15 year-old script kid-die may not know how to take personal information gathered from a PC and profit from it, but they can surely steal a player’s Linden dollars and quickly cash them out.

From a technical perspective, it is difficult to control the actions of the avatar. It requires executing code from

Figure 2: Multimedia transactions in Second Life take place directly between the client and the server and do not pass through the central server.

VIRTUAL WORLDS

6Network Security April 2008

within the Second Life client in a way that was not intended. To do this, we wrote a DLL and had the payload (bor-rowed from Metasploit) inject the DLL into the process. We then had the DLL call various functions in the Second Life binary. These are not intended to be called except where expected, because they are not APIs, so we had to reverse engineer the binary to figure out how many arguments the functions took, what calling convention was used, and the types (and reasonable values) of each argument passed to the function. Second Life is written in C++, meaning that the functions we wanted to call are object methods, and accessed not only the arguments that we pass in, but global variables and object members. All of this information needs to be set up prop-erly before the function is called or the viewer will crash.

We needed to reverse engineer the binary to see how to call the functions because the payload worked at a very low level. This means that the source code wasn’t entirely helpful. However, having the source code did help when it came to finding useful functions to call. The functions we called included getBalance (to find how many Linden dollars they had), giveMoney (to steal the money), sendChatFromViewer (to make the avatar shout something), and start CurrencyBuy (to buy Linden dol-lars from an on-file credit card).

“We needed to reverse engineer the binary to see how to call the functions because the payload worked at a very low level”

Once we had the proof of concept complete, we notified Linden Lab of the problem. The architecture of the system meant that there was very lit-tle the company could do, short of disabling multimedia altogether. It promised to reimburse anyone who had their Linden dollars stolen through this type of method, and also ensured that newer versions of Second Life would require the most up to date version of QuickTime to be installed for multi-media to function in the virtual world. Unfortunately, it did not require users to upgrade their Second Life clients to this new version before entering the vir-tual world. We presented our research to the community at the Shmoocon conference in Februrary.5 This included a live demonstration with an unusual spectator.

A broader dangerIt is important to note that this problem isn’t specific to Second Life. All users in all virtual worlds are at risk to this type of attack. Any time a user’s computer is interacting with data provided from other users, there is risk. This risk is

compounded by the fact that these vir-tual worlds, by design, are trying to be as immersive as possible. They include sound, images, and video, and often allow users to create their own content. Also, unlike the real world, it is much harder to describe exactly what is dangerous in a virtual world. There are no easy rules such as ‘don’t click on attachments’ here. The point of virtual worlds is to explore, but that exploration can be a risky endeavour.

As virtual worlds become more main-stream, these risks will expand. Our partic-ular proof of concept was tied to the piece of land that the object was created on. However, had the Second Life architecture been slightly different, it is conceivable that the object with the exploit could have been constructed to be carried around, like a bomb ready to explode. Likewise, it is easy to imagine a scenario whereas a similar exploit could act as a worm and infect all the objects in a virtual world.

It is conceivable that in a very short time period, a hacker could obtain all of the wealth in Second Life and cash it out. Currently, this is estimated at approxi-mately 4.5 billion Linden dollars, or just over $17m.6 That wouldn’t be a bad haul for a few minutes of work. As in the real world over the past decade, there will likely be counter measures and additional secu-rity put in place in virtual worlds, once this threat is realised. This will inevitably be fol-lowed by new ideas to thwart the counter measures, and the arms race will continue. I can’t wait to see how it develops.

References

1. Habbo virtual world web site, Sulake Corporation Oy <www.habbo.com>

2. Second Life virtual world, Linden Lab <http://secondlife.com/>

3. Exploiting Online Games: Cheating Massively Distributed Systems, Greg Hoglund and Gary McGraw, Addison-Wesley, 2007

4. Apple QuickTime RTSP Response Header Content-Type Remote Stack Based Buffer Overflow Vulnerability, Security Focus Nov 2007 <www.secu-rityfocus.com/bid/26549>

5. Shmoocon web page, Shmoocon Security Conference <www.shmoocon.org>

6. http://secondlife.com/whatis/economy_stats.php

Figure 3: A view of Second Life. The small pink box contains the exploit shortly before my avatar gets taken over. The small avatar holding the sign is a Linden Labs employee who stopped by to watch the demonstration.

VIRTUAL WORLDS