----------------------------------------
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@private)
Todd Chapman (tchapman@private)
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.
This archive was generated by hypermail 2b30 : Tue Mar 23 2004 - 15:28:02 PST