Patch: password protected servers

[[-z-]]

You should get a job as a software tester... if you can convince a company to trust you.

[tundramagi]

You should get a job as a software tester... if you can convince a company to trust you.

The getting a good/real job part seems unrealistic. The bottom is falling out from everything. Also the only job experience I have is 2 retail jobs and a work-study program. My 4 yr degree is in buisness and is worthless. I don't think there is any possibility of me ever getting a good job. I will probably always be in retail untill 30, which is surely when life ends as I've been told.

[[-z-]]

Why not just show them some of your internet triumphs? Build a portfolio of your smarts.

[tundramagi]

Why not just show them some of your internet triumphs? Build a portfolio of your smarts.

What triumphs?

[divVerent]

Anyway, back to topic.

The big problem with passworded servers is abuse of that feature by changing the engine to ALLOW them to be registered on the master server.

And I know that many people want that.

Although the author of this thread proposes a patch that does make the server forcefully non-public, it's trivial to remove that code and allow passworded servers to clog the server list, which would be a GREAT annoyance to everyone.

Before accepting such a patch, we'd need some automated means to safely check whether a server is passworded, and have the master server (dpmaster) reject entering passworded servers.

An idea for this would be doing the password check not in the "connect" request, but already in the "getchallenge" one. That command can be used at any time, and it does not fail if the server is full. The master server therefore could easily use it (e.g. after every heartbeat packet) to verify the server and to keep passworded servers out.

I do not demand that the master server be changed NOW for this. This can be done later once such abuse is there. But if the password protection is moved to the "getchallenge" stage, nobody would be able to easily hack his server so it successfully registers into the public server list once that dpmaster change would be made.

Still, the gaping security holes in this patch need to be changed anyway (especially that join_password is easily sent to a server the PW is not intended for, and that server could log the password then). Stuff that IMHO has high priority before this is:

- SSL encrypted connections (e.g. using DTLS from OpenSSL). But I gave up on that part due to lack of documentation (only usage of OpenSSL for stream protocols is documented). With this, client and server certificates.
- If this is REALLY rejected, and not pushed away until someone else comes with OpenSSL and DTLS experience who can do it: hashed passwords for rcon. But this is bad, as it would still allow MitM attacks.

BTW, the problem mikeeusa is referring to is crappy providers in the USA. In civilized countries, someone who signs up at an ISP - be it modem, DSL, whatever - is restricted to only send packets from his own assigned IP, and can't send e.g. ARP replies to other customers of this ISP. Apparently, in the USA, the concept "cable modem" is prevalent, and it means that whole streets or blocks are in a single LAN segment, and can freely ARP spoof each other (and programs like ettercap do exactly that). And the chance to find one badly configured computer in a whole /24 subnet is very high (e.g. chances are high that one or more of them are trojaned or have bad passwords), and from there you can sniff on your actual victim.

[merlijn]

On a bit of a related note, one of the features I have been looking for is a way to allow admins (having the rcon password) to join a server even when it's full.

Only being able to use this from the console would be fine (for example connect x.x.x.x:26000 <rcon_pssswd>). This way normal players will not have to know about this behaviour (as they won't get actively prompted for the password).

About the encryption bit, it seems more logical in this case to use PBKDF (like PKCS #11) than to use full DTLS. DTLS is there to encrypt an UDP packet sequence (not in a stream, but still multiple packets), while PBKDF let's derive a key from the password - which can be used as the key for AES to re-encrypt the challenge. If the server generates the same aes encrypted sequence - they have the same password.

I'd be willing to take a stab at this when I have some free time.

[tundramagi]

About the encryption bit, it seems more logical in this case to use PBKDF (like PKCS #11) than to use full DTLS. DTLS is there to encrypt an UDP packet sequence (not in a stream, but still multiple packets), while PBKDF let's derive a key from the password - which can be used as the key for AES to re-encrypt the challenge. If the server generates the same aes encrypted sequence - they have the same password.

I'd be willing to take a stab at this when I have some free time.

Then you hijack an existing player connection rather than creating your own.

Also with that you only "gain" the advantache of douch-servers without the advantage of privacy amonst connected users and difficulty in vandalism/tomfoolery/haxing that full encryption allows: you never know when someone will private message something they could later regret to someone (and wish it was just between them (bob+alice+serveradmin), rather than them and whatever is recording their conversation free in the clear (bob+alice+serveradmin+skriptkiddie+intrepidhaxplayer+everypoliceorganization)...

Basically its having telnet with "secure" passwords vs having SSH. Once you're authenticated anyone can still do whatever they want by hijacking your connection. Also since the connection is not interrupted (it is forwarded both ways) to the original user that user can still respond to any auth challenges sent down the line later.

[merlijn]

Then you hijack an existing player connection rather than creating your own.

Also with that you only "gain" the advantache of douch-servers without the advantage of privacy amonst connected users and difficulty in vandalism/tomfoolery/haxing that full encryption allows: you never know when someone will private message something they could later regret to someone (and wish it was just between them (bob+alice+serveradmin), rather than them and whatever is recording their conversation free in the clear (bob+alice+serveradmin+skriptkiddie+intrepidhaxplayer+everypoliceorganization)...

Basically its having telnet with "secure" passwords vs having SSH. Once you're authenticated anyone can still do whatever they want by hijacking your connection. Also since the connection is not interrupted (it is forwarded both ways) to the original user that user can still respond to any auth challenges sent down the line later.

You're right in that it would still be possible to inject, or alter packets after the authentication step. The advantage is that the password itself never travels over the line. The way to resolve this would be to add a verification key to rcon passwords, for example using the AES cipher in CBC mode and forcing a re-auth whenever a failed verification was received. This would extend the packetsize with 16 octets and could be comprised of first generating the md5sum over the contents of the packet, and encrypting this with the 128-bit AES cipher. This would result in quite secure authentication.

Encryption just seems like it's over the top for this kind of traffic, and the problem with DTLS is still that if you manage to decrypt the auth-packet, you will have all the information you need to authenticate yourself.

[divVerent]

A session takeover attack for darkplaces and other NQ protocol engines already exists. Can be used e.g. to inject a svc_stufftext message on a client that executes a quake console command (like "quit").

Only disadvantage of this attack is that it's not covert - doing this will for sure kill the connection afterwards (but you can time it right before a map change and send a "connect" command so the client won't notice).

So if you're going to "authenticate first, rcon afterwards", it means one can easily inject rcon packets.

IMHO rcon packets should be digitally signed by the issuer, and only a single packet should be sent for them.

For in-game security (including join_password, session takeover can also make you able to play), one would have to encrypt the whole connection.

[Dokujisan]

Personally, I have absolutely no interest in this feature, as it's really not a good idea to do this in an open source game.

I'll give you a real-world example of why this would be useful.

I run some private servers that are quite popular. I have had one particular individual connect to my server and act like an ass to everybody. I've banned him by IP address multiple times. He just gets a new one from his ISP. I've ended up banning mutliple IP ranges with iptables. This is not ideal to me, because I also run a public server on the same box and I don't know how many people might be affected by that banning.

So divverent, what would you have me do to keep this guy off my private servers? I could change the ports, but then I would not be able to have a webpage about the servers that shows the list of players because someone could discover the port # through that page.

It seems that the best option is to password protect the server. Sure, they could discover the password by someone accidentally leaking it to them, and then I would have to change the password and notify everyone again, but this is the only thing I can imagine that would work.