DAoC Security Advisory - By SecurityFocus.com

O

old.Hardbein

Guest
Here is a nice read for those of special interest :)

----------------------------------------
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://removed.soradarn00bshavetofinditelsewhere.org/) 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.

Original post: clicky

Summary:
GOAs billing systems have not been tested in this advisory.
Mythic's billing system contains documented flaws.
Mythic r aware of these flaws and r currently working on new game communication mechanics wich will make CurrentRadar programs non-functional (read: radar-nerf \o/)
 
O

old.yaruar

Guest
Originally posted by Brynn
Surprise Surprise Goa s00k

Why do goa suck because mythic use an insecure communication method?

goa != mythic
 
S

SoulFly Amarok

Guest
Why do you have to post this on a public board?

gg.
 
N

ning

Guest
Re: Re: DAoC Security Advisory - By SecurityFocus.com

Originally posted by Brynn

it seems you don't understand what you quote.
 
B

bigchief

Guest
Originally posted by Brynn
Surprise Surprise Goa s00k

Goa use an external billing system so actually its the more secure of the 2 in the sense of whats being discussed in the initial post.
 
O

old.Hardbein

Guest
Originally posted by SoulFly Amarok
Why do you have to post this on a public board?

gg.

This is a public advisory, containing public information and meant as a warning for the people who trust Mythic and their game mechanincs, how Mythic handle your Login-information and billing information. (GOA uses a different method of handeling Billling information fyi)

This advisory is easy searchable on Google.

People have the right to know imo. Then ppl will have to make their minds up in wich to continue pay for GOA/Mythics services or not. Mythic/GOA will have to do something to ensure that their customers have the sufficient security systems when handeling ppls private information (CC info, Login details etc)

^^imo
 
T

the_smurflord

Guest
Originally posted by old.Hardbein

Mythic r aware of these flaws and r currently working on new game communication mechanics

It's spelt "are".
 
O

old.Ramas

Guest
This does seem rather poor.

But you should note that the GOA setuip wouldn't pass any reasonable audit either.

tbh, nor would most public internet billing systems.

You should also note that the advisory concludes not that the exploit is still a sigificant risk, but that Mythic have what would typically be regarded as an inadequate audit process.

Personally I view this with a truly stunning level of 'not surprised'. Since the vast majority of IT based organisations outside of large banks have an inadequate audit process.

That said, since Mythic's development process is a lot more robust than those used by other MMOGs, and so tbh, you can be sure that the competition is even worse.

Not that this makes everything peachy.
 
T

Tesla Monkor

Guest
GOA's billing system is NOT integral with the login sequence.

Mythic's system is, and that's where their weakness is (was). In other words, you enter your credit card stuff in the same window in which you enter your login stuff.

Perhaps now you understand why you have TWO sets of login codes, one for the game, and one for you account. Even if the game account stuff was captured, they still can't access your credit card stuff. :)

It's not foolproof, of course, but it has a better thought out base than Mythics original setup.
 
S

SoulFly Amarok

Guest
Originally posted by old.job
All I can say is LOL

Check the links retard and think again.

Please, do make it more easier to people to get a radar prog.

gg no re -_-
 
O

old.Hardbein

Guest
I do see ur point Soulfly.....BUT

The informational value of this post was higher than the risk of revealing a link to a radar prog....
If some1 chooses to use one (radar prog) its at his/hers own risk of beeing cought/banned/named and shamed. So if u realy want to use radar there is noone stoping u to use Google etc...

If the link in my Quote is of "illegal content" I ask the moderators to kindly remove it.
 
O

old.yaruar

Guest
Originally posted by old.Ramas
This does seem rather poor.

But you should note that the GOA setuip wouldn't pass any reasonable audit either.

tbh, nor would most public internet billing systems.

You should also note that the advisory concludes not that the exploit is still a sigificant risk, but that Mythic have what would typically be regarded as an inadequate audit process.

Personally I view this with a truly stunning level of 'not surprised'. Since the vast majority of IT based organisations outside of large banks have an inadequate audit process.


Haahaa haa haa haa.

You think large banks have a decent audit process...

Trust me, I work in the sector, they don't. They don't even deal with day to day fraud with any level of competance.
 
F

Falcon

Guest
Who cares if GOAs system is secure from outside attacks when GOA just do the money stealing themselves :p

This isn't the highest risk thread, as said already it's no worse a system than certain other MMOGs. It'd in fact be easier to just hack into your average person's machine and nick their info than setting up an attack like this. Nonetheless when there IS an issue it needs to be dealt with no matter what the level of risk, and hopefully it will be dealt with soon.
 
B

bigchief

Guest
Originally posted by old.Hardbein
I do see ur point Soulfly.....BUT

The informational value of this post was higher than the risk of revealing a link to a radar prog....
If some1 chooses to use one (radar prog) its at his/hers own risk of beeing cought/banned/named and shamed. So if u realy want to use radar there is noone stoping u to use Google etc...

If the link in my Quote is of "illegal content" I ask the moderators to kindly remove it.

Just remove the names/links for the radar programs from the post. The rest is still valid and will make sense, and retains the reason why you posted the thread in the first place.
 
S

SoulFly Amarok

Guest
Originally posted by bigchief
Just remove the names/links for the radar programs from the post. The rest is still valid and will make sense, and retains the reason why you posted the thread in the first place.

Kind of obvious that.
 
O

old.job

Guest
Retards re-read the post and apologises

Does radar see stealth?

And no I'm not even thinkin of it, that is so far off the sad scale it hurts.
I mean FFS , if you had the stupid thing, you couldn't tell anyone of enemy whereabouts, or use it more than once before people got suspicious.

Or am I way off base and loads use it?
 
O

old.Hardbein

Guest
Originally posted by bigchief
Just remove the names/links for the radar programs from the post. The rest is still valid and will make sense, and retains the reason why you posted the thread in the first place.

Ok, fixed....
 
S

SoulFly Amarok

Guest
Originally posted by old.job
Retards re-read the post and apologises

Does radar see stealth?

This is argued. Does or does not.

Myself I dunno, heard not, but why wouldn't it? not like you stop sending packets :O
 
C

_cofi_

Guest
Originally posted by old.yaruar
Haahaa haa haa haa.

You think large banks have a decent audit process...

Trust me, I work in the sector, they don't. They don't even deal with day to day fraud with any level of competance.

Id love to know who you work for mate if you think banks dont have strict audit requirements.
 
O

old.windforce

Guest
tbh it takes like 20 seconds to find download for naughty software

40 more for an cc number

15 secs to download

40 seconds to install

5 seconds to read the manual


so you can be an asshole in 2 minutes :D
 
O

old.Mitsu

Guest
Radar does not show stealthers like normal players.
It does however know when stealthers are close.
 
O

old.yaruar

Guest
Originally posted by _cofi_
Id love to know who you work for mate if you think banks dont have strict audit requirements.
one of the biggest privately owned futures and options traders in europe.
I deal with banks on a daily basis especially regarding fraud. we regularly have to deal with all the major banks on fraud cases and a number of them don't give a toss about procedure and auditing.

At least in the UK the sfa does have strict auditing requirements, however a number of institutions don't fully comply to these such as a major high street bank we are dealing with who don't as a matter of course record their phone calls which is a requirement of the industry
 

Users who are viewing this thread

Top Bottom