[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Full-Disclosure] Advisory: Dark Age of Camelot - Weak encryption of network traffic exposed personal information.



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

Full advisory available in PDF and HTML 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.




---
Todd Chapman


_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html