MOUL security discussion

[Chacal]

In other discussions, we talked about things that can crash the MOUL server or even corrupt the vault.
With the amount of expertise now concentrated in this GoW forum, I wonder if we could start thinking about ways of advising and helping Cyan secure the servers. This is an area I have experience in.

Wearing my IT Security ResEng hat, with the increased interest in hacking Uru (such as what we do here), security by obscurity is no longer a valid strategy (if it ever was). Competent IT security experts don't rely on obscurity, no matter what the layman's perception is.

Also, from a QA perspective, it doesn't make sense to say "this function is dangerous, so let's never use it otherwise it might crash the vault". If the function is needed, then we should say "this function is dangerous, so let's make sure it is used properly and let's test it thoroughly before releasing the Age".

Also, Cyan should say "we have found several functions that are dangerous to the server, such as linking, commands sent from modified client-side python code such as adminKI and flymode. Let's fix the server code so it's not vulnerable to client-side events anymore".

The following are not safeguards and we should stop relying on them:

- Hope that pirates will not discover that you can do pretty much what you want using client-side python code;
- try to keep UU userKi and adminKi code secret;
- tell people not to use dangerous hacks such as flymode;
- put restrictions on Huru tools so they won't open Cyan Ages.

What we should do:

- Invite Cyan devs to participate in discussions here (I'm on it);
- ask Cyan devs to share the MOUL architecture and security model;
- track down and invite the original hackers who started reverse-engineering Uru in 2004 (leading to the current tools), and those who worked on analysing captured packets when the imminent closing of the original Live was announced in 2004 (leading to the Alcugs server).
- do a risk analysis, based on probability and impact on MOUL and its players;
- suggest best solutions for reducing the main risks. Solutions should offer the best ROI, in keeping with what resources Cyan can spare for security.

Topics for discussion should include:

- Securing the client code (integrity checking, code review, input filtering, elegant recovery from exceptions and network problems...)
- Providing a secure API for coders (thanks Trylon)
- Securing the server code (input filtering, code review, managing exceptions, recovery...)
- Securing the vault (sanity checking, integrity assurance, health monitoring)
- Securing communications;
- Securing architecture (redundancy, managing performance problems, intrusion detection and prevention...)
- Precise QA procedures for user-submitted content (unit testing in the prp file (could be automated), functional testing by Maintainers)
- ...

From our perspective, the most important thing is unit testing in the prp file. All the information about whether or not the Age is dangerous to the MOUL server is in there.

It is possible that some might still think such things shouldn't be discussed in public. That perception is wrong but difficult to get rid of, and maybe more realistic until the biggest risks are taken care of, so I'm prepared to live with secrecy if needed. I guess it would be acceptable to move it to a private forum, as long as access is not limited to a closed elite.

What do you think?

[Trylon]

An option we should also seriously consider is to develop some sort of "official" API that writers could use to safely perform linking and access certain vault stuff.

At first that would only work on CC, but it could be expanded (in conjunction with cyan) to service Live...

[Chacal]

I'm glad you mention this because that is what I tell my customers when I do a review of their development process. Security shouldn't be left in the hands of the individual programmers, they should be constrained to using an enterprise framework for all sensitive functions. It makes a lot of sense in terms of both cost and security.

I understand from what paradox said in the past that this is your intent with Huru tools.

Thanks, I'll add it to my first post.

[Tsar Hoikas]

An option we should also seriously consider is to develop some sort of "official" API that writers could use to safely perform linking and access certain vault stuff.

At first that would only work on CC, but it could be expanded (in conjunction with cyan) to service Live...

In case you haven't noticed, Cyan already has that handled (see: x*.py). For example, the correct way to use a linking book is to pass arguments to xLinkingBookGUIPopup.py

Also, the vault API included in Plasma is so very simple that any average person who can write simple python would be able to use it. The allegations of constant vault corruption due to "hacks" are pretty senseless because it takes a sheer idiot doing something completely idiotic to corrupt a vault. I hacked the devil out of my UU shard and never corrupted a vault once.

[Trylon]

Good point
Now go write a tutorial on the correct way of working with this python stuff !!!!

[belford]

For what it's worth, this plan looks wise to me. Both on the "stop relying on X" and the "do Y" parts.

There are obviously many degrees of "corrupting the vault". (E.g., you could modify an avatar entry such that: (A) ... the player can't log in. (B) ... the avatar's home is set to someone else's private Bevin where he wasn't invited. (C) ... the avatar appears as a Bahro to other players. (D) ... the avatar has no GZ Nexus link even though he has solved the puzzles that are supposed to lead there. (E) ... the avatar has a Myst linking book even though he's never solved any of the puzzles that are supposed to lead there.)

Without investigating, I assume that client-side Python code can do all of those things. All of them are "wrong states", but for varying community standards of "wrong". Cyan will care about some of them. (Probably all of those five examples, but there will be some line they don't care about any more. You get down to (Z) pushing a button in Ahra Pahts opens a door elsewhere in that age, and that's clearly okay.)

My point is, the first stage of the process is coming to an agreement with Cyan about defining what's legal. Then you can think about how to secure the system against illegal action.

[Chacal]

Also, the vault API included in Plasma is so very simple that any average person who can write simple python would be able to use it. The allegations of constant vault corruption due to "hacks" are pretty senseless because it takes a sheer idiot doing something completely idiotic to corrupt a vault. I hacked the devil out of my UU shard and never corrupted a vault once.

Yes, but vault corruption is but one of the possible (?) impacts.

It remains that the server shouldn't accept just any message from just any client.

For some other games, we've had secured client-server admin tools for years. I'm on the support team for BF2CC, an admin tool for BF2 game servers. I've been using it on several BF2 game servers for almost 3 years in the testosterone-rich BF2 world which is much more hostile than MOUL, and so far it has yet to be hacked. This was possible because BF2CC has been build with security in mind from the start.


Adding security after development is completed is much more difficult.

My point is, the first stage of the process is coming to an agreement with Cyan about defining what's legal. Then you can think about how to secure the system against illegal action.

Yup. This is part of the risk assessment process.

Risk is the impact of successful attacks. It is a result of Impact X Probability.

- Impact is how much the attack would hurt MOUL or Cyan (either financially, or in loss of confidence, etc).
- Probability is a factor of: motivation (how much pirates would want to carry out the attack), complexity (how hard it would be) and danger (how likely to get caught).

Example: The impact of someone entering the data center and stealing the servers would be devastating. Physical security reduces the probability of this attack to nearly zero (low motivation, high complexity, high danger). As a result, the risk is low enough to be acceptable to Cyan, so no further security measure is needed.

Example: The impact of someone using client-side python code to alter avatar parameters in the vault is rather high (users get angry, some bad rep on the forums, some loss of confidence leading to reduced registrations, possibly an impact on disponibility as a vault restore might be necessary). Probability, however, is high (high motivation, low complexity, low danger). The resulting risk is high enough that it is not acceptable and should be addressed immediately. Impact can be lowered by making the server and the vault more resilient to attacks and more suspicious of client input, and probability can be lowered several ways (reduce the attack surface by securing the code, filter inputs, monitor messages, etc). After all this, the resulting risk is hopefully acceptable.

What you are saying goes into impact, and you are right, it is for Cyan to determine this. As you can see, it is not as simple as "legal or illegal".

[BAD]

No one is hiding the adminKI code. No one is releasing it either. End of story.

If you want the UserKI code, decompile it yourself. It isn't hard at all.

Who is telling people not to use flymode? It's been out for ages, and practically everyone knows about it. The only time it was ever ASKED not to be used was on UU shards because it was found to actually crash the servers. Work was being done to fix it for that purpose, but alas, UU ended.

I also don't see how we could possibly put restrictions on tools that couldn't be easily reversed to open Cyan files. As you say it would be futile.

I think it is a great idea to invite Cyan devs to this board. Good luck.

They will never share the MOUL architecture publicly. Do you happen to allow your company's system information to leak all over the internet?

If we wanted to get the original creators of such things as the Alcugs servers, AdminKI, and others. We would have to somehow convince them that we are not going to treat them as badly as those that surrounded them back then. Tall order if you ask me.


I think you have convinced yourself that most people agree with you regarding handling of information from Cyan. Even if that was true, Cyan will not release any of their code, nor have open discussions with this entire board. Your aiming your sights at an ideal. Prepare to be really disappointed.



Alternative plan........

We don't worry about the security of Cyan's servers, because they are not our responsibility. We worry about our ages working on the client. When we do submit our ages to Cyan for possible addition to MOUL, Cyan will tell us what they want us to do to make the ages work. This may require some people signing NDAs and doing things in secret (oh no!). This is just a game not a government. People are here to have fun and make cool ages. We need to stop putting so much weight on issues that will have no bearing on the actual work of building ages.

[Aloys]

Bad is totally right.
However I'd like to comment on that part:

When we do submit our ages to Cyan for possible addition to MOUL, Cyan will tell us what they want us to do to make the ages work.

Yep, and that can't come too soon.. Unfortunately, again, right now for some reason communication isn't their greatest skill, and we are heading for a disapointment.. (although I'd love to be proven wrong)
I have no idea how or when they plan to start including custom ages in Live but I have a itching feeling that we will be the last one aware of it..

[Chacal]

I think you have convinced yourself that most people agree with you regarding handling of information from Cyan. Even if that was true, Cyan will not release any of their code, nor have open discussions with this entire board. Your aiming your sights at an ideal. Prepare to be really disappointed.

When I offer help and it is rejected, I don't feel disappointed. I feel I have done what I could. Sometimes my customer do that and I'm OK with it. After all they assume the risk, not me. I would feel BAD if I didn't offer help, as you are proposing. And yes, I'm aware that they probably won't share any information without an NDA. Code, probably never. But hey, maybe they can't afford hiring anyone for security and would like some volunteer help from knowledgeable people here.

Maybe I'm overly optimistic, maybe you've been at this too long and your glass is stuck at half-empty. We'll see.

MOUL is not our responsibility, but if it goes down again we are the ones who lose a great game. No more having fun and making cool ages.

We all have our interests. For me, this is much more important than, say, a guild structure.