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

From: Todd Chapman (tchapman_at_leoninedev.com)
Date: 12/12/03

  • Next message: VeNoMouS: "Re: [Full-Disclosure] RE: FWD: Internet Explorer URL parsing vulnerability"
    To: bugtraq@securityfocus.com, full-disclosure@lists.netsys.com
    Date: Thu, 11 Dec 2003 19:47:14 -0500

    Security Advisory

    Full advisory available in PDF and HTML at
    Certain sections omitted from email to keep the length down.

    Dark Age of Camelot from Mythic Entertainment
    Including Shrouded Isles & Trials of Atlantis (ToA) Expansion Packs
    European version hosted by GOA.
    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
    Europe/Italy/Korea – Mythic stated that they use a different process and
    were not affected.
    Weak encryption in game client exposed customer billing and authentication
    information during transmission.
    10/22/03 - Original advisory to vendor
    12/11/03 – Public advisory
    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.
    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.
    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

    The original inspiration for researching this problem in DAoC stems from
    a the
    long term availability of cheating utilities referred to as “radar”
    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
    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
    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
    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
    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
    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
    over the wire) when activating or reactivating an account or change billing
    information. Login information is the only commonly transmitted private


    3) Technical Details

    This section avaiilable in full version at


    4) Code

    This section avaiilable in full version at


    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
    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
    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
    for examination/exploitation.


    6) Updates since initial advisory to Mythic
    We emailed Mythic and GOA with the initial version of the advisory on
    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
    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
    and were not vulnerable.


    7) Conclusion
    The current state of the situation appears to be that the major weakness
    transmission of billing information has been improved. While we cannot
    all the specifics of the solution in place, the documented exploit is no
    usable. Since they state that their international partners are not
    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
    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

  • Next message: VeNoMouS: "Re: [Full-Disclosure] RE: FWD: Internet Explorer URL parsing vulnerability"

    Relevant Pages

    • Advisory: Dark Age of Camelot - Weak encryption of network traffic exposed personal information.
      ... to 1.66 live patch (game client is patched to latest version upon ... authentication information during transmission. ... The login binary has undergone several updates ... all personal and billing information was available including credit ...
    • [VulnWatch] Advisory: Dark Age of Camelot - Weak encryption of network traffic exposed personal info
      ... to 1.66 live patch (game client is patched to latest version upon ... authentication information during transmission. ... The login binary has undergone several updates ... all personal and billing information was available including credit ...
    • Re: [PHP] Is this the best way?
      ... Why is Jason schreefing again? ... maybe I should edit my authentication function... ... attempting to login. ... really be either attempting an authentication *or* outputting some ...
    • Authentication Sharing Across Apps
      ... For my part "B" question that I had (Login App was not returning ... authentication to calling app), I found the solution. ... Basically, in both the Login App and Calling App Web.Config, I did ... authenticated connection with SQL server. ...
    • Re: [PHP] Is this the best way?
      ... Jason Pruim schreef: ... I am attempting to add a little error checking for a very simple login system. ... So maybe I should edit my authentication function... ... really be either attempting an authentication *or* outputting some message ...