Advisory: Dark Age of Camelot - Weak encryption of network traffic exposed personal information.

[Todd Chapman <tchapman () leoninedev com>]

----------------------------------------
Security Advisory

Full advisory available in HTML, PDF and TXT formats at
http://capnbry.net/daoc/advisory.html
Certain sections omitted from email to keep the length down.
----------------------------------------
Software:
    Dark Age of Camelot from Mythic Entertainment
    Including Shrouded Isles & Trials of Atlantis (ToA) Expansion Packs
    http://www.darkageofcamelot.com
    European version hosted by GOA.
    http://camelot-europe.goa.com/en/home.php

Affected Version:
    North America - all versions (including last beta of ToA) previous
    to 1.66 live patch (game client is patched to latest version upon
    initial connection)
    Europe/Italy/Korea - Mythic stated that they use a different
    process and were not affected.

Platform:
    Windows

Issue:
    Weak encryption in game client exposed customer billing and
    authentication information during transmission.

Date(s):
    10/22/03 - Original advisory to vendor
    12/11/03 - Public advisory

Status:
    Mythic issued an updated login client (login.dll) on 10/28/03 to
    use new encryption (described as "strong RSA encryption") for
    billing information. The login binary has undergone several updates
    since then. On 11/24/03 the login client expanded use of the new
    encryption to protect authentication information and significantly
    changed certain packet payloads. One side effect of the payload
    changes is that they prevent old versions of the login client from
    functioning. Note: The game client (game.dll) still sends a second
    authentication in the old insecure manner.

Authors:
    Bryan Mayland (bmayland () capnbry net)
    Todd Chapman (PintOStout () yahoo com)

----------------------------------------

Table of Contents
1) Introduction
2) Bug Summary
*3) Technical Details
*4) Code
5) Proposed Workaround / Fixes
6) Updates since initial contact w/Mythic
7) Conclusion

* Omitted from e-mail version
----------------------------------------

1) Introduction

Dark Age of Camelot (DAoC) is a fantasy based Massively Multiplayer
Online Role Playing Game (MMORPG) developed by Mythic Entertainment
(http://www.mythicentertainment.com/). As an MMORPG, DAoC can only be
played on-line for a monthly subscription fee of $11-$13 based on
billing plan. DAoC went live in October of 2001 and according to Mythic
has grown to 235,000 subscribers as of late September 2003
(http://www.mythicentertainment.com/press/fast502003.html). In addition
over 600,000 have played the game worldwide since its release
(http://www.mythicentertainment.com/press/goldedition.html). Mythic has
also released two retail expansion packs: Shrouded Isles and Trials of
Atlantis(released on 10/28/2003). Dark Age of Camelot is available in
other parts of the world via access to the North American server or by
local partners. In Europe the game is hosted by GOA
(http://camelot-europe.goa.com/en/home.php).

The original inspiration for researching this problem in DAoC stems
from a the long term availability of cheating utilities referred to as
“radar” programs. These programs allow a user to see information the
game client hides from the user. Radars are usually implemented using a
packet sniffer to read the game's network traffic. Such radar programs
have been freely  available for Dark Age of Camelot since shortly after
the game's release.

One open source program, known as Odin's Eye, gained notoriety among
players in November, 2001.  Mythic was fully aware of these programs
and had one of their developers comment on Odin's Eye in December of
2001 (http://camelot.allakhazam.com/news/sdetail421.html?story=421).
Odin's Eye evolved into a SourceForge hosted project under new
developers known as Excalibur (http://excalibar.sourceforge.net/) which
has resulted in several other derivatives as well (Cheyenne,
DAoCSkilla, etc...). The encryption algorithm for the game's network
communications has never changed previous to this advisory. The
symmetric encryption for game data uses a shared 12 byte key,
transmitted in the clear at the start of a network session, as part of
a simple XOR process.

Full Disclosure Note: Bryan Mayland became a maintainer (although was
not an original developer) of the Excalibur project in 2002 and has
developed other utilities derived from this code.

----------------------------------------

2) Bug Summary

Seeing the long term exposure of the game's communications, we decided
to take a look at the login program for more serious problems. Upon
launching the game executable, the program uses HTTP to contact the
patch server and download new versions of game content and executables.
Authentication and, if necessary, account update takes place next using
the login.dll. Our investigation of captured data revealed that the
login process uses the same encryption algorithm as the rest of the
game with only one difference: It uses a 13 byte key instead of a 12
byte key. With minor changes to publicly available code, we were able
to read the login packets. We chose the Delphi-based DAoCSkilla code
base for our initial test then tested the ease of adopting the old
Odin's Eye application to the same use. DAoCSkilla and Odin's Eye
source code is available via CVS under the Excalibur project on
SourceForge. The resulting utility allowed us to see the user's
authentication information, and if a user was activating an account,
all personal and billing information was available including credit
card number and expiration date. Authentication information is
transmitted multiple times during the process of loading the game. We
tested the exploit against the latest versions of the DAoC client, the
Shrouded Isles expansion, and the Trials of Atlantis beta and it worked
in all cases.

Testing Note: All tests for this issue were run upon data captured from
our own personal machines. No “in the wild” testing was done.

Potentially mitigating factors for this exploit include:
    A) The attacker has to perform some style of “man in the middle”
    attack to be able to sniff the packets.
    B) For a particular user, billing information is only entered (and
    transmitted over the wire) when activating or reactivating an
    account or change billing information. Login information is the
    only commonly transmitted private data.

----------------------------------------

3) Technical Details

This section avaiilable in full version at
http://capnbry.net/daoc/advisory.html

----------------------------------------

4) Code

This section avaiilable in full version at
http://capnbry.net/daoc/advisory.html

----------------------------------------

5) Proposed Workaround / Fixes

The user was fairly limited in their options until Mythic updated their
software to use more appropriate methods for the transmission of
personal and billing information. The only options for a user to
protect their data were:

A) Use an alternative payment method such as the IPS option provided.
IPS transactions are handled for Mythic by paybycash.com
B) Avoid activating/re-activating an account.

There are two areas which required immediate improvement.

   1. The initial authentication against the login servers by login.dll
   2. The transmission of billing/personal information.

The initial authentication and the gathering of billing information
processes both needed to be re-engineered to use more acceptable
security mechanisms. At a minimum, the billing process should use a
protocol such as SSL v3.0 (according to our reading of the American
Express on-line policy this is required for their merchant accounts).
In addition, other authentication methods that do not send the password
to the server (using the standard game protocol) should be investigated.

In addition, there are two areas which we suggested additional
improvement.

   1. The repeat authentication that happens when the game.dll connects
   to an actual game server.
   2. The patching process.

The method for connecting a user to the actual game server should be
revised to prevent theft of account login information. The
authentication mechanism should be changed so that the account and
password are not retransmitted using the standard game protocol after
the initial login process in login.dll. Use of a system to pass around
time limited certificates issued to the client at the initial
authentication or use of a challenge/response system would offer
greater security.

The patch process should stop providing updates to the entire
application to non-authenticated users. One solution is to execute a
two step patching process. When the client is first launched, only the
login related files are patched. Once the login client is patched, the
user can then be required to authenticate before receiving the
remainder of the game executable and data files. This prevents
non-customers from keeping updated copies of the program for
examination/exploitation.

----------------------------------------

6) Updates since initial advisory to Mythic

We emailed Mythic and GOA with the initial version of the advisory on
October 22, 2003 and sent a follow-up to Mythic on October 27, 2003.
The Trials of Atlantis expansion for the Dark Age servers in North
America went live on the morning of October 28. We noticed users
reporting problems with the login on various Dark Age related forums
and downloaded the patch. The login client had been updated to use
additional encryption for the packet used during transmission of
billing information. No changes had been made to how account
authentication information was transmitted. Later that afternoon we
received correspondence from Mythic reporting that the new login.dll
uses "strong RSA Encryption”. The initial versions of the new DLL still
had debug code and assertions that allowed us to clearly see that it
used LibTomCrypt's (http://www.libtomcrypt.org/) implementation of RSA
public key encryption using PKCS #1 v1.5 style padding). Neither one of
us were familiar with LibTomCrypt previously and have not found much
information on how battle tested” the library is. During the exchange
of additional emails, no additional technical information was provided
to us including key strength or how the key was exchanged.

The last significant update that we tracked was on November 24th. This
new login.dll used the new encryption process to protect the
authentication information and changed certain packet structures which
had the side effect of preventing old versions of the login.dll from
functioning any more. One item to note is that the game.dll still sends
the additional authentication using the old protocol so this
information is still vulnerable. Also on this date, we received our
last message (at this time) from Mythic. They did state that their
international partners use a different process than the North American
client and were not vulnerable.

----------------------------------------

7) Conclusion

The current state of the situation appears to be that the major
weakness with transmission of billing information has been improved.
While we cannot confirm all the specifics of the solution in place, the
documented exploit is no longer usable. Since they state that their
international partners are not vulnerable to this same exploit, we feel
there should be no harm in discussing the technical details of the
exploit. LibTomCrypt looks to be a useful tool but we're unsure of how
much scrutiny and testing it has received. In addition, the question of
key exchange is an open issue.

The main purpose of this advisory is to inform the general public that
may have been exposed by this problem (at least one state in the U.S.
now requires such notification). Users of DAoC are advised to update
their passwords to protect their accounts. In addition, any customer
who provided their billing info via the DAoC North American client
previous to October 28, 2003 and does not aggressively audit their
credit card statements should consider doing so. To be clear, we are
not aware of any other exploit specifically tailored for DAoC billing
data and Mythic did correct the issue within a week of notification.
However, the code that formed the basis for these demonstration
exploits was made publicly available in late 2001 so it is reasonable
to surmise someone looking to exploit this type of vulnerability may
have noticed it.