DAoC - The middle man

We've already seen that the key generation isn't up to par, neither is the actual way how the RC4 encryption is used... but there's an even bigger issue. The game is susceptible to a man-in-the-middle attack (MITM).

The game client has no way of knowing if the traffic it receives is indeed coming from the official servers. Games like Guild Wars2 use Diffie-Hellman to exchange the encryption key, but they have the server part baked into the client binary. Therefor in a game like that, you can't impersonate the server without changing the client binary (unless they leak their server binary ofcourse *wink*).
Now, in Mythic's defense, the DAoC client does use RSA to transmit the RC4 session key to the server, which means a man in the middle attacker won't be able to decrypt this packet and sniff the encryption key (unless you found a solution for the factoring problem).

So... where's the problem then?

The issue is with the initial connection setup. The client connects to the server and sends a packet with it's info. The server then responds with the following packet:

0000: 22 01 31 01 0a 03

Which tells the client what version the server is running, but more importantly, tells the client to switch to encrypted communication mode. Yes, there's actually 2 modes the client can work in! Encrypted and non-encrypted mode.

This opens the possibility for a MITM attack. If we proxy the data between the client and the server and change the 01 into 00, we can trick the client to work in non-encrypted mode. To the server, we respond with an RSA encrypted RC4 key, which the proxy creates itself. From then on, it's just passing traffic while encrypting/decrypting the data between the 2.

Another big problem is that the communication protocol doesn't use anything like SRP to prevent people from sniffing and reusing the password. Therefor, the attacker will be able to grab the login and plain text password from the intercepted session.


As a proof of concept, I wrote a small proxy that did just that. It ran on a linux machine in between the client and the server and used the transparent proxying (TPROXY) feature of the linux kernel to redirect the traffic to the proxy program. Worked like a charm.

DAoC Random function

As I mentioned before, the generation of the RC4 key in this game can easily be instrumented to generate the secret we want.

The pseudo code to generate the RC4 key looks something like this:

repeat 0x40 times
  use rdtsc to generate 1 byte
  verify the resulting byte isn't 0
  sleep 1

This block is then RSA encrypted and exchanged with the server. From then on, all packets get encrypted with this RC4 key. One interesting thing also, is that the game doesn't use RC4 as a continuous stream cipher, instead each packet resets the RC4 cipher to the initial state. This stems from the fact that the game can use UDP for communication and therefor needs to handle the case where packetloss occurs, which would desync the state, but it also makes this less secure. I'm not an expert in cryptography, but I'm sure this enables some interesting crypto attacks to decipher the content. From what I've read, the first few bytes of RC4 are already less random than they should be, which is why it's suggested to advance the RC4 state a couple of bytes before actually using it on your data, which this game doesn't do. Couple that with knowledge of some of the payloads' fixed bytes and I'm sure a real cryptographer can decipher a stream without much effort. Now there's 1 thing they did to try and counter some of this. Instead of starting the packet encrypt from the first byte of the packet, they start it from the middle of the packet, which helps a bit with the known byte value issue.
They are also feeding back the input into the RC4 state, by incrementing the j variable by the unencrypted input byte.

Another issue with just using the rdtsc instruction to generate random data, is that this instruction can be made priviledged by setting the TSD flag in CR4, ie. cause a system trap to occur when executed in userspace / ring3, which means there's full control over what this RC4 key generator produces without even having to alter the game binary or redirecting system APIs. Example code to do something like this, can be easily found, ie. here.

DAoC vulnerability update

So I got a mail back from the janitor at Mythic regarding my vulnerability report:

Hello Karl,

Thank you for contacting Dark Age of Camelot Support.

With regard to your appeal, Ticket#: [XXXXX], we cannot field feedback or suggestions regarding how the game may be altered or improved. However, your opinions and thoughts are always valued!

To appropriately submit your suggestions and feedback regarding game content, mechanics, or design, please go to http://darkageofcamelot.com/contact. On this page, you will find a form which will allow you to submit your suggestions and opinions directly to our development team.

This email address is only for issues of a billing or technical nature, and not issues related to feedback or concerns regarding elements of the game.

Thank you for playing Dark Age of Camelot!
XXXX

 Oh boy... what can I say... FAIL!

Blast from the past

Since I've been talking about game security the last couple of posts. I figured I revisit an old target I once investigated.

Many many moons ago I blogged about getting Dark Age of Camelot to run in wine. While reversing that game, I also had a look at how the actual game connection works, because that's something that always interests me, ie. the security aspect of it. In this case, there was an extra reason to have a look, since at one time early on in the game's life, a security issue was found and reported to them:

CVE-2004-1855
Dark Age of Camelot before 1.68 live patch does not sign the RSA public key, which could allow remote malicious servers to gain sensitive information via a man-in-the-middle attack.
A more detailed description is available at:
http://capnbry.net/daoc/advisory20031211/daoc-billinginfo-exploit.html

So fast forward 10 years, you'd think it would be pretty secure by now... unfortunately it appears it's still flawed in some way. The thing is, even after all these years, the game is still susceptible to a man-in-the-middle attack. It's perfectly possible to intercept / proxy a connection from the game without needing any details / account info from the player.

So how does the game connection work?

The communication is rather straight forward. There's only 1 connection maintained between the client and the server. The game supports both UDP or TCP for it's game session. This probably stems from the old days where most players actually used a dialup connection, where you don't want TCP retransmissions to cause issues.

Most of the game packets are known. There has been an emulator around for quite some time now and since it's open source, anyone can have a glimpse at how it all works.

The connection is encrypted with RC4. It generates a random session key which gets exchanged via RSA encryption. The generation of the RC4 key could also be improved, since how it currently is done, makes it extremely easy to intercept by using some virtualization techniques. This has as effect that one can get the game to generate the key you want, without having to make any patches to the game client, which is imho not a good thing.

But worse is the fact that this all doesn't matter, due to another vulnerability. But before explaining that one, I'll see if there's still anyone in charge of the game code (most players of the game, seem to think the janitor is the only guy left in the building.. so we'll see how it goes)

Anyway, let's hope the old Mythic gang @ City State Entertainment will have a better security track record if their Kickstarter project, Camelot Unchained, funds!

Wine fun #3

The icing on the cake has finally arrived!

After reversing large parts of the game code and spending a silly amount of time in a debugger, I was finally able to track down the code path that caused the game to crash on wine.
Once that was clear, it was just a matter of comparing the difference in return values when running the game directly on a windows box.

Since I just hacked up the wine source to return the value I needed, it isn't a proper fix.. but I'm hoping the wine devs can come up with a solution that is acceptable for everyone.

The bug details can be found in Bug 10832