---------------------------------------- Security Advisory Full advisory available in HTML, PDF and TXT formats 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.