this didnt effect the euro players.. right? without links

[Cavex ElSaviour]

A friend of mine emailed me this to want me. He didnt know there was a diff between Euro and US. as far as i can read this doesnt apply to us euro players.. right?

note: by request of the mods the links to the original has been removed.

----------------------------------------
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://
Advisory in text format:
http://
Advisory in HTML format:
http://
Advisory in PDF format:
http://


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

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 issued last December at http://capnbry.net/daoc/advisory.html
or http://www.securityfocus.com/archive...0/2003-12-16/0

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.

[Ning]

Billing information aren't in the login client for DAOC Europe (but the on offical site)

[Sharma]

Cheers Cavex.

[NetNifty]

Possible to get the login details tho :/

[GReaper]

Originally Posted by NetNifty

Possible to get the login details tho :/

It's been possible for the past 2 years or more?

Someone gives you a security advisory after all this time and now you're worried about it?!?

[Raear]

Originally Posted by GReaper

Someone gives you a security advisory after all this time and now you're worried about it?!?

It's kinda hard to worry about something you don't know about though.

[Cavex ElSaviour]

Originally Posted by GReaper

It's been possible for the past 2 years or more?

Someone gives you a security advisory after all this time and now you're worried about it?!?

And i was more worried about my cc details then my login details. they expire a lot slower then the login details and can do potentially more harm.

[Daedalus]

A similar exploit allows people to sniff the game username and password. But face it, the only way to do that is to actually install an application on the victem's computer, so even more the reason to have a decent firewall (and configured properly!) installed on your computer.

(and for those with routers, make sure that there's a secure password on it, and the latest firmware)

[NetNifty]

Most common use of a "man in the middle" attack is in cybercafes where the internet traffic is configured to travel through the computer which provides the link, filtering system etc between the internet and the network within the cyber cafe. Just another reason not to play DAoC in one

[GReaper]

GOA actually did something right by switching to secure HTTP for account pages. Your subscription username/password will be reasonably safe as they're seperate from the game username/password.

However it is risky to play DAoC on a network you don't trust. Anyone could sniff out the username/password.

[Driwen]

Originally Posted by GReaper

GOA actually did something right by switching to secure HTTP for account pages. Your subscription username/password will be reasonably safe as they're seperate from the game username/password.

However it is risky to play DAoC on a network you don't trust. Anyone could sniff out the username/password.

but atleast with goa's setup it is your game password, which can be changed easily (with mythic there doesnt seem to be a difference in account/game pw?).

And worrying part of this is that mythic has been warned about their system not being secure before, but it seems that apart from fixing the exploit that was pointed out they did nothing else.

[Prudil]

Encryption of the gameclient is implemented in the 1.68 client. So the problem has been issued and solved. Next..... (tho it took Mythic 2,5 years to implement...go figure :P )

[Driwen]

Originally Posted by Prudil

Encryption of the gameclient is implemented in the 1.68 client. So the problem has been issued and solved. Next..... (tho it took Mythic 2,5 years to implement...go figure :P )

not really as you can fool the client into thinking he is talking to the right server. As there is no way to know that the send key is from mythic atm.It also wouldnt be such a problem if this weakness just existed for logging into the game(like with goa), as then you only need to change your game password and you are safe again. However mythic login client is also the way to go to the billing information.

Also this survey is after the 1.68 encryption has been added, the makers think its still fairly easy to steal someones password and also peoples creditcard info.

[Cyfr]

Originally Posted by Prudil

Encryption of the gameclient is implemented in the 1.68 client. So the problem has been issued and solved. Next..... (tho it took Mythic 2,5 years to implement...go figure :P )

Encryption can and has been broken

[Healer McHeal]

if some one does hack in and get your CC details tho, u can have the card canceld, but it dont mean u wont lose any money :/ as i dunno how banks will see it with if they can give your money back after the card got used for something