[VulnWatch] Dark Age of Camelot login client vulnerability to man in the middle attack

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

  • Next message: advisory_at_rapid7.com: "[VulnWatch] R7-0018: OpenBSD isakmpd payload handling denial-of-service vulnerabilities"
    Date: Tue, 23 Mar 2004 16:10:44 -0500
    To: bugtraq@securityfocus.com, full-disclosure@lists.netsys.com, vulnwatch@vulnwatch.org
    
    

    ----------------------------------------
    Security Advisory
    ----------------------------------------
    Software:
         Dark Age of Camelot from Mythic Entertainment
         including Shrouded Isles & Trials of Atlantis Expansion Packs
         http://www.darkageofcamelot.com

    Affected Version:
         North America – all “live” versions up to initial 1.68 release.
         Exploit fixed during subsequent 1.68 patches (exact date unknown)

    Platform:
         Windows

    Issue:
         Flaws in login client allows attacker to read customer information
         using man in the middle attacks.

    Date(s):
         2/18/04 - Original advisory to vendor
         3/23/04 – Public advisory

    Status:
         Fixed for billing data.
         No response from the vendor to the original notification e-mail was
         ever received. Some time after the initial live 1.68 release, a new
         login.dll was issued with a billing fix. Account login and
         password are still vulnerable. Current login.dll is dated
         03/01/2004 2:16:50 PM, file size is 213,064, and MD5 sum is
         62F47E62 D88C0AED 0EA11012 6097C32D.

    Authors:
         Bryan Mayland (bmayland@capnbry.net)
         Todd Chapman (tchapman@leoninedev.com)

    Advisory home page:
         http://capnbry.net/daoc/advisory20040323/
    Advisory in text format:
         http://capnbry.net/daoc/advisory20040323/daoc-advisory2.txt
    Advisory in HTML format:
         http://capnbry.net/daoc/advisory20040323/daoc-advisory2.html
    Advisory in PDF format:
         http://capnbry.net/daoc/advisory20040323/daoc-advisory2.pdf

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

    Table of Contents
    1) Introduction & Summary
    2) Bug Details
    3) Sample exploit
    4) Conclusion

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

    1) Introduction & Summary

    Dark Age of Camelot (DAoC) is a fantasy based Massively Multiplayer
    Online Role Playing Game (MMORPG) developed by Mythic Entertainment
    (http://www.mythicentertainment.com/). For more background information
    on the product and for previous security issues, please refer to
    advisory issues last December at http://capnbry.net/daoc/advisory.html.

    The current security scheme of the Dark Age of Camelot login involves
    the use of RSA public key cryptography and an RC4 based symmetric
    algorithm. The weakness of their approach is that the RSA public key is
    transmitted at the start of each session and is not digitally signed or
    verified to insure the integrity of the connection or data.

    With the release of the version 1.68 patch to the DAoC test server
    (Pendragon), Mythic upgraded the game client (game.dll) to use the
    security changes made to the login protocol. One side-effect of this
    change was to focus more eyes on the protocol. While monitoring the
    discussion on various forums dedicated to DAoC utilities and emulators,
    it became apparent that people understood how to attack the security.

    Seeing the imminent release of code for cracking the game client (which
    would then expose the login client), an e-mail was sent to multiple
    contacts at Mythic on February 18th to describe the flaws of the
    protocol. Specifically, we described how billing information was
    exposed and repeated our suggestion about going to a SSL/TLS based
    solution handling account information. This approach seems practical in
    light of the fact that the European provider of DAoC, GOA, uses web
    pages served over HTTPS to secure account updates.

    We have received no acknowledgment of the e-mail from anyone at Mythic.
    After one month had passed, we begin to prepare a formal public
    advisory and noticed that the login client had been silently patched
    (i.e. no mention in any public patch notes). The current version of the
    login client is no longer vulnerable to this billing information
    exploit. The solution implemented by Mythic was to embed a fixed public
    key into the login.dll to use for the encryption of billing data. The
    per session public key is still used for protecting the symmetric key.

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

    2) Bug Details

    The encryption scheme relies on the use of RSA public key encryption
    combined with RC4 based symmetric encryption. The encryption routines
    were originally based on implementations from LibTomCrypt
    (http://www.libtomcrypt.org/). We say “RC4 based” because of one small
    difference in the Mythic code from the LTC code. For brevity we will
    refer to it simply as RC4 from now on.

    Note: In no way are any of the flaws we've found attributable to
    LibTomCrypt code.

    At the beginning of each TCP session, the server sends a 1536 bit RSA
    public key to the client. The client then randomly generates a 256 byte
    RC4 key which is encrypted using the public key and transmitted back to
    the server. Any further communication during the session is encrypted
    using RC4. The basic login process is diagrammed below:

         Client Server
         1 Connect -------->
         2 <-------- RSA pub key
         3 Send RC4 key -------->
         4 Authenticate -------->
         5 <-------- Authenticate Success
         6 Launch game.dll

         1. Client connects to server
         2. Server generates RSA public/private key and exports the public
         key to the client
         3. Client generates RC4 key, encrypts it with RSA public key and
         sends to server
         4. Authentication information is encrypted via RC4 and sent to the
         server
         5. Server sends success message (secured via RC4)
         6. Login.dll launches game.dll passing it the account and password
         to send to game server.

    If billing information is transmitted, the data is encrypted using the
    RSA public key prior to the RC4 encryption.

    The fundamental weakness of their approach is the transmission of the
    public key at the start of each session without any type of
    verification. The key is not signed in such a way that the client can
    validate that the key came from Mythic. Any attacker able to actively
    proxy or hijack the communication can supply his own key to the client
    and read the data.

    Since this requires an active attack, the attacker can take the step of
    not passing the data along to the Mythic account servers and simply
    pretend to be the server and demand that the client provide billing
    information. Once the client provides the data, the attacker signals
    success and the login client will proceed with launching the game
    client, which communicates with different servers (and thus the
    attacker can ignore that traffic). As long as the user's account is
    valid, the game would proceed with a normal launch.

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

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

    3) Sample exploit

    The following exploit code is designed to pretend to be an account
    server to trick a login in client into thinking an account is closed
    and prompting the user to enter their billing data. In this case, no
    data is ever passed along to the real account servers.

    To simplify our test case, we relied on modifying the login.dat file to
    force the login client to talk to our program. The following lines were
    edited.

    [main]
    numofservers=1

    [daocclient0]
    addr=127.0.0.1
    port=10500

    However, the exploit can also be implemented using ARP spoofing to fool
    the client machine into sending packets to the attacking machine. An
    example setup would be use arpspoof and iptables on Linux similar to
    the one method used for the SSLsniff exploit for I.E. at
    http://www.thoughtcrime.org/ie.html.

    The code was implemented using LibTomCrypt v0.91 but newer versions
    should work. Compiled and tested on Linux and Cygwin. Note protocol
    version comment prior to definition of LOGIN_PROTOCOL_VERSION for
    testing with different versions of the login.dll (currently set to
    version of vulnerable client).

    Sample compile: gcc mystic2.c -o mystic2 -I./libtomcrypt
    -L./libtomcrypt -ltomcrypt

    File: mystic2.c available at
         http://capnbry.net/daoc/advisory20040323/mystic2.c

    Example run against 1/15/04 dated login.dll:

    user@mymachine:~/mystic2$ ./mystic2 10500
    prng registered...
    RSA key generated...
    RSA public key exported (209 bytes)...
    .Waiting for client connections.
    Client connected!
    RSA public key sent to client...
    Client sent symmetric key (256 bytes)...
    Account authenticate request:
       Account Name: MyAccount
       Password: password
    Requesting user enter their billing info...Client closed
    Client connected!
    RSA public key sent to client...
    Client sent symmetric key (256 bytes)...
    Billing Info:
       Account Name: MyAccount
       Password: password
       Cardholder's Name: Joe blow
       CreditCard Number: 1234123412341234
       Expiration Date: 11/04
       Billing cycle: 1
    Client closed

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

    4) Conclusion

    The current state of the situation appears to be that weaknesses with
    transmission of billing information are being improved but only when
    outside attention is focused upon the problem. We would hope that
    Mythic would learn to take a more proactive approach to these issues.

    As with the previous advisory, the main purpose of this advisory is to
    inform the general public that may have been exposed by this problem.
    The difficulty of this exploit is greater than the previous one (which
    was trivial) and it existed for much less time (a few months instead of
    2 years) so the danger of exposure is less.

    ----------------------------------------
    Last Modified: 3/23/2004

    Revision History:
    3/17/04 – Creation of formal advisory.
    3/23/04 – Finalizing for publication.


  • Next message: advisory_at_rapid7.com: "[VulnWatch] R7-0018: OpenBSD isakmpd payload handling denial-of-service vulnerabilities"