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.