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!

Hacking the central heating

The central heating I have installed in my home (Integra Zero F29e) doesn't have any network functionality or possibility to interface with a computer. It's using a 2 wire thermostat as a control. The thermostat is powered from the 2 wires it uses to communicate with the central unit.


As I was interested in a computer interface, I set out to investigate what my options were. After some googling around, I got up to speed on the types of interfaces that exist for these kinds of devices. It seems there are 2 major interfaces. One is called Ebus and the other OpenTherm. Both of these have been dissected by hobbyists and therefor there are devices / schematics available to make an interface.

When I started this endevour, I only had a multimeter available. Measuring the 2 wires, it gave a voltage around 20-24v, which led me to believe it was an Ebus interface. So I put something together to convert the data on the bus to TTL levels, since Ebus is just 9600bps serial communication. However, it didn't quite work out.

While researching all this stuff, I figured an oscilloscope would come in handy and since these days you can pick up a digital oscilloscope pretty cheap, I went ahead and ordered a cheap Rigol DS1052e. Once I had the scope, it quickly became apparent that this system wasn't Ebus based.

As I was already on a shopping spree, I also got myself an Open Workbench Logic Sniffer and some arduino's.

I figured it would be simpler to bypass the bus driving circuit, so I had a look at the PCB of the central unit. The PCB was quite simple, it's nothing more than a couple of relays controlled by a microprocessor, in this case an ST62T25.

Here the scope came in handy to check the pins on the MCU, which helped me to figure out which pins were used for the transmission and reception of data. With this knowledge, I could hook up the logic sniffer on those pins and get a dump of the data transmission. Here's how it looked:

For anyone with the same device, the data of the MCU pins are available from the topside of the PCB at points J1 (green wire) and J10 (white wire), the black wire is just a ground point.

With the logic dump available, my next step was to try and decode it. Which I'll explain in another post.

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!

Fixed!

So I was finally contact by ArenaNet regarding the issue I mentioned. It seems my original mail regarding the issue I posted about, was unfortunately lost in cyberspace. So they never read my report.

Anyway, I must say I was pleasantly surprised by the way they handled it. Respect!

Fixed?!

"We've updated the game for routine maintenance only. No content changes were included. ~RB2"
-- https://twitter.com/GuildWars2/status/322082110334697472

It seems the GwSrv and AuthSrv libraries aren't on the CDN. I wonder if they finally fixed their leak?! Sad that mailing them didn't work, but posting about it got the job done... The old files however are still present.

Give a man a fish...

I guess ArenaNet has had time enough to react and fix their broken security, so it's
time to explain what exactly they messed up.

As I showed in a previous post, the game connection uses diffie hellman to negotiate the RC4 session key but stores the server's side pre-calculated in the client.

So how in hell did I calculate the server's secret?! ie. For the current release (17368) where do I get this from:

const unsigned char p[] = {
0xa1, 0xc5, 0x67, 0x7b, 0x95, 0xef, 0x74, 0x12, 0xcf, 0x58, 0xab, 0xef, 0xb0, 0x60, 0x9e, 0xa7,
0xab, 0x6c, 0x15, 0x3c, 0x6d, 0xf0, 0x24, 0xac, 0x0d, 0x02, 0x26, 0x66, 0xd1, 0x65, 0x28, 0x53,
0x29, 0xc7, 0xb4, 0xc4, 0x7b, 0xdd, 0xbc, 0x4c, 0x8d, 0xab, 0x7d, 0x6a, 0x7e, 0x26, 0xd7, 0x3c,
0x62, 0xe5, 0x66, 0x5f, 0x38, 0x9f, 0x49, 0x44, 0x6b, 0x18, 0x74, 0x9c, 0x43, 0x7a, 0xf4, 0x17,
};

const unsigned char b[] = {
0x8e, 0xe7, 0x79, 0xf0, 0x00, 0x0d, 0x31, 0xc9, 0xda, 0x45, 0x77, 0x44, 0xd3, 0x47, 0x0a, 0x26,
0x8d, 0x7e, 0xe3, 0x03, 0x02, 0x55, 0x6b, 0x0d, 0x88, 0xc7, 0x65, 0x32, 0x29, 0xbe, 0x1d, 0x71,
0x9f, 0x49, 0x00, 0xf9, 0x65, 0x97, 0xe6, 0x05, 0xda, 0x3b, 0x8f, 0xc0, 0xc7, 0x0b, 0x3a, 0x49,
0xe3, 0xfa, 0x6e, 0x2e, 0x27, 0x54, 0xab, 0x13, 0xae, 0xf5, 0x54, 0x61, 0x29, 0x4f, 0x37, 0x35,
};


To explain it.. we have to look at how the game does it's updates.

ArenaNet is using a content delivery network to distribute game updates. At startup, the game patcher will query an URL on the CDN which contains information about what the current live version is.

This information is at:
  http://assetcdn.101.ArenaNetworks.com/latest/101


Now, if you try to access this with your browser, you'll get an authentication error. To pass the authentication check, a header called 'authCookie' has to be passed. Older clients had this header clearly visible in the executable, ie:

$ strings gw2.exe.524178 |grep md5=|cut -c1-
authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=4e51ad868f87201ad93e428ff30c6691

In newer clients it's build through printf style formatting, so it's a bit more effort to get it:

$ strings gw2.exe.570713 |grep md5=|cut -c1-
authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=%s

However, the md5 value is always the same (haven't verified this on the latest clients anymore), so you can just use this value.

$ curl http://assetcdn.101.ArenaNetworks.com/latest/101 -b 'authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=4e51ad868f87201ad93e428ff30c6691'
17368 570713 22680128 570709 5108

This tells us the latest release is 17368, has a fileid of 570713 on the CDN and is 22Mb in size. Equipped with this information, we can download the latest gw2 executable:

$ curl http://assetcdn.101.ArenaNetworks.com/program/101/1/0/570713 -b 'authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=4e51ad868f87201ad93e428ff30c6691' -o gw2.exe

Easy enough...


An update contains much more than just the gw2 executable, there's also patches for the data files and other stuff.

And this is where ArenaNet made a gigantic mistake in my opinion. If you take the previous link and  increment the filenumber by one, you get something VERY interesting! For some unknown reason,  the actual server code and authentication code is also on the CDN and it's even accessible to everyone that wants a copy!!

If you take fileid 570714 and run it through objdump, you will see it's actually called GwSrv.dll and fileid 570715 is called AuthSrv.dll

Imagine my surprise when I discovered this. By that time, I had already reversed the encryption protocols used on both connections, so it didn't help me for that part, but I also knew one of those 2 DLLs would need access to the server side secret and after some investigating, it was clear the key was contained inside the DLL itself (it could aswell have been loaded from an external file).

Equipped with that info, I wrote a small tool using libbfd which looks for the keys and just dumps them. I later verified they were in fact correct.


To this day, I'm still gobsmacked that a company can make such an error. Makes you wonder how they store all the credit card information of people!

The GwSrv.dll will be particularly interesting for people trying to write an emulator, but it's also nice to get an idea of how their backend is setup.

ie.

$ strings GwSrv.dll |grep -P '^[A-Z].*Srv$'
FileSrv
BuildSrv
DllSrv
AuthSrv
GwSrv
DbSqlSrv
DbCacheSrv
StreamSrv
SiteSrv
DistSrv
AcctHttpSrv
AcctMailSrv
CrashDumpSrv
EventLogSrv
LogQuerySrv
BeaconSrv
CrashSrv
UTournSrv
ConfigSrv
DbNameSrv
BugMailSrv
LogImportSrv
CensusSrv
DummyCliSrv
DbNameTestSrv
DbSrv
RankSrv
FileIdChkSrv
IpBlockSrv
PitchingSrv
ConfigSrv
ObsCtrlSrv
GuildSrv
ReplicationSrv
AssetSrv
EconDataSrv
EconSrv
ClientErrorLogSrv
TournSrv
EmptySrv
PlayerlessSrv
BrokerSrv
ExchangeSrv
GemStoreSrv
TradeSrv
CharUserDataSrv
PortalSrv
HealthSrv
ClientErrorSrv
MetricsSrv
ItemSearchSrv
ItemDataSrv
RestoreSrv
ListTaskSrv
TournSearchSrv
ContentSrv

Pity they didn't put them all on the CDN ;-)

Proximus fail!

I got a Nexus4 the other day, but since it uses a micro sim whereas my old phone used a normal sim card, I had to get a replacement for it.
Much to my surpise, the only info I needed to provide, was my current phone number! No id card, no proof of ownership, no pin number, not even the old sim card I was replacing, .. nothing!

What's this proximus?! Social engineering courses for dummies?!