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)
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 (email@example.com) Todd Chapman (firstname.lastname@example.org)
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.
[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
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.