[Old account M4dson]

Hey dengad, you will put your server into 4.2 ? :) (Cause it seem to be down in 4.1)

[Dengad]

M4dson, on 19 September 2014 - 04:12 PM, said:

Hey dengad, you will put your server into 4.2 ? :) (Cause it seem to be down in 4.1)

I have a server 4.1 and I'm not going to change until there are people I try there to come up with something new and interesting and to me it is not difficult to write a mod under 4.2 I just don't need it . code ban will run on any version of the server he is going in iourtded . ( but it is not complete yet have a code location in which the lock such as proxy server helps a lot ).


http://urtmaps.ucoz....sv_iplocation.c

This post has been edited by Dengad: 20 September 2014 - 06:19 AM

[Mod [dswp]JRandomNoob]

Update: The oldest map on the repo used in this attack was uploaded on September 10 (and created on September 9). This does not mean that maps downloaded before these dates are guaranteed to be safe, just that I can’t find anything older. Treat any weirdness with extreme suspicion.

barfingskull (forum topic) (GitHub issue) got one of those older maps and his symptoms are slightly different from what was initially reported: in addition to auth problems, his up-to-date .019 installation was saying “4.2.018” in the lower right corner of the main menu.

An interesting sign of being compromized is that even if you’re logged out of auth the game claims it’s attempting to contact the auth server and failing.

[Evilmice]

SilverFoxZ, on 16 September 2014 - 04:49 PM, said:

I got the new key because i think i downloaded a couple of those maps but i cant put in the new key ingame because "log in" is greyed out.
I also deleted alot of stuff and repatched.

Bro, you probably got your game folder and a place where it SHOULD be in different locations. Look for /home/user/.q3a folder. There should be automatically created file "authkey". Change it. Voila!

[uJ|V00d00]

Would have thought this to be easy to fix. Simply remove the ability for a server/client to run a qvm from any file that isnt zpak*., with a sha512 hash of x, and make it impossible for any file named zpak to be downloaded by a client (if it isnt already). Ie, hash all the original game zpaks, and compare them on startup. If they dont match, shutdown the client/server or re-download the originals and restart. Then make a new cvar to switch the behaviour on and off, default being on (for those who have some need of switching it off).

If not maybe create an official spec for a pk3 file for Urt. Normally you have maps, levelshot, scripts, textures, sounds, etc. So make all clients obey a set of rules that automatically ignores pk3's that dont meet the spec.

Also an IP list of all these fake servers would be nice, so they can be passed to the corresponding law enforcement agencies, to allow investigation of the people running them. It might not result in arrests, but it will put them on certain cybercrime radars, as these people will often be doing things far more serious than this on the side.

[Fenix]

The problem I can see here is more general. The client communicate the auth-key to the game server which query the auth server to check client identity. This a normal (and old) password authentication system where the auth-key act in place of a password. Usually, when using this type of authentication, the server doesn't store our password but a hash of our password (computed using a collision resistent algorithm like SHA family). Everytime the user submit the password, the server computes the hash and matches it with the one stored (simple as that). In this way, if somone manage to get his hands on the database of the server where password are stored he cannot steal passwords, but hashes of passwords (which are useless since you cannot recompute the original password from the has of it: hash is one-way only function) Now: the auth-key is generated by FS-CMS and you can see your auth-key in your profile (on this website), which means that FS-CMS is not storing a hash of the "password" but the password itself: this is the very first problem I can see (and not a small one).

Since the auth-key is already generated by FS-CMS I don't see any reason why not to use a public key authentication protocol like PKCS1 (or simple RSA eventually). FS-CMS could generate for us a Private-Key (that we will put on our client, like we already do with the auth-key, and that will not be transmitted to servers) and a Public-Key which will stay on the auth server. What do you achieve with this? You can put a normal login system inside UrT client (username and password). The user inserts username and password, the client QVM encrypt username and password using the private key (which will be the auth-key) and send everything to the gameserver which simply act as a proxy sending everything to the auth server. The auth server can decrypt (since it has the auth-key) and it's the only one who can decrypt (in asymmetric cryptography you encrypt with a key and decrypt with another one: and you can decrypt only with that one). Now the auth server knows our username and password and can check for a match in the database (matching our username and a hash of our password). When the match is found the auth server returns some data to the game server which will confirm our identity (if we entered a correct username/password combination). The data sent back to the game server can be also plaintext since it doesn't contain sensitive information.

This post has been edited by Fenix: 23 September 2014 - 07:46 PM

[=jF=docDude]

Did you bring this up when you were still on the dev team?
Well.. I guess you did, just making sure

[FS Barbatos]

Fenix, on 23 September 2014 - 07:43 PM, said:

The client communicate the auth-key to the game server

No it doesn't. The client communicates its auth key with the authentication server ONLY and all communications are encrypted.

[Dengad]

if the server knows the client key it is always possible to get and regardless of it , I'm not deeply versed but I suspect it's somewhere in the gclient->sess......

This post has been edited by Dengad: 24 September 2014 - 06:05 AM

[FS Barbatos]

Dengad, on 24 September 2014 - 05:52 AM, said:

if the server knows the client key it is always possible to get and regardless of it , I'm not deeply versed but I suspect it's somewhere in the gclient->sess......

The server does NOT know the client key and it's not stored anywhere except in a local variable in the client that is never sent to the server.